目录

k8s中的控制器的使用

k8s中的控制器的使用

一 什么是控制器

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

  • 自主式pod:pod退出或意外关闭后不会被重新创建
  • 控制器管理的 Pod:在控制器的生命周期里,始终要维持 Pod 的副本数目

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

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

二 控制器常用类型

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

三 replicaset控制器

https://i-blog.csdnimg.cn/direct/8a981d11c67b4299b2c92cbd3eb0266a.png

3.1 replicaset功能

  • ReplicaSet 是下一代的 Replication Controller,官方推荐使用ReplicaSet
  • ReplicaSet和Replication Controller的唯一区别是选择器的支持,ReplicaSet支持新的基于集合的选择器需求
  • ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行
  • 虽然 ReplicaSets 可以独立使用,但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制

3.2 replicaset参数说明

参数名称字段类型参数说明
specObject详细定义对象,固定值就写Spec
spec.replicasinteger指定维护pod数量
spec.selectorObjectSelector是对pod的标签查询,与pod数量匹配
spec.selector.matchLabelsstring指定Selector查询标签的名称和值,以key:value方式指定
spec.templateObject指定对pod的描述信息,比如lab标签,运行容器的信息等
spec.template.metadataObject指定pod属性
spec.template.metadata.labelsstring指定pod标签
spec.template.specObject详细定义对象
spec.template.spec.containerslistSpec对象的容器列表定义
spec.template.spec.containers.namestring指定容器名称
spec.template.spec.containers.imagestring指定容器镜像

3.3 replicaset 示例

https://i-blog.csdnimg.cn/direct/e23151876dd94aa5b0db6d537b116073.png

https://i-blog.csdnimg.cn/direct/68f08a3f78d0480592a943f5f5911c00.png

https://i-blog.csdnimg.cn/direct/26e9a61ab21f4959820e7f6ad535529b.png

#replicaset是通过标签匹配pod

修改标签后

https://i-blog.csdnimg.cn/direct/eb7b3ecd3a364a4c8b55281a764f9963.png

#恢复标签后

https://i-blog.csdnimg.cn/direct/c5ccea00ed9d494ebaed217a7047034c.png

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

https://i-blog.csdnimg.cn/direct/d2421d12f5574defaee13df55d93fe9e.png

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

四 deployment 控制器

4.1 deployment控制器的功能

https://i-blog.csdnimg.cn/direct/9e2e7350b16044caa1d77140e19d8173.png

  • 为了更好的解决服务编排的问题,kubernetes在V1.2版本开始,引入了Deployment控制器。
  • Deployment控制器并不直接管理pod,而是通过管理ReplicaSet来间接管理Pod
  • Deployment管理ReplicaSet,ReplicaSet管理Pod
  • Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法
  • 在Deployment中ReplicaSet相当于一个版本

典型的应用场景:

  • 用来创建Pod和ReplicaSet
  • 滚动更新和回滚
  • 扩容和缩容
  • 暂停与恢复

4.2 deployment控制器示例

https://i-blog.csdnimg.cn/direct/aeecc3da03e841a8a586b33d99399949.png

https://i-blog.csdnimg.cn/direct/f80afce68bf4472092f7a627bf5f8fb5.png

版本迭代

https://i-blog.csdnimg.cn/direct/7737475521b247a5a237b1e24e84cc87.png

https://i-blog.csdnimg.cn/direct/8569cd78789d4952b361b9e579bc774f.png

#pod运行容器版本为v1

https://i-blog.csdnimg.cn/direct/737e257e621545e892351e3d182948c6.png

https://i-blog.csdnimg.cn/direct/0a86f581bf3545c2a0b918d7b05efd83.png

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

测试:

https://i-blog.csdnimg.cn/direct/4330812fc20a42dc8da27fe88c3f8329.png

https://i-blog.csdnimg.cn/direct/0fd4c7c3b1a3482083340b40d56dc01f.png

版本回滚

https://i-blog.csdnimg.cn/direct/38565e9a1c23474d9d61f77e8c4b2eed.png

https://i-blog.csdnimg.cn/direct/df067fec7d244ae6bfb43a08ea75727a.png

滚动更新策略

https://i-blog.csdnimg.cn/direct/ea8e5347e17f46f399f339ef1ba5a343.png

https://i-blog.csdnimg.cn/direct/e0223961a2e44f30bc31ae9f634f2061.png

暂停及恢复

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

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

暂停滚动更新

https://i-blog.csdnimg.cn/direct/aaa103c28956418bbdd474142f63b9f9.png

做资源限制

https://i-blog.csdnimg.cn/direct/7f72820ecc3743d9bd684275c11244e7.png

https://i-blog.csdnimg.cn/direct/d243b85d7f764343adfb1e4991d9a4c4.png

#调整副本数,不受影响

[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 +08:00

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 +08:00

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

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

#恢复后开始触发更新

https://i-blog.csdnimg.cn/direct/6944b8f12c5642aba4b6e076c99cd83e.png

https://i-blog.csdnimg.cn/direct/ba8184388feb41258e87478844a404d1.png

五 daemonset控制器

5.1 daemonset功能

https://i-blog.csdnimg.cn/direct/26fa217177474240939dddd4c69cd5d0.png

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 示例

https://i-blog.csdnimg.cn/direct/1521e1e7475e40ca988c213aae871eb3.png

https://i-blog.csdnimg.cn/direct/8ef491661d7c4c69a13d458c6ae8b1d9.png

六 job 控制器

6.1 job控制器功能

https://i-blog.csdnimg.cn/direct/ee55eb9c9cd44f4c9f79b4c565b5bb84.png

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

Job特点如下:

  • 当Job创建的pod执行成功结束时,Job将记录成功结束的pod数量
  • 当成功结束的pod达到指定的数量时,Job将完成执行

6.2 job 控制器示例:

https://i-blog.csdnimg.cn/direct/e0db1edb088247628fab93bdbd1fc7e2.png

https://i-blog.csdnimg.cn/direct/480693a843ef4f6192168ed9ba875819.png

https://i-blog.csdnimg.cn/direct/21fa49bd317b4d5fb59864597dc47dd8.png

https://i-blog.csdnimg.cn/direct/7184569e428c4b88a745fd665f4a837f.png

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

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

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

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

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

七 cronjob 控制器

7.1 cronjob 控制器功能

https://i-blog.csdnimg.cn/direct/f7ec26a031c448d3b5c5f1202d49ddf3.png

  • Cron Job 创建基于时间调度的 Jobs。
  • CronJob控制器以Job控制器资源为其管控对象,并借助它管理pod资源对象,
  • CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。
  • CronJob可以在特定的时间点(反复的)去运行job任务

7.2 cronjob 控制器 示例

https://i-blog.csdnimg.cn/direct/9e76a7b69a3d4e3ebb9666c5d2b207e9.png

https://i-blog.csdnimg.cn/direct/9fca917634694afca8e4fd0d0c08d72e.png

区别

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

1. 功能定位

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

2. 使用场景

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