Kubenetes控制器

一.控制器简介

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

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

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

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

二.控制器

1.Replicaset控制器

你就把 ReplicaSet（副本控制器） 当成一个看场子的监工。

1、它是干啥的？

你告诉它：我这里要一直跑 3 个一模一样的 Pod（容器程序）。它就 24 小时盯着这 3 个 Pod。

如果 1 个 Pod 崩了、删掉了 → 它马上新起一个补上，永远凑够 3 个
如果你手动改成要 5 个 → 它就再多开 2 个
如果你改成只要 1 个 → 多余的就直接关掉

核心任务：保证时时刻刻，运行的 Pod 数量 = 你想要的数量

2、和老版本 ReplicationController 的区别

RC 是旧版监工，选人的标签条件很死板； ReplicaSet 是升级版监工，筛选 Pod 的规则更灵活，可以用集合条件匹配。所以官方已经放弃老的 RC，推荐用 ReplicaSet。

3、但是！平时我们几乎不会直接用它

生产环境没人直接创建 ReplicaSet。 Deployment（部署）才是老板，ReplicaSet 是老板手下干活的员工。

流程：

你操作 Deployment → Deployment 去创建、管理 ReplicaSet → ReplicaSet 再去管一堆 Pod

Deployment 负责版本升级、回滚；ReplicaSet 只管保副本数量。

一句话总结

ReplicaSet = 专职保镖，只管守住 Pod 副本数量不掉线；一般被 Deployment 调用干活，很少单独出场。

实验

bash 复制代码

[root@master controler]# kubectl create deployment webcluster --image myapp:v1  --dry-run=client -o yaml  > repset.yml

[root@master controler]# vim repset.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  labels:
    app: webcluster
  name: webcluster
spec:
  replicas: 2       #控制pod可随意调整
  selector:
    matchLabels:
      app: webcluster

  template:
    metadata:
      labels:
        app: webcluster
    spec:
      containers:
      - image: myapp:v1
        name: myapp

[root@master controler]# kubectl apply -f repset.yml

#打开一个新的shell
[root@master ~]# watch -n 1 kubectl get pods   --show-labels

2.Deployment控制器

把整个关系比作老板‑包工头‑工人

Deployment（老板）：就是 Deployment
ReplicaSet（包工头）：ReplicaSet
Pod（干活工人）：Pod

1、它是干啥的

Deployment不会直接去管 Pod。老板不会直接指挥工人干活。老板（Deployment）先找一个包工头（ReplicaSet），然后包工头再去管一群工人 (Pod)。

命令只需要发给 Deployment 就行，你告诉他：

我要运行 3 个一模一样的程序，版本是 v1

Deployment 就会创建一个 ReplicaSet，ReplicaSet 再去启动 3 个 Pod。

2、升级更新（最核心功能）

现在你要升级成 v2 版本： Deployment不会直接修改旧的 Pod。

Deployment 新建一个新的 ReplicaSet（新版本包工头）
新包工头慢慢开出新版 Pod
再慢慢关掉旧包工头手下的旧 Pod
升级完成，旧 ReplicaSet 不会立刻删掉，留着当备份

每一个 ReplicaSet 就代表一个版本！想回滚？Deployment 直接重新启用之前旧的 ReplicaSet 就一键降级。

3、声明式管理

白话：你只写好你最终想要长啥样，不用管中间怎么一步步实现。你写配置：最终 3 个 v2 的 Pod。剩下扩容、升级、换版本全部交给 k8s 自己去干。

4、一句话总结

Deployment 就是管版本升级、回滚的大总管 ，它指挥 ReplicaSet 干活，ReplicaSet 负责守住 Pod 数量。平时工作中，99% 的业务项目直接用 Deployment，不直接创建 ReplicaSet。

实验

bash 复制代码

[root@master controler]# kubectl create deployment webcluster --image myapp:v1  --dry-run=client -o yaml  > dep.yml
[root@master controler]# vim dep.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: webcluster
  name: webcluster
spec:
  minReadySeconds: 5
  replicas: 2
  selector:
    matchLabels:
      app: webcluster

  template:
    metadata:
      labels:
        app: webcluster
    spec:
      containers:
      - image: myapp:v1
        name: myapp


[root@master controler]# kubectl apply -f dep.yml

bash 复制代码

[root@master controler]# kubectl expose deployment webcluster --port 80 --target-port 80
[root@master controler]# kubectl describe  services webcluster

[root@master controler]# curl  10.106.107.142

升级和回滚

bash 复制代码

[root@master controler]# vim dep.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: webcluster
  name: webcluster
spec:
  minReadySeconds: 5
  replicas: 2
  selector:
    matchLabels:
      app: webcluster

  template:
    metadata:
      labels:
        app: webcluster
    spec:
      containers:
      - image: myapp:v2
        name: myapp
[root@master controler]# kubectl apply -f dep.yml

3.Daemonset控制器

咱们先打个比方：集群里有一堆节点（服务器） 。 DaemonSet 就像一个监工，要求每一台服务器上，都必须跑指定的那一个 Pod。

1、它是干什么的？

Deployment：只管一共要 N 个 Pod，Pod 随机跑到集群任意服务器上，一台机器可以跑好多个，也可以一个都不跑
DaemonSet：每一个节点，有且只能启动 1 个目标 Pod 只要新加一台服务器进集群，DaemonSet 自动就在这台新机器上部署这个 Pod；服务器下线了，对应的 Pod 也就跟着删掉。

2、举几个生活里最常见的例子

适合放 DaemonSet 的程序，一般都是每台服务器都得装一个的后台工具：

日志采集程序（如 filebeat）：每台机器都要收集本机日志
监控代理（如 prometheus‑node‑exporter）：每台机器上报自身性能数据
网络插件：集群网络组件，每个节点必须部署

这类程序就不能用 Deployment，你不能控制它刚好每台机器一个。

3、DaemonSet 能不能升级、回滚？

可以。更新 DaemonSet，它就会逐个节点把旧 Pod 删掉，换上新版本 Pod。

4、一句话总结

Deployment：我一共要 5 个 Pod，放哪台机器无所谓。 DaemonSet：每一台节点，都必须有且仅有一个 Pod。

实验

bash 复制代码

[root@master controler]# kubectl create deployment daemonset --image myapp:v1 --dry-run=client -o yaml  > daemonset.yml
[root@master controler]# vim daemonset.yml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app: daemonset
  name: daemonset
spec:
  selector:
    matchLabels:
      app: daemonset
  template:
    metadata:
      labels:
        app: daemonset
    spec:
      containers:
      - image: myapp:v1
        name: myapp



#实验中有多少nodes就会产生多少pods，pods会随着nodes上线而上线，下线而下线

4.Job 控制器

比喻

Deployment、DaemonSet 都是长期上班、永不下班 的程序（日志、网站、监控，一直跑着）。 Job 是一次性任务，干完活就下班，程序跑完就结束。

通俗解释

Job 的作用：创建 Pod，让它执行一次性任务，任务执行完成就正常退出，不需要一直重启。

你提交一个 Job，k8s 启动 Pod 跑任务
任务成功跑完（进程正常退出）→ Pod 标记完成，不会重新启动
如果中途失败报错崩溃了 → Job 会自动新建一个 Pod，重新重试执行任务，直到任务成功

重点区别

Deployment：Pod 挂了→立刻重启，永远保持运行（长驻服务）
Job：任务做完就收工；失败才重启，成功就不再跑了（一次性任务）

适合干什么活

一次性、定时跑完就完事的工作：

数据库备份
批量数据计算
文件迁移
报表导出

Job 小局限

Job 只能跑一次性任务 ；如果你想周期性、每天 / 每周定时跑任务，Job 不行，要用 CronJob（定时任务）

5.CronJob控制器

比喻

Job = 临时工，来了干一次活就走，干完下班，手动触发才执行。
CronJob = 定时钟点工，到点自动上班，循环反复执行任务。

通俗解释

CronJob 就是 k8s 里的定时任务，相当于 Linux 的 crontab。你写好时间表，到了规定时间，它就自动生成一个 Job，由 Job 去启动 Pod 干活。

执行流程：

CronJob 到预定时间 → 创建 Job
Job 创建 Pod，执行一次性任务
任务跑完结束，Pod 退出
等到下一个时间点，再重新生成 Job，再来一遍

典型使用场景

每天凌晨 2 点数据库备份
每小时清理一遍过期日志
每周一早上生成业务报表

和 Job 的核心对比

Job：手动跑一次，一次性任务，不会重复
CronJob：按周期重复跑，自动定时执行

需要注意的坑

到点如果上一轮任务还没跑完，有可能出现新旧两个任务同时并行运行
CronJob 只管按时生成 Job，任务失败重试这件事，还是交给 Job 自己控制

一句话总结

Job 干一次；CronJob 定时反复干，到点自动召唤 Job 出来干活

三.总结

控制器名称	控制器用途
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水平自动缩放

Deployment：长驻业务，负责升级回滚
ReplicaSet：只管副本数量，很少单独用
DaemonSet：每个节点，必跑一个 Pod
Job：一次性临时任务，干完即停
CronJob：定时循环任务，按时召唤 Job