【云原生】K8S 相关知识点整理 -- 控制器

【1】控制器概念

控制器能够管理 Pod，监测 Pod 运行状况，当 Pod 发生故障，可以自动恢复 Pod；即控制器能够代用户管理 Pod，并帮助用户确保每一个 Pod 资源始终处于用户所定义或者用户所期望的目标状态，一旦 Pod 资源出现故障，控制器会尝试重启 Pod 或者里面的容器，如果一直重启有问题，那么控制器可能会基于某种策略进行重新布派或者重新编排；如果 Pod 副本数量低于用户所定义的目标数量，控制器也会自动补全；如果多余，控制器会自动终止 Pod 资源；

【2】Replicaset 控制器

ReplicaSet 是 K8S 中的一种副本控制器，简称 rs，主要作用是控制由其管理的 Pod，使 Pod 副本的数量始终维持在预设的个数；该控制器会持续监听这些 Pod 的运行状态，在 Pod 发生故障时重启 Pod，Pod 数量减少时重新运行新的 Pod 副本；
Replicaset 核心作用在于代用户创建指定数量的 Pod 副本，并确保 Pod 副本一直处于满足用户期望的数量， 起到多退少补的作用，并且还具有自动扩容缩容等机制；
Replicaset 控制器主要由三个部分组成

• 1、用户期望的 Pod 副本数，用来定义由该控制器管控的 Pod 副本个数
• 2、标签选择器，选定哪些 Pod 是用户管理的，如果通过标签选择器选到的 Pod 副本数量少于用户指定的数量，需要根据 Pod 资源模板创建新的 Pod
• 3、Pod 资源模板，若集群中现存的 Pod 数量不够用户定义的期望数量，则需要根据 Pod 资源模板新建 Pod

【3】Deployment 控制器
Deployment 是 K8S 中最常用的资源对象，其为 ReplicaSet 和 Pod 的创建提供了一种声明式的定义方法 (声明式定义，指直接修改资源清单 yaml 文件，然后通过 kubectl apply -f 资源清单 yaml 文件，从而实现更改资源)，在 Deployment 对象中描述一个期望的状态，Deployment 控制器就会按照一定的控制速率把实际状态改成期望状态，通过定义一个 Deployment 控制器会创建一个新的 ReplicaSet 控制器，通过 ReplicaSet 创建 Pod，删除 Deployment 控制器，也会删除 Deployment 控制器下对应的 ReplicaSet 控制器和 Pod 资源
Deployment 可以使用声明式定义，直接在命令行通过纯命令的方式完成对应资源版本的内容的修改，即通过打补丁的方式进行修改；Deployment 能提供滚动式自定义自控制的更新；对 Deployment 来讲，用户在实现更新时还可以实现控制更新节奏和更新逻辑

通过 Deployment 对象可以实现如下功能

• 1、创建 ReplicaSet 和 Pod
• 2、滚动升级 (不停止旧服务的状态下升级) 和回滚应用 (将应用回滚到之前的版本)
• 3、平滑地扩容和缩容
• 4、暂停和继续 Deployment

更新节奏和更新逻辑的示例讲解

• 比如 Deployment 控制 5 个 Pod 副本，Pod 的期望值是 5，但是升级的时候需要额外多几个 Pod，那么控制器可以控制在 5 个 Pod 副本之外还能再增加几个 Pod 副本；
  • 比方说能多一个，但是不能少，那么升级的时候就是先增加一个，再删除一个，增加一个删除一个，始终保持 Pod 副本数是 5 个；
  • 比方说最多允许多一个，最少允许少一个，即最多 6 个，最少 4 个，第一次加一个，删除两个，第二次加两个，删除两个，依次类推；
  • 说明，这种滚动更新需要加 readinessProbe 和 livenessProbe 探测，确保 Pod 中容器里的应用都正常启动了才删除之前的 Pod

【4】DaemonSet 控制器
DaemonSet 控制器能够确保 K8S 集群所有的节点都运行一个相同的 Pod 副本，当向 K8S 集群中增加 node 节点时，该 node 节点也会自动创建一个 Pod 副本，当 node 节点从集群中移除，这些 Pod 也会自动删除；删除 Daemonset 也会删除它们创建的 Pod
DaemonSet 的控制器会监听 K8S 的 DaemonSet 对象、 Pod 对象、 node 对象，这些被监听的对象发生变动，就会触发 syncLoop 循环让 K8S 集群朝着 DaemonSet 对象描述的状态演进
适用场景

• 1. 在集群的每个节点上运行存储，比如，glusterd 或 ceph
• 2. 在每个节点上运行日志收集组件，比如，flunentd、logstash、filebeat 等
• 3. 在每个节点上运行监控组件，比如，Prometheus、Node Exporter、collectd 等

DaemonSet 与 Deployment 的区别

• Deployment 部署的副本 Pod 会分布在各个 Node 上，每个 Node 都可能运行好几个副本
• DaemonSet 每个 Node 上最多只能运行一个副本

【5】StatefulSet 控制器
StatefulSet 控制器是为了管理有状态服务的问题而设计的
有状态与无状态服务

• 有状态服务概念
  • StatefulSet 是有状态的集合，管理有状态的服务，它所管理的 Pod 的名称不能随意变化，数据持久化的目录也不一样，每一个 Pod 都有自己独有的数据持久化存储目录，比如 MySQL 主从、redis 集群等
• 无状态服务概念
  • ReplicaSet、DeploymentSet、DaemonSet 都是管理无状态的服务，它们所管理的 Pod 的 IP、名字、启停顺序等都是随机的，个体对整体无影响，所有 Pod 都共用一个数据卷，比如部署的 tomcat 就是无状态的服务，tomcat 被删除后，再启动一个新的 tomcat，加入到集群即可，跟 tomcat 的名字无关

StatefulSet 的组成部分

• 1. Headless Service，用来定义 Pod 网路标识，生成可解析的 DNS 记录
  • Headless service 的概念
    • Headless service 不分配 clusterIP，headless service 可以通过解析 service 的 DNS，返回所有 Pod 的 dns 和 ip 地址  (statefulSet 部署的 Pod 才有 DNS)，普通的 service 只能通过解析 service 的 DNS 返回 service 的 ClusterIP
  • Headless service 的作用
    • 在使用 Deployment 时，创建的 Pod 名称是没有顺序的，是随机字符串，而使用 statefulset 管理 Pod 时要求 Pod 名称必须是有序的，每一个 Pod 不能被随意取代，Pod 重建后 Pod 名称还是一样的；由于 Pod IP 是变化的，所以要用 Pod 名称来识别，Pod 名称是 Pod 唯一性的标识符，必须持久稳定有效，这时候要用到 Headless service，它可以给每个 Pod 一个唯一的名称
• 2. volumeClaimTemplates，存储卷申请模板，创建 pvc，指定 pvc 名称大小，自动创建 pvc，且 pvc 由存储类供应
• 3. StatefulSet，管理 Pod

volumeClaimTemplate 的作用
对于有状态应用都会用到持久化存储，比如 mysql 主从，由于主从数据库的数据是不能存放在一个目录下的，每个 mysql 节点都需要有自己独立的存储空间；而在 deployment 中创建的存储卷是一个共享的存储卷，多个 Pod 使用同一个存储卷，它们数据是同步的，而 statefulset 定义中的每一个 Pod 都不能使用同一个存储卷，这就需要使用 volumeClainTemplate，当在使用 statefulset 创建 Pod 时，volumeClainTemplate 会自动生成一个 PVC，从而请求绑定一个 PV，每一个 Pod 都有自己专用的存储卷；
Pod、PVC 和 PV 对应的关系图

参考与致谢
本博客为博主学习笔记，同时参考了网上众博主的博文以及相关专业书籍，在此表示感谢，本文若存在不足之处，请批评指正。