笔记摘自视频章节：第四章-p24
主题
k8s控制器的种类和功能
笔记
Kubernetes 中内建了很多controller (控制器),这些相当于一个状态机,用来控制Pod的具体状态和行为
- ReplicationController和ReplicaSet
- Deployment
- DaemonSet
- StateFulSet
- Job
- Cronjob
- Horizontal Pod Autoscaling
RC和RS
- ReplicationController (RC)用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器异常退出,会自动创建新的Pod来替代:而如果异常多出来的容器也会自动回收
在新版本的Kubernetes中建议使用ReplicaSet 来取代ReplicationController. ReplicaSet 跟ReplicationController没有本质的不同,只是名宇不一样,并且ReplicaSet支持集合式的selector;
Deployment
- Deployment 为Pod 和ReplicaSet 提供了一个声明式定义(declarative)方法，用来替代以前的
- ReplicationController来方便的管理应用。典型的应用场景包括:
- 定义Deployment 来创建Pod和ReplicaSet
- 滚动升级和回滚应用
- 扩容和缩容
- 暂停和继续Deployment
deployment和rs的关系
ReplicaSet可确保指定数量的pod“replicas”在任何设定的时间运行。然而，Deployments是一个更高层次的概念，它管理ReplicaSets，并提供对pod的声明性更新以及许多其他的功能。因此，我们建议您使用Deployments而不是直接使用ReplicaSets，除非您需要自定义更新编排或根本不需要更新。
声明式编程与命令式编程
- 命令式编程: 它侧重于如何实现程序,就像我们刚接触编程的时候那样,我们需要把程序的实现过程按照逻辑结果一步步写下来。 kubectl create
- 声明式编程: 它侧重于定义想要什么,然后告诉计算机/引擎,让他帮你去实现。 kubectl apply
deployment的扩缩容功能
deployment控制RS进行扩缩容。
- 滚动扩容：
- 创建一个新的rs，记为rs2。原来的rs记为rs1。
- rs1 pod 数量-1， rs2 pod数量+1，这就完成一个pod的扩容
- 以此类推，完成滚动
DaemonSet
DaemonSet保全部(或者一) Node上运行一个Pod的副本,当有Node加入集群时,也会为他们新增一个Pod. 当有Node从集群移除时, 这些Pod也会被回收, 删除DaemonSet将会删除它创建的所有Pod 使用DaemonSet的一些典型用法:
- 通行集群存daemon, 例如在每个Node 上行glusterd,ceph
- 在每个Node上通行日志收集daemon, floentd, logstash
- 在每个Node上行daemon, 9 Prometheus Node Exporter, collectd, Datadog 代理New Relic 代理
Job
Job负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束
CronJob
CronJob管理基于时间的Job，即:
- 在给定时间点只运行一次
- 周期性地在给定时间点运行
使用前提条件：当前使用的Kubernetes集群，版本>=1.8 (对Cronjob)。对于先前版本的集群，版本< 1.8，启动API Server时，通过传递选项
--runtime-config=batch/v2alpha1=true以开启batch/v2alpha1 API 典型的用法如下所示: - 在给定的时间点调度Job运行
- 创建周期性运行的Job，例如:数据库备份、发送邮件
StatefulSet
部署有状态服务
StatefulSet 作为Controller 为Pod提供唯一的标识。它可以保证部署和scale的顺序 StatefulSet是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为无状态服务而设计)，其应用场景包括:
- 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
- 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service (即没有 Cluster IP的Service)来实现
- 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行(即从0到 N-1， 在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态)，基于init containers来实现。（因为Init container不用修改app的镜像文件）
- 有序收缩，有序删除(即从N-1到0)
Horizontal Pod Autoscaling
水平自动扩缩容。 应用的资源使用率通常都有高峰和低谷的时候，如何削峰填谷，提高集群的整体资源利用率，让service中的Pod 个数自动调整呢？这就有赖于Horizontal Pod Autoscaling了，顾名思义，使Pod水平自动扩缩容
