1. Pod Controller控制器

• 控制器是管理pod的中间层，只需要告诉Pod控制器，想要创建多少个什么样的Pod，它会创建出满足条件的Pod，相当于一个状态机，用来控制Pod的具体状态和行为。controller会自动创建相应的pod资源，并在当pod发生故障的时候按照策略进行重新编排
• 通过它来实现对pod的管理，比如启动pod、停止pod、扩展pod的数量等等
• 通俗来说就是【幕后老板】
• yaml文件中 kind 填写对应的类型即可

2. Pod Controller的类型概述

a. ReplicaSet

• 一种副本控制器，简称rs，主要是控制由其管理的pod，使pod副本的数量始终维持在预设的个数
• 并支持pod数量扩缩容，镜像版本升级
• 官方建议不要直接使用ReplicaSet，用Deployments更好，并提供很多其它有用的特性

b. Deployment

• 通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本，适合无状态的服务部署
• 当某个应用有新版本发布时，Deployment会同时操作两个版本的ReplicaSet
• 其内置多种滚动升级策略，会按照既定策略降低老版本的Pod数量，同时也创建新版本的Pod
• Deployment控制器不直接管理Pod对象，而是 Deployment 管理ReplicaSet, 再由ReplicaSet管理Pod对象

c. DaemonSet

• 在K8S集群部署中由于节点数量不定，那么如果我们需要对每个节点中都运行一个守护进程、日志收集进程等情况时，在k8s中如何实现呢？这个时候就是DaemonSet应用场景了
• 这类Pod 运行在K8S 集群里的每一个节点（Node）上，确保所有节点上有且仅有一个pod
• 有新的节点加入 K8S集群后，该 Pod 会自动地在新节点上被创建出来
• 而当旧节点被删除后，它上面的 Pod也相应地会被回收掉
• 应用场景：监控告警Agent、日志组件、监控组件等

d. StatefulSet

• 像RS、Deployment、DaemonSet都是面向无状态的服务，所管理的Pod的IP、名字，启停顺序都是随机
• StatefulSet就是有状态的集合，管理所有有状态的服务，
• StatefulSet 中的 Pod 具有黏性的、独一无二的身份标识，重新调度后PodName和HostName不变
• Pod重新调度后还是能访问到相同的持久化数据，基于PVC实现
• 分配给每个 Pod 的唯一顺序索引，Pod 的名称的形式为

<statefulset name>-<ordinal index>

• 应用场景：比如MySQL、MongoDB集群

e. Horizontal Pod Autoscaler

• 可以基于 CPU 利用率或其他指标实现Pod水平自动扩缩
• 被伸缩的pod需要是通过deployment或者replica set管理
• HPA不能应用于不可伸缩的对象，如：DaemonSets
• 由资源来决定控制器行为，控制器周期性调整目标pod的副本数量，让目标pod的实际cpu使用率符合用户指定的数值

f. Job

• 普通任务容器控制器，只会执行一次,只要完成任务就立即退出，不需要重启或重建
• 容器中的进程在正常运行结束后不会对其进行重启,而是将pod对象置于completed状态
• 若容器中的进程因错误而终止,则需要依据配置确定是否需要重启
• 应用场景：批处理程序，完成后容器就退出等

g. Cronjob：

• Linux 中有 cron 程序定时执行任务，K8s的 CronJob 提供了类似的功能，可以定时执行 Job
• 创建的Pod负责周期性任务控制
• 应用场景：执行周期性的重复任务，如备份数据、发送邮件、数据报表、报告生成等