Kubernetes常用控制器
五种常用控制器
-
Deployment 无状态应用
-
Stateful Set 有状态
-
Daemon Set 守护进程控制
-
Job 一次性任务
-
CronJob 计划任务
Deployment
声明式定义方法，用于替代以前的ReplicationController
*声明式与命令式：
-
命令式：侧重于如何实现，shell脚本
-
声明式：侧重与定义，拥有幂等性，可重复执行
应用场景
-
定义Deployment来创建Pod和ReplicaSet
-
滚动升级和回滚应用
-
扩容和缩容
-
暂停和继续Deployment
ReplicationController & ReplicaSet & Deployment
ReplicationController：简称rc，当有容器异常退出，会自动创建新的Pod来代替，如果有异常多出来的也会自动回收
ReplicaSet：简称rs，跟rs没有本质上的区别，只是名字不同，并且支持集合式的selector，Replication Controller不支持集合式selector，所以被ReplicaSet替代
Deployment：一般建议使用Deployment来自动管理ReplicaSet，这样无需担心和其他机制的不兼容问题（如ReplicaSet不支持滚动更新，Deployment支持）
控制方式
创建pod指定类型为deployment时，deployment会创建一个对应的RS，由RS对pod进行管理（创建，回收）
滚动升级与回滚原理
升级：当进行应用升级时，会创建一个RS副本，在新的RS中逐渐创建新版本的Pod并将旧版本的逐渐减少，直至所有pod都转移到新的RS中，至此完成整个滚动更新
回滚：当新的RS中的pod难以到达目标并有回滚需求时，会将旧的处于停用的RS重新启动，并将其中的pod逐渐启动，并将新RS中的逐渐减少，直至完成回滚
扩容与缩容
暂停和继续 deployment
配置范例
apiVersion:apps/v1#API群组及版本
kind:Deployment#资源类型特有标识
metadata：
name <string>#资源名称，在作用域中要唯一
namespace <string>#名称空间；Deployment隶属名称空间级别
spec：
minReadySeconds <integer>#Pod就绪后多少秒内任一容器无crash方可视为“就绪”
replicas <integer>#期望的Pod副本数，默认为1
selector <object>#标签选择器，必须匹配template字段中Pod模板中的标签
template <object>#Pod模板对象
revisionHistoryLimit <integer>#滚动更新历史记录数量，默认为10
strategy <0bject>#滚动更新策略
type <string>#滚动更新类型，可用值有Recreate和Rollingupdate；
rollingUpdate <0bject>#滚动更新参数，专用于RollingUpdate类型
maxSurge <string>#更新期间可比期望的Pod数量多出的数量或比例
maxUnavailable <string>#更新期间可比期望的Pod数量缺少的数量或比例
progressDeadlineSeconds <integer>#滚动更新故障超时时长，默认为600秒
paused <boolean>#是否暂停部署过程
DaemonSet
确保全部/部分 node上运行一个pod的副本。可在node使用调度策略决定是否在node创建pod
当有新的node加入集群时，会为他新增此pod；当有node从集群移除时，这些pod也会被回收。
DaemonSet并非即时在所有node创建pod，而是在DaemonSet持续运行时动态持续创建指定pod
默认值为1，即一个daemonset只能定义一个pod，需求为多个时可以定义多个daemonset
删除daemonset时，daemonset会删除所有由他创建的pod
应用场景
-
运行集群存储 daemon ， 例如在每个 node 上运行 glusterd 、 ceph
-
在每个 node 上运行日志收集 daemon，例如 fluentd 、 logstash
-
在每个 node 上运行监控 daemon ，比如 zabbix，也可以通过 daemonset 去部署更便于我们去实现，因为他可以去确保每个 node 节点有且只有一个，哪怕 zabbix 死了以后也会被启动。
配置范例
apiVersion:batch/v1#API群组及版本
kind:DaemonSet#资源类型特有标识
metadata：
name<string>#资源名称，在作用域中要唯一
namespace <string>#名称空间；DaemonSet资源隶属名称空间级别
spec：
minReadySeconds <integer>#Pod就绪后多少秒内任一容器无crash方可视为“就绪”
selector <object>#标签选择器，必须匹配template字段中Pod模板中的标签
template <object>#Pod模板对象；
revisionHistoryLimit <integer>#滚动更新历史记录数量，默认为10；
updateStrategy <0bject>#滚动更新策略type <string>#滚动更新类型，可用值有0nDelete和RollingUpdate；
rollingupdate <0bject>#滚动更新参数，专用于RollingUpdate类型
maxunavailable <string>#更新期间可比期望的Pod数量缺少的数量或比例
Stateful Set
docker更适合的是运行无状态服务，对于有状态服务的解决方案是以存储卷去加载对应数据，k8s里有专门的有状态控制器
应用场景
-
稳定的持久化存储：即 pod 重新调度后还是能够访问到相同的持久化数据，基于 PVC 来实现。假设现在我有几个我们的容器，是被我们的 statefulset 去部署的，部署完成以后呢可能都用到了我 们同一个存储卷，假如有一天这个 pod 死亡了，但我们的 statefulset 为了维持这个副本数就会重 新创建对应的 pod ，这时候新创建的 pod 也会继续使用上一个 pod 退出时使用到的存储卷。也 就这里的持久化数据并不会丢失，这就是我们所谓的稳定的持久化存储方案。
-
稳定的网络标识：即 pod 重新调度以后其 pod name 和 host name 不变（这个很重要，在我们的很多服务里我们去创建对应的一些服务的链接方案的时候，都会以我们的 pod name 为链接对 象，或者 host name 为链接对象，如果我们的 pod 死亡被重新创建以后它的名称发生改变了这个 对于我们后面的自动化流程来说时非常不友好的。但是对于我们的 statefulset 来说它可以确保每 一个 pod 它的 pod name 和 host name 在 statefulset 生命周期里完全不变），基于 headless service 无头服务实现（也就是没有 cluster IP 的 service，可以理解为没有 IP 地址和端 口 ）来实现
-
有序部署，有序扩展：即 pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行 （即从 0 到 N1，在下一个 pod 运行之前所有的 pod 必须是 running 和 ready 状态），基于 init containers 来实现。这里需要注意以下为啥是基于 init containers 而不是基于我们所谓的 start 或 stop ，原因是不管是 start 、stop 他都需要去更改我们 pod 内部的容器镜像，但是对于 init containers 初始化容器来说是不需要更改的，只需要在statefulset 的 pod 里面的容器运行之前加 一个 init C ，并不会对我们的原有 pod 结构发生改变。所以这是他的解决方案怎么去实现这里的 running 和 ready。
-
有序收缩，有序删除（即从 N1 到 0）：会发现在扩展部署的时候是 0 到 N1 的，在删除的时候 N1 到 0 的，这是一个倒序关系。我们可以观察下图：
配置范例
apiVersion:apps/v1#API群组及版本；
kind:Statefulset#资源类型的特有标识
metadata：
name<string>#资源名称，在作用域中要唯一
namespace <string>#名称空间；StatefulSet隶属名称空间级别
spec：
replicas <integer>#期望的Pod副本数，默认为1
seleftor <object>#标签选择器，须匹配Pod模板中的标签，必选字段
template <object>#Pod模板对象，必选字段
revisionHistorylimit <integer>#滚动更新历史记录数量，默认为10
updateStrategy <0bject>#滚动更新策略
type <string>#滚动更新类型，可用值有0nDelete和Rollingupdate
rollingupdate <0bject>#滚动更新参数，专用于RollingUpdate类型
partition <integer>#分区指示索引值，默认为0
serviceName <string>#相关的Headless Service的名称，必选字段
volumeClaimTemplates <[]0bject>#存储卷申请模板
apiVersion <string>#PVC资源所属的API群组及版本，可省略
kind <string>#PVC资源类型标识，可省略
metadata <0bject>#卷申请模板元数据
spec <0biect>#期望的状态，可用字段同PVC
podManagementPolicy <string>#Pod管理策略，默认的“OrderedReady"表示顺序创建并逆序删除，另一可用值"Parallel”表示并行模式
Job
批处理任务，仅执行一次
多次执行：当脚本执行后正常退出，状态码为0，当状态码为0时计数+1，当状态码为非0时job会重新执行；定义当计数到3时，此job成功退出，则此时job完成
生命周期：运行至成功数目后结束
配置范例
apiVersion:batch/v1#API群组及版本
kind:Job#资源类型特有标识
metadata：
name<string>#资源名称，在作用域中要唯一
namespace <string>#名称空间；Job资源隶属名称空间级别
spec：
selector <object>#标签选择器，必须匹配template字段中Pod模板中的标签
template <object>#Pod模板对象
completions <integer>#期望的成功完成的作业次数，成功运行结束的Pod数量
ttlsecondsAfterFinished <integer>#终止状态作业的生存时长，超期将被删除
parallelism <integer>#作业的最大并行度，默认为1
backofflimit <integer>#将作业标记为Failed之前的重试次数，默认为6
activeDeadlineSeconds <integer>#作业启动后可处于活动状态的时长
CronJob
类似计划任务，定时执行job
使用前提：K8S集群版本必须大于1.8
注意项：创建cronjob指定的操作应该是幂等的，否则第二个job会影响第一个运行的pod；
cronjob是否成功难以判断，因为cronjob只会定期创建对应的job，无法知道job的成功与否
配置范例
apiVersion:batch/vlbetal#API群组及版本
kind:CronJob#资源类型特有标识
metadata：
name<string>#资源名称，在作用域中要唯一
namespace<string>#名称空间；CronJob资源隶属名称空间级别
spec：
jobTemplat <Object>#job作业模板，必选字段metadata <object>#模板元数据
spec <object>#作业的期望状态
schedule <string>#调度时间设定，必选字段
concurrencyPolicy <string>#并发策略，可用值有Allow、Forbid和Replace
failedJobsHistoryLimit <integer>#失败作业的历史记录数，默认为1
successfulJobsHistoryLimit <integer>#成功作业的历史记录数，默认为3
startingDeadlineSeconds <integer>#因错过时间点而未执行的作业的可超期时长
suspend <boolean>#是否挂起后续的作业，不影响当前作业，默认为false
