五、应用编排与管理：核心原理

资源元信息

资源对象

• Spec 部分用来描述期望的状态
• Status 部分用来描述观测到的状态

元数据

• Labels 标签主要用来筛选资源和组合资源

• Annotations 描述资源，系统或者工具用来存储资源的非标示性信息

• 阿里云负载器的证书 ID
• nginx 接入层的配置信息
• 上一次 kubectl 操作的资源的 json 的描述

• OwnerReference 用来描述多个资源之间相互关系的
  • 所有者，一般就是指集合类的资源，比如说 Pod 集合，就有 replicaset、statefulset

Selector

1. 查询

1. k8s 里的资源的“组织机构”是由选择器控制的

实例

• tie notin（front,back）
• Env=dev
• tie in (front,back),Env=dev（与关系）

实操

1. 查看 Pod kubectl get pods
2. 查看一下 Pod 打的标签 kubectl get pods —show-labels
3. 查看 Pod 具体的资源信息 kubectl get pods nginx1 -o yaml
4. 新增标签 kubectl label pods nginx1 env=test
5. 修改标签 kubectl label pods nginx1 env=test —overwrite
6. 删除标签 kubectl label pods nginx1 env-
7. 通过label筛选 kubectl get pods --show-labels -l env=prod kubectl get pods --show-labels -l 'env in (prod,test)'
8. 添加注释 kubectl annotate pods nginx-deployment-9456bbbf9-2gg67 custom-annotate='good'
9. 查看replicasets（通过ReplicaSet创建的 Pod 可以指定副本数量，并拥有 OwnerReference） kubectl get replicasets nginx-replicasets -o yaml

控制器模式

控制循环

• spec 和 status 不一致时触发
• 各组件独立自主运行
• 不断使系统向终态趋近 status -> spec

详细流程

Sensor 传感器

控制循环中逻辑的传感器主要由 Reflector、Informer、Indexer 三个组件构成。

1. Reflector 通过 List 和 Watch K8s server 来获取资源的数据。List 用来在 Controller 重启以及 Watch 中断的情况下，进行系统资源的全量更新；而 Watch 则在多次 List 之间进行增量的资源更新；
2. Reflector 在获取新的资源数据后，会在 Delta 队列中塞入一个包括资源对象信息本身以及资源对象事件类型的 Delta 记录，Delta 队列中可以保证同一个对象在队列中仅有一条记录，从而避免 Reflector 重新 List 和 Watch 的时候产生重复的记录。
3. Informer 组件不断地从 Delta 队列中弹出 delta 记录
4. Informer 把资源对象交给 indexer，让 indexer 把资源记录在一个缓存中，缓存在默认设置下是用资源的命名空间来做索引的，并且可以被 Controller Manager 或多个 Controller 所共享。然后把事件交给事件的回调函数。

Controller 控制器

控制循环中的控制器组件主要由事件处理函数以及 worker 组成，事件处理函数之间会相互关注资源的新增、更新、删除的事件，并根据控制器的逻辑去决定是否需要处理。

1. 对需要处理的事件，会把事件关联资源的命名空间以及名字塞入一个工作队列中
2. 事件并且由后续的 worker 池中的一个 Worker 来处理，工作队列会对存储的对象进行去重，从而避免多个 Woker 处理同一个资源的情况。
3. Worker 在处理资源对象时，一般需要用资源的名字来重新获得最新的资源数据
4. 用来创建或者更新资源对象，或者调用其他的外部服务，Worker 如果处理失败的时候，一般情况下会把资源的名字重新加入到工作队列中，从而方便之后进行重试。

扩容举例

1. 修改 ReplicaSet 的 yaml 文件，将 replicas + 1
2. 更新 replicaset，此时 spec 已经 +1，但 status 还是之前的值
3. reflector 监听到 replicaset 更新，发现需要增加 Pod
4. 通过循环控制，增加 Pod
5. reflector 监听到 Pod 增加
6. 通过循环控制，更新 replicaset status 的 Pod 数量
7. 最终 replicaset 的 status 和 spec 一致

总结

为达到目标（status和spec趋向一致），这里的循环控制会运行多次，之前还以为运行一次就行呢。

每次往目标靠近一步，并且触发下一步。这种设计思维很巧妙，整体思路是循序渐进。但此架构应对的目标需求是多种多样，而且实现步骤需要一环扣一环。想要做到通用基础架构，实属不易。