【Kubernetes】控制器模型

　　在Kubernetes中，Deployment是最基本的控制器对象

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

　　这个Deployment定义的编排动作非常简单：确保携带了app=nginx标签的Pod个数永远等于spec.replicas指定的个数，即两个

　　那究竟是Kubernetes项目中的哪个组件在执行这些操作呢？

　　是kube-controller-manage组件。这个组件是一系列控制器的集合，它们被统一放在pkg/controller目录下，因为它们遵循Kubernetes中一个通用的编排方式，控制循环（control loop）

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

　　上面这个目录的每一个控制器都以独有的方式负责某种编排功能，Deployment是这些控制器中的一种。

　　例如，如果现在有一种待编排的对象X，它有一个对应的控制器，那可以用一段伪代码描述这个控制循环

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

　　实际状态一般来自于Kubernetes集群本身（kubelet心跳汇报容器状态和节点状态）

　　期望状态一般用于用户提交的YAML文件

　　像这种控制器设计原理就是用一种对象管理另一种对象。其中控制器对象本身负责定义被管理对象的期望状态（如replicas=2），而被控制对象的定义，则来自于一个模板（如template）

　　Deployment中template字段里的内容跟一个标准Pod对象的API定义丝毫不差，所有被这个Deployment管理的Pod实例，都是根据这个template字段内容创建出来的。

扫描二维码关注公众号，回复： 3465248 查看本文章

【Kubernetes】控制器模型

猜你喜欢