k8s中的控制器的使用

一 什么是控制器

控制器也是管理pod的一种手段

• 自主式pod：pod退出或意外关闭后不会被重新创建

• 控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目

Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod

当建立控制器后，会把期望值写入etcd，k8s中的apiserver检索etcd中我们保存的期望状态，并对比pod的当前状态，如果出现差异代码自驱动立即恢复

二 控制器常用类型

控制器名称	控制器用途
Replication Controller	比较原始的pod控制器，已经被废弃，由ReplicaSet替代
ReplicaSet	ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行
Deployment	一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力
DaemonSet	DaemonSet 确保全指定节点上运行一个 Pod 的副本
StatefulSet	StatefulSet 是用来管理有状态应用的工作负载 API 对象。
Job	执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束
CronJob	Cron Job 创建基于时间调度的 Jobs。
HPA全称Horizontal Pod Autoscaler	根据资源利用率自动调整service中Pod数量，实现Pod水平自动缩放

三 replicaset控制器

3.1 replicaset功能

• ReplicaSet 是下一代的 Replication Controller，官方推荐使用ReplicaSet

• ReplicaSet和Replication Controller的唯一区别是选择器的支持，ReplicaSet支持新的基于集合的选择器需求

• ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行

• 虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制

3.2 replicaset参数说明

参数名称	字段类型	参数说明
spec	Object	详细定义对象，固定值就写Spec
spec.replicas	integer	指定维护pod数量
spec.selector	Object	Selector是对pod的标签查询，与pod数量匹配
spec.selector.matchLabels	string	指定Selector查询标签的名称和值，以key：value方式指定
spec.template	Object	指定对pod的描述信息，比如lab标签，运行容器的信息等
spec.template.metadata	Object	指定pod属性
spec.template.metadata.labels	string	指定pod标签
spec.template.spec	Object	详细定义对象
spec.template.spec.containers	list	Spec对象的容器列表定义
spec.template.spec.containers.name	string	指定容器名称
spec.template.spec.containers.image	string	指定容器镜像

3.3 replicaset 示例

#replicaset是通过标签匹配pod

修改标签后

#恢复标签后

#replicaset自动控制副本数量，pod可以自愈

replicaset无法更新版本所以需要用到deployment控制器

四 deployment 控制器

4.1 deployment控制器的功能

• 为了更好的解决服务编排的问题，kubernetes在V1.2版本开始，引入了Deployment控制器。

• Deployment控制器并不直接管理pod，而是通过管理ReplicaSet来间接管理Pod

• Deployment管理ReplicaSet，ReplicaSet管理Pod

• Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法

• 在Deployment中ReplicaSet相当于一个版本

典型的应用场景：

• 用来创建Pod和ReplicaSet

• 滚动更新和回滚

• 扩容和缩容

• 暂停与恢复

4.2 deployment控制器示例

版本迭代

#pod运行容器版本为v1

更新的过程是重新建立一个版本的RS，新版本的RS会把pod 重建，然后把老版本的RS回收

测试：

版本回滚

滚动更新策略

暂停及恢复

在实际生产环境中我们做的变更可能不止一处，当修改了一处后，如果执行变更就直接触发了

我们期望的触发时当我们把所有修改都搞定后一次触发暂停，避免触发不必要的线上更新

暂停滚动更新

做资源限制

#调整副本数，不受影响

root@master pod\]# kubectl describe pods deployment-5f4d6b95df-7fzmb Name: deployment-5f4d6b95df-7fzmb Namespace: default Priority: 0 Service Account: default Node: k8snode1/192.168.10.10 Start Time: Wed, 12 Mar 2025 16:09:18 +0800 Labels: app=myapp pod-template-hash=5f4d6b95df Annotations: \ Status: Running IP: 10.244.1.14 IPs: IP: 10.244.1.14 Controlled By: ReplicaSet/deployment-5f4d6b95df Containers: myapp: Container ID: docker://f414b15cd85f4d034d57b88c4d9aefd6f1699794b1852ff1113dd3af4ba5e00e Image: reg.timinglee.org/library/myapp:v1 Image ID: docker-pullable://reg.timinglee.org/library/myapp@sha256:9eeca44ba2d410e54fccc54cbe9c021802aa8b9836a0bcf3d3229354e4c8870e Port: \ Host Port: \ State: Running Started: Wed, 12 Mar 2025 16:09:18 +0800 Ready: True Restart Count: 0 Environment: \ Mounts: /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-n2sdf (ro) Conditions: Type Status PodReadyToStartContainers True Initialized True Ready True ContainersReady True PodScheduled True Volumes: kube-api-access-n2sdf: Type: Projected (a volume that contains injected data from multiple sources) TokenExpirationSeconds: 3607 ConfigMapName: kube-root-ca.crt ConfigMapOptional: \ DownwardAPI: true QoS Class: BestEffort Node-Selectors: \ Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 21m default-scheduler Successfully assigned default/deployment-5f4d6b95df-7fzmb to k8snode1 Normal Pulled 21m kubelet Container image "reg.timinglee.org/library/myapp:v1" already present on machine Normal Created 21m kubelet Created container myapp Normal Started 21m kubelet Started container myap

#但是更新镜像和修改资源并没有触发更新

#恢复后开始触发更新

五 daemonset控制器

5.1 daemonset功能

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时， 也会为他们新增一个 Pod ，当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod

DaemonSet 的典型用法：

• 在每个节点上运行集群存储 DaemonSet，例如 glusterd、ceph。

• 在每个节点上运行日志收集 DaemonSet，例如 fluentd、logstash。

• 在每个节点上运行监控 DaemonSet，例如 Prometheus Node Exporter、zabbix agent等

• 一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用

• 一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求

5.2 daemonset 示例

六 job 控制器

6.1 job控制器功能

Job，主要用于负责批量处理(一次要处理指定数量任务)短暂的一次性(每个任务仅运行一次就结束)任务

Job特点如下：

• 当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量

• 当成功结束的pod达到指定的数量时，Job将完成执行

6.2 job 控制器示例：

• 如果指定为OnFailure，则job会在pod出现故障时重启容器

  而不是创建pod，failed次数不变

• 如果指定为Never，则job会在pod出现故障时创建新的pod

  并且故障pod不会消失，也不会重启，failed次数加1

• 如果指定为Always的话，就意味着一直重启，意味着job任务会重复去执行了

七 cronjob 控制器

7.1 cronjob 控制器功能

• Cron Job 创建基于时间调度的 Jobs。

• CronJob控制器以Job控制器资源为其管控对象，并借助它管理pod资源对象，

• CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。

• CronJob可以在特定的时间点(反复的)去运行job任务

7.2 cronjob 控制器 示例

区别

CronJob 控制器和 Job 控制器都用于处理批处理任务，但它们在功能、使用场景、执行方式等方面存在明显区别，下面为你详细介绍：

1. 功能定位

• Job 控制器
  • Job 控制器的主要功能是创建一个或多个 Pod 来执行特定的任务，直到达到指定的成功完成次数。一旦任务完成（所有 Pod 成功执行并退出），Job 就会被标记为完成状态。它专注于确保任务在集群中可靠地执行一次或多次。
• CronJob 控制器
  • CronJob 控制器是基于 Job 控制器构建的，它增加了按时间调度的功能。CronJob 可以按照指定的时间间隔（如每分钟、每小时、每天等）定期创建 Job，从而实现任务的周期性执行。

2. 使用场景

• Job 控制器
  • 一次性任务 ：适用于只需要执行一次的任务，例如数据迁移、批量数据处理、备份任务等。比如，将旧数据库中的数据迁移到新数据库，这种任务通常只需要执行一次，使用 Job 可以确保任务成功完成。
  • 多次执行但无时间规律 ：当需要执行多次相同的任务，但这些任务之间没有特定的时间间隔要求时，可以使用 Job 并设置 spec.completions 来指定任务需要成功完成的次数。
• CronJob 控制器
  • 周期性任务 ：适合需要定期执行的任务，如每天凌晨进行数据备份、每小时收集系统监控数据、每分钟清理临时文件等。通过 CronJob 可以方便地按照预定的时间计划执行这些任务。