云世 公众号

续前篇：详解｜K8s核心技术栈解析

K8s与虚拟机部署的区别、高可用部署的命令、对象如何定义、对象分组原则、Pod、service、deployment等核心对象工作流程、架构、原理解析

K8s应用的好处

假设你是一个开发人员，写了一个web服务器，想把它发布出去。在虚拟机世界里面，这是很困难的：

首先要去建这些虚拟机，要有一个provision的过程：需要去设定什么样的操作系统，要多少CPU，多少memory，然后要想办法把你的应用程序，包括它所依赖的中间件，（比如你的应用是Java程序，就需要想办法把Tom cat装上去，要把你的war包放在固定的目录，需要去重启Tom cat，让你的应用起起来）。

对于一两个节点，这个手工操作ok，但是当面对成千上万甚至几十万的实例的时候，这个操作几乎就不可能，就失去人为去管理整个平台的能力了，成本和出错的几率会非常大。

那么在容器世界里怎么做呢？

在前面一篇：容器核心技术解析 中讲过：

1. 首先可以通过go build把源代码编译成一个可执行的文件，

2. 然后通过 docker build，把编译好的文件放到容器镜像里面，

3. 接下来在定义容器镜像启动的时候，定义它执行哪条命令，把所有编译的任务都放到了这个文件里面。

这个文件有几个目标：

1. 把源代码编译成可执行文件，

2. 通过docker build把可执行文件塞到一个容器镜像里面去，

3. 通过docker push把这个容器镜像推到镜像仓库。默认的镜像仓库是docker hub。

作为应用开发人员，通过以上操作就把应用打包好，并且上传到镜像仓库了。要去做部署的时候，就去另外一个环境，用镜像把它部署出来。

K8s的部署跟虚拟机不一样

回顾前面讲的K8s的核心对象：Namespace、Pod、Node等。

这些核心对象及相互之间在K8s是如何运作的，有哪些通用属性呢？

以及这些核心对象间世怎么联动的？

其中Pod就是用来起镜像的容器实例的。

先定义一个K8s对象，deployment，它是用来干嘛的？它跟Pod之间有什么关系？

举个例子：deployment其中有个属性叫replica，如果它=3，就是有3个实例。（设定多个实例的原因是要做应用的高可用，做冗余部署）。每个实例分别提供了IP。思考对于冗余部署的服务来说，要提供一个服务出去，能把这三个IP都给出去吗？

当多实例部署的时候，把每个实例的IP都给出去，是有问题的。因为把IP list给出去，要依赖客户端来决定连哪个。客户端盯着一个，只把request发给其中一个IP，而背后有三个实例，它的负载是不均衡的。当请求很大的时候，会出现所有request都连到一个实例上去，这个实例就可能没法响应了，但是其他的实例又都是空闲的。

所以为了保证应用高可用率，要有负载负载均衡。

K8s提供了一个对象叫做service，预先定义好了service，叫做Nginx service，是为服务配负载均衡规则的。service有plus IP作为这个服务的虚IP，VIP（virtual IP）。访问虚IP就会把请求转到后面的三个Pod。每次访问的时候，它连的backend就已经做了负载均衡。这种情况下，服务就有了高可用的能力。

如果把其中一个Pod删掉，再通过访问VIP，用户的访问是不受影响的，它把请求指向了其他两个Pod中的一个，保证了出现故障时的应用高可用。

在K8s中，应用高可用部署可以简化到敲三个命令完成：

1. 第一条命令：create -f +文件，创建了一个对象deployment

   通过建deployment，达到的目标是把应用部署到K8s平台上。

2. 第二条命令：scale，把建好的对象里面其中一个副本数的属性进行扩展到n，获得的结果是同时起了n个Pod。

3. 第三条命令，集群里面有service，提供虚IP，访问虚ip，就把所有的请求转到backend的Pod里面去，就完成了应用的高可用部署。

K8s的对象是如何设计的

K8s之所以厉害，成为业界云计算的统一标准、事实标准，是因为它是一个声明式系统。

通过声明式系统，也就是它的架构原则，把所有要管控的对象都用统一的方法抽象成了一个个对象。

K8s的统一属性

第一部分是Typemeta

里面又有TypeMeta，用来声明这个对象的类型。

Type meta里面有三个重要的属性，第一个属性是叫做group，第二个属性叫kind，第三个属性叫version。我们常说的GKV。

1，K8s有很多很多的对象，会按照不同的业务目的，把这些对象放到不同的group里面去，所以可以把group就认为它是 Java里面的package。

2，Kind代表这个对象是什么。映射到Java里面的class。

3，第三个是version， K8s里面任何对象都有一个version，而且很多对象在中间态的时候会有不同的多种版本同时存在。

比如装了某一个K8s版本，你用不同的版本都能get出来， version干嘛用的呢？社区在不断的迭代过程中，不断的设计和演化出来。K8s在每年有4个版本，基本上每个季度一次，它是按照既定的周期去发新版本的。（后面一年会调整为三个版本，因为release太多，整个业界都要跟着他走，都跟得很累）

我们讲究敏捷，讲究迭代，任何社区的API定义，对象的定义，并不是一定义出来就是一个final版本了，社区会follow一定的原则做版本的演进。从alpha，到beta，然后再上生产。

跟做系统类似，开始先做poc，一个最初的版本，然后随着需求不断增加，把功能部署出去，不停的使用，会觉得有一个设计是不合理的，要做一些调整。所以K8s在做演进的时候，非生产版本的变化是不保证的。

处在版本升级，迁移中，如果用的是alpha功能或beta功能，可能它的属性会发生变化，那么怎么减少迁移成本？K8s设计了一种向前兼容的能力。向前兼容三个版本，实现就是通过version。任何对象，会分external version和internal version。

例如：

v1：说明Pod本身已经毕业了，它基本上不需要做向前兼容，想的已经很清楚了。但是有些对象还不是这个版本，很有可能在下一个时期它的结构就会发生变化，所以设计了internal version和external version。

 

version的作用

External version和Internal version之间的转换是怎样的？

是客户端连API server的时候，告诉API server，它是哪个版本的，API server内部会维护internal version，在API server这一端，它会有conversion的方法，把external version转成internal version，然后会把internal version再转成external version的模式。这个能力支持到当不同的客户端以不同的版本去连api server的时候，不同的版本的数据都可以按照既定的conversion的方法转成internal version。

Internal version也知道，这个版本要通过alpha 1 写进来的数据，你要通过alpha 2 去读，它知道怎么样相互convert，所以这样就实现了多个版本的转换和兼容。这就是version的作用。

GKV就代表了对象是哪个组的，哪种类型的，什么版本。其实就是定义对象是什么，不是什么。

K8s核心对象第二个大的部分，所有对象都有的通用属性，叫做metadata。

比如：deployment对象，metal data里面有namespace。

Namespace把DB分成一个个的namespace，可以按照用户去划分的，或者按照项目去划分。可以把不同应用的对象或者不同用户的对象放在这些namespace，然后通过权限控制来控制能不能看，能不能改，这样可以做安全性的隔离，相当于对DB做隔离，建了一些目录，这些目录里面放了一些文件，这些文件就是这些spec，比如deployment就是 spike。Name和namespace约定了对象放在哪个namespace，它的名字是什么。

就唯一确定了我是谁，上面的GKV确定了我是啥，Metadata确定了我是谁。这几个要素组合起来就变成了这个对象在集群范围的一个唯一标识。

第三个重要的属性是label和annotation

label是什么？
可以为对象加上一些标签，用这个标签去做过滤查询。

标签查询有什么意义？

K8s在做对象和对象组合的时候，鼓励用松耦合，有另外一个对象叫service用来定义负载均衡配置。在service里面有一个属性叫selector，做过滤查询，查询namespace里面打了这个标签的Pod。所以label的意义就是跟一些selector去合作，去完成一个查询过滤的业务目标。

Annotation是什么？

annotation是不支持过滤查询的。

它的意义是什么呢？

把它当成对象定义的扩展。对象一旦定型了以后，对象的本身的struct就不会再发生变化了，比如Pod，想加一个属性是加不上去的，那么 annotation 这个时候就能体现它的作用了。

另外一个重要的属性是Finalizer，
把它理解为资源的锁。如果一个对象要配一个外部的设备，假设说你建一个service要配一个外部的负载均衡器，如果把这个对象删除，控制器正在出现故障，这个对象消失了，从etcd里面被删除了，那么负载均衡上那个配置就丢在那里了，没人管了。
这个情况，应用finalizer锁，可以往里面塞任何的值，一旦塞了这个值，这个对象就不会被删除，直到你把Finalizer解除掉。

接下来还有一个resource version，是做版本控制的。
resource version就相当于给对象加一个版本号。

K8s本身是一个微服务的平台，任何对象都可能被多个控制器或者用户同时修改，那么就涉及到了多线程或者多进程去修改同一个对象资源的场景。

我们做数据库或者做多线程开发的时候，这种场景下应该怎么处理加锁？

有两种，一种叫乐观锁，一种叫悲观锁。

• 悲观锁在做写之前，先把对象lock住，如有其他人也要改，需先获取锁，如没获取到，需等锁。

  对于分布式系统，如果这样加锁整个系统的性能就会降低。因为很多线程在等锁，所以resource version就是给对象加一个版本号。

• resource version是一个乐观锁。它的工作机制是：某个Pod的resource version假如是1版本，这时如果有两个线程来读取对象，那么两个线程都读取到的是1版本，两个线程都去更新对象，同时发起写操作到API server，那么微观上API server一定会先处理一个后处理一个，先处理的完成了以后，对象就会变成版本2，后处理的会去比较：要操作的对象最新的版本是多少，请求过来的时候，resource work版本是多少。如果当前的最新版本超出请求的版本，说明请求版本是旧的，就会触发写冲突，给客户端报错，409，conflict，后处理的写操作失败。这是客户端有责任去做的操作。

  这是 resource version的乐观锁作用，MVCC（multiple version concurrency control）它依赖于 Etcd的mvcc保证的。

以上是K8s对象定义的解析。这些通用的type meta和metadata在任何K8s对象里面有。

K8s特定对象及分组

K8s按照业务目的，将不同的对象放在不同的分组里面，分组的方式可能是这个版本在这个分组，下个版本它在另外一个分组更合理，就会放到别的分组去。

K8s对象如何分组

• 首先最核心的对象，是让平台或者让你的业务能跑起来的一个最小级。

• 在最小级之上要做一些应用管理，应用管理可能要管理多副本，要管理有状态，要管理无状态，就分了一个application的组，APPS组。在这个组，可能跑一些短时的Job，有Job和CronJob。

• 在应用管理的上面可能有一些自动化，比如要做扩缩容，horizontal port，autoscaler，做扩缩容，要控制一个应用最多能有多少个实例不工作，可以通过pdb去定义。

按不同的业务目的，把所有的K8s对象组织起来了。

最核心的对象就是Pod。是连接应用层和结构层的核心对象。

基础架构这边的核心对象是node，计算节点。应用的核心对象是Pod，pod和node之间产生绑定关系，就让二者之间的边界去除了。

Pod不是孤立运行的。可以把它理解为一堆容器的松耦合的容器集合的对象。Pod就像Borg里面的task一样，是K8s里面调度的基本单元。当有一个应用，通过源代码构建成了一个容器，容器镜像，想运行在K8s上面怎么办？就去定义一个Pod。

Pod定义原则

Pod里面定义镜像仓库镜像的地址，需要的资源，还有更多依赖等。K8s的12 factor其中有一条原则是代码和配置分离，应用的可执行文件或者依赖包都在镜像仓库里面，但配置文件是不在镜像仓库里面的，遵循12 fector原则，需要把它的配置文件通过另外的方式灌进去，K8s提供了一些其他的对象，比如config map，secret，把配置放在config map和secret里面。这两个对象定义好了以后，通过 volume外挂存储的方式，把它mount给这个Pod。

Pod启动的时候会需要一堆依赖对象，它本身是要有个账户身份的，叫service count。它的作用是Pod要跟API server通信， API server能够认识Pod是谁。

Pod需要一些配置，这些配置可以从configmap或secret里面去读。

Pod需要一些外挂存储，K8s提供了pv和PVC的这样一些对象，这些东西都可以挂载到Pod， Pod可以把它们里面所包含的内容当成本地文件来读。

Pod应用高可用策略

Pod是应用事例，当部署应用的时候，Pod一旦创建，会被调度到某一个节点上面。如果定义了一个孤立的Pod被删除，它就消失了，没有办法确保这个应用的高可用。怎么样去确保应用的高可用？要去定义一个更高级的跟application相关的高级对象，来确保Pod永远存在。

更高级的对象有好多种：

• 无状态的应用，用replicaset和deployment去创建

• 有状态的应用，用statefulset创建

• 在每个节点上跑一个实例的应用，用Deamonset创建

K8s核心对象工作架构

从deployment到Pod这一条线是如何工作的

service：Pod起来以后有了应用实例，要发布服务，通过service去expose出去，暴露服务。

ingress：对于一个web应用，整个集群有一个统一的API网关，K8s提供ingress对象，定义API网关。

以Pod为核心，发散出来跟它相关密切相关的重要对象。这个架构里涵盖K8s大部分的知识。

容器在Pod创建的时候到底如何工作的？

定义了一个容器的pod，假设是Nginx的Pod，这个Pod里面就只有一个image，是ngx的image。K8s在起这个 Pod的时候，它并不是只起一个容器，它是起两个容器，其中一个容器叫sandbox。比如CRI接口，事实上是两部分，一部分是对sandbox的操作，一部分是对 user container的操作。这个容器是K8s自带叫做 pause的 image, 里面就一条命令，这个镜像一旦运行起来，它不做什么任何事情就直接sleep掉了。

这意味着这个镜像非常小，不需要CPU资源，极度稳定，它不会crash，不会oam，也不会有空指针。小而精的不消耗资源的基础镜像，这个基础镜像的作用是去创建一个独立的网络namespace，把sandbox进程跟网络name space相关，然后所有的网络配置是配在这个sandbox container的namespace的。
 

当所有网络配置完成以后，才会去起主container。为什么需要这样？

因为主container启动的时候就需要网络，主container启动之前，网络要先配好的，所以一定是网络预加载。

Configmap支持动态更改。

POd启动后，把configmap Mount到pod里面。会把 configmap从API server下下来，放在本地docker的dir里面，只要应用进程支持本地文件刷新的时候，它重新去load，就可以动态更改。

service的虚IP是某个机器的IP吗？外部可访问吗？会不会和其中一个replica的重复？Pod的IP和service IP是不同的range，

POd IP是怎么做的呢？
是通过CNI的plugin去配置的。

service IP的或者叫class IP，是API server在启动的时候会配一个class IP range。所有的service IP是从那个 range去配的。

外部访问集群内的一个服务有两种方式：

• 第一种方式、通过负载均衡器访问，负载均衡器跟K8s做集成，标准的cloud provide提供集成，也有可能如果不是标准的cloud，要自己去切service controller；

• 第二种方式、就是通过noteport，就是节点端口。起一个service的时候，它在会在机器上开一个高端口，访问这个高端口的时候，会把请求转到backend pod里面去。

K8s核心对象的工作机制

K8s是一个声明式系统，除了metatype，metadata这些通用属性，还有Spec和status。Spec就是用户的声明，就是期望这个对象长得什么样。status是Controller回填的，是对象的一个真实状态。

Controller在这两个属性上的作用是什么？就是把真正的状态跟期望的状态保持一致。这是K8s对象设计的精华，每一个对象的spec和status长的是不一样的。

对象的Spec工作机制
以计算节点NOde为例，如spec是空的，有很多status，填这个节点的IP，节点的主机名，节点的可分配资源。如节点一共有多少资源，20G硬盘，10G内存，6个CPU。用eligible表明有多少可用的，这个信息是给scheduler消费的，scheduler会读取这个信息，知道每个节点的资源使用情况，它做调度的时候就可以做正确决策。

以Pod为例，它的spec部分就是一堆一组容器定义的集合，每个container会定义image是什么，name是什么，还有一些资源的使用需求。资源需求不填，这个Pod就是随便可以调到任何的节点上，它不受资源管控。

Pod是一组紧密关联的容器集合，有些应用可能一个容器不能满足业务需求，可定义多个容器，每个容器有自己的镜像和自己的资源需求，在Pod这个 spec里面，容器的部分是个数组，可以把多个容器组合成一个Pod，它本身是K8s的调度基本单位。不同的容器会运行在不同的PID，所以当一个Pod里面有多个容器的时候，它和主机的IP信息是共享的，网络是共享的。但是像PID IPC IMP这些东西是不共享的，所以Pod是一堆容器的松耦合的一个组合对象。

Pod为什么不鼓励被独立创建呢？
因为Pod是短生命周期的，假设说建一个Pod，然后把它删掉，它就消失了。如果作为服务的提供商，万一Pod被建出来以后又被人误删了，我的服务就当了，所以应用要确保高可用。

• Replicaset对象

  确保高可用怎么操作呢？
  要去定义另外一个对象。为了不同的业务场景，应该组合不同对象来完成一个目标。
  通过副本级来实现。所谓的副本级，它本质上就是在Pod的 spec上面包了一层，它把Pod spec作为Pod 的template，模板，在上面就定义要几个replica，K8s会去确保总会有这么多副本能够满足你的需求。

• Deployment对象

  做应用开发或者应用部署的时候，经常会涉及到版本的替换。一个应用已经变成高可用的了，升级的时候希望是滚动升级，就是一部分一部分升级，最终的目的是什么？不影响用户的使用。那么通过这种方式，希望做一个滚动升级，就需要约定一些滚动升级的策略，策略通过Deployment这个对象来定义。

  对于无状态应用，最常用的对象就是deployment，它确保了什么？
  第一，定义好了滚动升级的策略，在做版本升级的时候，可以做对用户没有影响，不会让service down掉的滚动升级。

  第二，会建一个副本级，确保应用一定要多少个实例。当某些实例被删掉的时候，会自动补一个新的出来，这是deployment的作用。

对象的Status工作机制
K8s对象都有status，status是让controller去干活，然后Controller填上去的，是对象的真实状态。

Status里面有个condition，是对象的一些状态的细节。

协同工作原理

Controller manager是一堆控制器的集合，其中有一个控制器叫做deployment controller，它watch所有deployment的变化，一旦一个deployment被创建了，或者被更新了，它就要去做配置，去建了一个replicaset。

控制器是怎么工作的

1. 创建deployment，然后Controller监听到了创建事件，

2. 就去读取deployment，Deployment controller去解析这个department，把deployment里面的port template部分读出来，并计算哈希。

3. 根据哈希去判断模板创建POd的副本级存不存在？如果不存在，就要创建一个副本级叫做Replicaset，

4. 这个 Replicaset 副本数是deployment里面那个 Replicate是几，复制过来，它会把 template也复用过来。

5. 副本级被创建好了以后，在Controller Manager里面同时replicaset controller，会去watch API server，看有Replicaset被创建了，那所对应的Pod是否存在了，如POd不存在，Replica Controller会去创建Pod。创建原则是在后面加uid，保证Pod名字唯一性。

6. 此时scheduller调度器看到新的POd创建出来了，会看有没有被调度过，如没有，就进行调度，并且把Pod和node完成绑定。

7. 绑定到node节点以后，节点上的kubelet会去watch API server，因为所有的组件都是跟API server通信的，组件和组件之间是不通信的，通过长链接监听，大家都在监听API server。

8. Kubelet监听到某个POd被调度到节点，看本地POd起起来没有，如果没有，会去调用CRI接口，CNI接口，CSI接口去挂载volumn，去起容器进程，去加载网络，这样整个容器就起来了，就能够被访问了。

其中，replica更新的数据会被存到API server，API server有Watch机制，通过event进行通信，API server里面发生的变化，会推送给replicaset，那么Replica Controller看到这个事件变化了以后，就看这个Replicaset对应的Pold有几个，是否跟deployment申明一致，不一致就更新到一致。

K8s核心对象的应用

集群的故障转移

场景：一个应用被调到了不同的节点，其中的一个节点出现了硬件故障，网络不通了，这时kubelet会把这个节点上的所有Pod做驱逐，因为那个节点已经坏了。意味着上面所有应用都会出问题。此时Node controller会去驱逐这个坏node上所有Pod，结果相当于把这个Pod删除掉了。立刻，K8s又补了一个Pod出来。通过这种方式就完成了一次故障转移。

这其实是由Replicaset的Controller来实现了用户期望的值和真实的值的一致性。另外，因为节点故障了，在新的pod被创建出来了以后，调度器再去调度的时候，会找一个健康的node把pod调度上去，再由kubelet起起来，这样就实现了一个fail over，实现了故障转移。

从用户的感受来说，一个节点坏了，他什么都没做，这个实例就在另外一个节点上起来了。这些就是replicaset controller去控制的。

如上scal out，fail over，在K8s上都是用户无感知的，就被自然实现了。

工作原理就是有一个个的Controller，Controller会不停的监控你的期望值和当前的现实值是不是一致，不一致就去调整成一致，智能化自动化了。这是K8s最核心的功能。

版本升级

对于任何新建的deployment，会给一个默认的rolling update strategy，每次去升级25%的实例，如果是三个的话，25%就一个一个去做。如果有一个不available，它就会停在那里。这是升级策略的理解。

版本升级是deployment controller去做。它会计算Pod模板的哈希值，当哈希字串发生变化了，对于development controller来说，意味着用户要做一次升级，controller就会算一个新的哈希，建一个以新的哈希副本级，逐渐把新版本的副本级的replicaset数量往上调，把老版本的replicaset的副本数往下调，直到所有的版本，pod版本都变成新的。如果中间有任何pod出现问题没有ready的话，就会卡在那里。

这样基于deployment就完成了一次版本的滚动升级。

在开发实践中应用，就是构建一个新的镜像，这个新的镜像打了V1.1新的tag，只要把原来在deployment的 V1.0 tag改成新的版本，那么它的哈希就发生了变化， deployment 的 rolling update strategy就会生效，就会按照既定策略去完成升级。

Tips：最核心的对象就是deployment，Replicaset和port这条线。

怎么样设计一个合理系统，想一想deployment怎么做的，做设计的时候经常会参考这个模式去思考。

Pod 的重要属性owner reference

 owner reference是metadata里面的一个属性，用来声明对象的父子关系。意味着对象不是独立存在的。

所谓的owner reference就相当于在建对象的时候，如果这个对象有一个父对象，比如Replicaset建Pod，会把owner reference填上，说这个pod的 owner是我。而replicaset是被deployment controller建出来的，那么也会被填上一个owner是那个 deployment。

在GC中的应用原理

在K8s的controller manager里面有一个控制器叫garbage collector，GC，垃圾回收，一旦有owner reference，对象的父子关系就有了，GC会去监控当前集群里面的所有对象，GC有两个组件，一个组件叫graph builder，扫这些对象的owner reference，有ownership，graph builder就会记录当前这个集群里面的这个对象关系图，会知道刚才的那个 deployment和这个 replicaset和Pod是有从属关系的。

当把主对象，也就是deployment删除的时候，GC就会触发工作，根据owner reference，会删除掉有关的Replicaset，再发现其下有Pod，也会删除掉。

所以owner reference是灌给GC的，为什么要做GC这样的操作？就是为了统一提高用户感受，建了一个deployment，要清的时候，不管建了多少对象，就统一给你清掉。这就是GC的作用。

总结

不同的控制器如何协作来完成一个业务流，然后如何去保证这个无状态应用的高可用，然后如何保证它的扩缩容，如何保证它的故故障转移，如何去做版本升级滚动升级。

尽量去把这个应用构建成无状态的。那么无状态的意义就是，一个实例出现故障的时候，可以把它随便替换掉，不care里面的状态，只要坏了就换一个，通过这种方式，我们的真正的这种故障转移才能工作。

如果你每个应用都是有状态的，万一节点出现故障，就要花很高的成本去做计划，所以这里面是我们去构建应用的一个指导原则，就是：能不依赖某一状态就不依赖，尽量让它是一个独立的应用，无状态的应用，这样我们才很好的去做替换或扩缩容等动作。

结合上面的对象原理，看K8s控制器内部的工作流程

控制器的工作流程是怎样的

控制器是生产者消费者模型。对于任何K8s对象，本身有一个项目是code generation，帮你把代码框架生成出来，会有informer，会有Lister。所谓的lister，允许去遍历某一个对象，所谓的informer是去监听某一个对象。

你需要做的事情是注册这些对象informer的event handle，然后说明如果发生了edit事件，应该做什么？发生delete事件，应该做什么，发生update事件，做什么。

把对象的key放在某一个Queue里面。会有一堆worker为并发度需要存在，worker都是死循环，是sick loop。worker有多少个看实际情况，看需要有多大的并发度。性能要求高的控制器可能要1000个worker。这些worker不断的去看Q里面有没有对象（对象在 Q里面是记录了它的key，这个K就是namespace+name的组合），当 worker获取对象的 Key以后，会去client cache里面去把对象的完整信息取出来，针对对象去做配置。

比如deployment 会去看对应的replicaset存不存在，如果不存在就把它建出来，如果存在那么就去看哈希变了没，副本数变了没，如果变了的话，就需去做对应的更新操作。

如果对象配置成功了，线程就结束，如果配置不成功，基于K8s的最终一致性，某一次配置失败，要把失败的 Key加回到Q里面，让Controller继续去重试。所以这个就完全依赖你的控制逻辑。

从实现层面理解，可以把K8s理解为Linux的一个扩展，很多的设计的思想或者是代码的结构跟Linux非常像。

往期推荐

关注 云世 微信公众号。

《最全云厂商及云方案能力报告【建议收藏】》

《最新Serverless服务研究报告【收藏参考】》

《云原生：一文读懂K8s架构》

《云原生：一文读懂Docker核心技术》

《云原生：一文读懂K8s架构原则和对象设计》

《云原生：一文读懂DevOps工具链》

如果你觉得这个系列有价值，也欢迎转发给有需要的朋友。

云世

【云世】专注职场人的硬实力和软技能提升。为产品上云，微服务和云原生前沿技术和落地实践布道，分享微服务架构、容器、K8s、Service Mesh等云技术干货、案例、经验；持续发布职场做事方法论、团队管理、读书笔记，好书推荐等软技能。

公众号   

---

喜欢就｜关注｜转发｜点赞｜订阅专题吧

公号专题

「云原生」「微服务」「Service Mesh」「K8s」「Docker」

「职场养分」「职场软实力」「认知跨越」

---END---

后台回复 “边缘云服务信任能力” 领取最新完整白皮书。回复 “2021报告” 领取35份最新行业分析报告。回复 “边缘节点管理框架” 领取最新完整白皮书。