深入剖析Kubernetes学习笔记:“控制器”模型(16)

 一、Pod 这个看似复杂的 API 对象,实际上就是对容器的进一步抽象和封装而已

1、属性字段和吊环

2、操作这些“集装箱”的逻辑

二、kube-controller-manager组件

我在前面介绍 Kubernetes 架构的时候,曾经提到过一个叫作 kube-controller-manager 的组件。

实际上,这个组件,就是一系列控制器的集合。我们可以查看一下 Kubernetes 项目的 pkg/controller 目录:

$ cd kubernetes/pkg/controller/
$ ls -d */              
deployment/             job/                    podautoscaler/          
cloud/                  disruption/             namespace/              
replicaset/             serviceaccount/         volume/
cronjob/                garbagecollector/       nodelifecycle/          replication/            statefulset/            daemon/
...

这个目录下面的每一个控制器,都以独有的方式负责某种编排功能。而我们的 Deployment,正是这些控制器中的一种。

实际上,这些控制器之所以被统一放在 pkg/controller 目录下,就是因为它们都遵循 Kubernetes 项目中的一个通用编排模式,即:控制循环(control loop)。

三、控制循环

比如,现在有一种待编排的对象 X,它有一个对应的控制器。那么,我就可以用一段 Go 语言风格的伪代码,为你描述这个控制循环:

for {
  实际状态 := 获取集群中对象 X 的实际状态(Actual State)
  期望状态 := 获取集群中对象 X 的期望状态(Desired State)
  if 实际状态 == 期望状态{
    什么都不做
  } else {
    执行编排动作,将实际状态调整为期望状态
  }
}

1、在具体实现中,实际状态往往来自于 Kubernetes 集群本身

2、而期望状态,一般来自于用户提交的 YAML 文件。

3、控制器模型的实现

4、控制循环

 5、PodTemplate

 6、控制器的组成

至此,我们就可以对 Deployment 以及其他类似的控制器,做一个简单总结了

 

 

这就是为什么?

posted @ 2020-02-24 19:25  活的潇洒80  阅读(681)  评论(0编辑  收藏  举报