至此agnet流程分析结束,本文还有主要分析了证书的使用,对于status判断,审计,日志等没有进行分析.本文感觉agent的配置有些混乱有些用法重复.可能有同学观察到,SDSserver中有xdsserver,它与xdsproxy有什么不一样的地方嘛?...

参考 https://blog.csdn.net/dm_changping/article/details/125258719。代理命令：docker pull gcr.dockerproxy.com/username/image:tag。官方命令：docker pull gcr.io/username/image:tag。

istio是一个产品，那么这个产品肯定提供了一些功能让用户使用。因为Istio与k8s的高度结合，所以对于这些功能的使用，采用了CRD的方式。用户只需要创建相应的规则资源，istio监听到资源后会进行一些系列的操作比如创建一个路由规则VirtualService，istio监听到该资源后，会将规则解析成Sidecar识别的配置，然后推送给POD中的Sidecar。接下来让我们对Sidecar进行讲

最初的存储插件都需要集成到k8s内部去使用，也就是编译并随核心 kubernetes 二进制文件一起提供。这意味着，如果他们希望添加对新存储系统的支持，则需要存储提供商将其签入核心 k8s 代码库。为了对其进行解耦，所以采用Out-tree模式开发了Flexvolume。

info在本文中,将对pilotDiscovery服务创建流程进行源码分析具体代码注释请移至pilot-discovery是istio的注册发现中心,可以说它相当于k8s中的kube-apiserver与协调各个组件,相当于指挥部的存在.那么它具体有什么功能那?让我们来罗列一下(内容可能不全,还请补充)我们可以看到返回值是一个Server结构体,它包含了整个discovery运行过程中所需要的服务

K8s存储主要是封装了对存储组件的细节，让我们可以通过pvc，pv操控就可以对存储进行管理。下面我们开始分析在k8s中是如何实现存储组件处理逻辑的。

通过前面几篇文章,我们已经知道了istio服务注册的一个大体流程,但是对于每个资源在变动的时候是如何进行处理的,比如创建一个k8s原生service,istio在监听到事件后该怎么处理,是否需要对其进行转换然后推送到envoy中?让我们带着这些疑问开始对istio中的资源事件进行一一分析....

fluent-bit operator资源介绍fluent-bit很好的与k8s融合，离不开本身的设计。fluent-bit采用配置插件的方式对输入、过滤、分析、输出进行实现，这使得与k8s集成时，只需要采用configmap(crd中使用的secret)就可以完成原有的功能。在fluent-bit operator(接下来简称fbo)中并没有直接使用k8s原生配置资源，而是使用了自定义CRD，接

在k8s中，我们可以使用..svc.cluster.local的方式对服务直接访问，该原理是在集群中部署一个kubeDNS，然后修改为默认的DNS服务器！

kubelet是k8s单独部署的应用，它是一个节点的监视器，管理器。 我们操作的所有资源信息最后的最后都是由kubelet呈现出来的，比如创建pod。所以它是k8s的核心（我认为）。![image.png](https://img-blog.csdnimg.cn/img_convert/f434af953e0b87be12f27be40ddf1509.png#clientId=u5956da4a-