七、pod控制器-北京尧图网络

一、rc控制器和rs控制器1.1rc控制器ReplicationController# # ReplicationControllerRC控制器配置 # 作用确保集群中始终运行指定数量的 Pod 副本 # 注意RC 是较老版本的控制器新版本推荐使用 ReplicaSet 或 Deployment # apiVersion: v1 # RC 使用 v1 版本的 API不是 apps/v1 kind: ReplicationController # 资源类型ReplicationController metadata: name: rc-demo # RC 自身名称全局唯一 spec: # ----- 副本数量配置 ----- replicas: 3 # 期望运行的 Pod 数量集群会始终维持 3 个 # ----- 选择器重要 ----- # 作用定义 RC 管理哪些 Pod通过标签筛选 # 注意与 ReplicaSet 不同RC 的 selector 只支持简单的标签匹配不支持 matchLabels/matchExpressions # 这里的标签必须与 template.metadata.labels 完全一致 selector: app: rc-demo # 筛选出所有标签为 apprc-demo 的 Pod # ----- Pod 模板蓝图 ----- # 作用当需要创建新 Pod 时就按照这个模板生成 template: metadata: labels: # 为 Pod 打上标签必须覆盖 selector 中的标签 app: rc-demo # 这行就是 selector 要找的标签 spec: # Pod 内部规格定义 containers: - name: rc-demo-container # 容器名称 image: wangyanglinux/myapp:v1.0 # 容器镜像 # ----- 环境变量注入到容器内部 ----- # 作用将配置信息以 key-value 形式注入容器应用可通过 process.env 读取 env: - name: GET_HOSTS_FROM # 环境变量名 ① value: dns # 取值dns 表示服务发现优先使用 DNS - name: zhangsan # 环境变量名 ②示例自定义变量 value: 123 # 取值字符串 123 # ----- 容器端口声明 ----- # 作用声明容器监听哪个端口仅起文档/可视化作用不影响实际网络通信 ports: - containerPort: 80 # 应用监听 80 端口如 myapp 的 Web 服务1.2、rs控制器ReplicaSet# # ReplicaSet 控制器配置 # 作用确保集群中始终运行指定数量的 Pod 副本 # apiVersion: apps/v1 # 使用 apps 组 v1 版本的 API kind: ReplicaSet # 资源类型副本集控制器 metadata: name: rs-ml-demo # ReplicaSet 自身名称全局唯一 spec: # ----- 副本数量配置 ----- replicas: 3 # 期望运行的 Pod 数量集群会始终维持 3 个 # ----- 选择器重要 ----- # 作用定义 ReplicaSet 管理哪些 Pod通过标签筛选 # 注意此处的 labels 必须与 template 中定义的 labels 完全一致 selector: matchLabels: # 匹配标签规则只能使用 matchLabels不支持复杂的 matchExpressions app: rs-ml-demo # 筛选出所有标签为 apprs-ml-demo 的 Pod # ----- Pod 模板蓝图 ----- # 作用当需要创建新 Pod 时就按照这个模板生成 template: metadata: labels: # 为 Pod 打上标签必须覆盖 selector 中的标签 app: rs-ml-demo # 这行就是 selector 要找的标签 spec: # Pod 内部规格定义 containers: - name: rs-ml-demo-container # 容器名称 image: wangyanglinux/myapp:v1.0 # 容器镜像 # ----- 环境变量注入到容器内部 ----- # 作用将配置信息以 key-value 形式注入容器应用可通过 process.env 读取 env: - name: GET_HOSTS_FROM # 环境变量名 value: dns # 取值dns 表示服务发现优先使用 DNS常见于旧版 k8s 示例 # 备注此变量在较新版本的 Kubernetes 中已非必需属于历史遗留配置 # ----- 容器端口声明 ----- # 作用声明容器监听哪个端口仅起文档/可视化作用不影响实际网络通信 ports: - containerPort: 80 # 应用监听 80 端口如 myapp 的 Web 服务1.3、两者差别官方推荐使用rs控制器对比维度ReplicationController旧ReplicaSet新API 版本apiVersion: v1apiVersion: apps/v1标签选择器能力❌仅支持等值匹配keyvalue✅支持等值匹配集合式匹配selector 写法直接写app: rc-demo支持matchLabels和matchExpressions两种方式官方推荐❌ 已弃用不建议使用✅推荐使用但通常由 Deployment 自动管理实际用途历史遗留仅用于理解旧版概念作为 Deployment 的底层组件不单独使用1.4、rs控制器优势RS 除了支持matchLabels等值匹配外还支持matchExpressions提供更灵活的标签筛选能力。支持的 4 种操作符操作符含义示例In标签的值在指定的列表中筛选env为prod或test的 PodNotIn标签的值不在指定的列表中筛选env不为prod或test的 PodExists只要标签存在就匹配不关心值筛选所有带有disktype标签的 PodDoesNotExist标签不存在才匹配筛选所有不带disktype标签的 Pod下面是rs的特性演示举例# # ReplicaSet 示例 1使用 Exists 操作符 # 作用匹配所有带有 app 标签的 Pod不管值是什么 # apiVersion: apps/v1 kind: ReplicaSet metadata: name: rs-me-exists-demo spec: selector: matchExpressions: - key: app operator: Exists template: metadata: labels: app: spring-k8s spec: containers: - name: rs-me-exists-demo-container image: wangyanglinux/myapp:v1.0 ports: - containerPort: 80 --- # # ReplicaSet 示例 2使用 In 操作符 # 作用匹配 app 标签值在 [spring-k8s, hahahah] 列表中的 Pod # 注意当前 template 中 labels 为 app: sg-k8s不在 values 列表中 # 因此该 RS 实际无法匹配任何 Pod内容未改保持原样 # apiVersion: apps/v1 kind: ReplicaSet metadata: name: rs-me-in-demo spec: selector: matchExpressions: - key: app operator: In values: - spring-k8s - hahahah template: metadata: labels: app: spring-k8s spec: containers: - name: rs-me-in-demo-container image: wangyanglinux/myapp:v1.0 ports: - containerPort: 80所以问题来了为什么pod有标签了还需要使用控制器的标签因为现实角色K8s 组件它关心什么标签的作用不匹配的后果前台Service哪些员工能接待客户用标签找到“能接客”的 Pod把流量导给它Pod 收不到任何流量但容器仍在运行人事经理ReplicaSet我负责的岗位有没有招满 3 个人用标签找到“归我管”的 Pod少一个就补一个RS 认为自己没有 Pod会不断创建新的 Pod员工Pod自己是什么身份用标签template.labels表明“我是谁”没有标签的 Pod 就是“孤儿”没人管二、Deployment控制器Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义declarative方法用来替代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括➢ 定义 Deployment 来创建 Pod 和ReplicaSetdeployment管理rs➢ 滚动升级和回滚应用➢ 扩容和缩容➢ 暂停和继续 Deployment声明式和命令式是对立的声明性的东西是对终结果的陈述表明意图而不是实现它的过程。在Kubernetes中这就是说“应该有一个包含三个 Pod 的 ReplicaSet”。命令式充当命令。声明式是被动的而命令式是主动且直接的“创建一个包含三个 Pod 的 ReplicaSet”。# 1. 命令式强制替换不推荐# 作用用 YAML 里的内容直接强制替换集群中现有的 Deployment。# 特点如果资源不存在会报错。它会直接删除旧对象并创建新对象容易导致服务短暂中断。$ kubectl replace -f deployment.yaml# 2. 声明式计算差异并更新最推荐企业生产标准# 作用对比 YAML 期望状态与集群实际状态只更新有差异的部分。# 特点如果不存在则创建如果存在则平滑更新触发滚动更新。这是你之前遇到“警告”时用的命令补全了配置后就能正常用。$ kubectl apply -f deployment.yaml# 3. 辅助命令查看差异安全预检# 作用只显示 YAML 文件和集群中实际运行的资源有哪些区别不执行真正的修改。# 特点相当于“预演”一下 apply方便你确认无误后再执行真正的应用。$ kubectl diff -f deployment.yaml命令式和声明式区别# # 实验kubectl apply vs kubectl replace # 演示apply 保留未在 YAML 中声明的注解replace 会删除它 # # 1. 初始创建用 apply让它记录 last-applied-configuration kubectl apply -f 1.dplmt.yaml # 2. 手动给 Deployment 加一个额外注解模拟“YAML 中未声明的字段” kubectl annotate deployment myapp-deploy test-annotationhello --overwrite # 3. 修改 YAML 中的镜像为 v2.0 sed -i s/v1.0/v2.0/ 1.dplmt.yaml # 4. 用 apply 更新并检查注解是否存在 kubectl apply -f 1.dplmt.yaml echo apply 之后的注解情况 kubectl get deployment myapp-deploy -o jsonpath{.metadata.annotations} echo # 5. 重新加上注解修改 YAML 镜像为 v3.0再用 replace 更新 kubectl annotate deployment myapp-deploy test-annotationhello --overwrite sed -i s/v2.0/v3.0/ 1.dplmt.yaml kubectl replace -f 1.dplmt.yaml echo replace 之后的注解情况 kubectl get deployment myapp-deploy -o jsonpath{.metadata.annotations} echo # 6. 结论 # apply 之后注解仍然存在保留未声明字段 # replace 之后注解消失YAML 中没有就删除diff对比命令通过diff对比pod实体与yaml的区别[rootk8s-master01 deployment]# kubectl diff -f 1.dplmt.yaml diff -u -N /tmp/LIVE-3445901412/apps.v1.Deployment.default.myapp-deploy /tmp/MERGED-604905406/apps.v1.Deployment.default.myapp-deploy --- /tmp/LIVE-3445901412/apps.v1.Deployment.default.myapp-deploy 2026-09-14 10:27:15.676236826 0800 /tmp/MERGED-604905406/apps.v1.Deployment.default.myapp-deploy 2026-09-14 10:27:15.678236825 0800 -4,7 4,7 annotations: deployment.kubernetes.io/revision: 3 creationTimestamp: 2026-09-14T02:01:49Z - generation: 4 generation: 5 labels: app: myapp-deploy name: myapp-deploy -30,7 30,7 app: myapp-deploy spec: containers: - - image: wangyanglinux/myapp:v3.0 - image: wangyanglinux/myapp:v4.0 imagePullPolicy: IfNotPresent name: myapp resources: {} [rootk8s-master01 deployment]#deployment更新策略分为两种RollingUpdate滚动更新默认策略。先起新 PodReady 后删旧 Pod逐步替换服务不中断。Recreate重建先删掉所有旧 Pod再创建新 Pod服务会短暂中断。适合无法同时运行新旧版本的应用如数据库变更。Deployment 在升级时为了保证服务不中断零宕机会采用“滚动更新”的方式确保在升级过程中总是有一定数量的 Pod 保持可用。rollingUpdate的核心参数数含义通俗解释maxSurge指定超出期望副本数的 Pod 最大数量。支持数字和百分比。“多出来”的 Pod升级时最多允许比期望数量多启动几个新 Pod。maxUnavailable指定最多有几个 Pod 不可用。“少掉”的 Pod升级时最多允许同时停掉几个旧 Pod。案例案例1 #不写 strategy 字段时默认就是 RollingUpdatemaxSurge: 25%maxUnavailable: 25%。 apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deploy spec: replicas: 10 selector: matchLabels: app: myapp-deploy template: metadata: labels: app: myapp-deploy spec: containers: - image: wangyanglinux/myapp:v3.0 name: myapp 案例2 # 每次最多多起 1 个新 Pod保证服务绝对不中断 apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deploy spec: replicas: 10 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 # 每次最多多起 1 个新 Pod maxUnavailable: 0 # 保证服务绝对不中断 selector: matchLabels: app: myapp-deploy template: metadata: labels: app: myapp-deploy spec: containers: - image: wangyanglinux/myapp:v2.0 name: myapp 案例3指定重建策略服务会中断 apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deploy spec: replicas: 10 strategy: type: Recreate # 指定重建策略 selector: matchLabels: app: myapp-deploy template: metadata: labels: app: myapp-deploy spec: containers: - image: wangyanglinux/myapp:v1.0 name: myapp ~deployment常用命令创建 Deployment,record是记录更新操作的 kubectl create -f deployment.yaml --record 手动扩缩容 kubectl scale deployment nginx-deployment --replicas 10 自动扩缩容 (HPA) kubectl autoscale deployment nginx-deployment --min10 --max15 --cpu-percent80 --min10指定 Pod 副本数的最小值为 10。 --max15指定 Pod 副本数的最大值为 15。 --cpu-percent80设置目标 CPU 使用率阈值为 80%。当deployment的所有pod使用率超过 80% 时触发扩容低于时触发缩容。更新镜像 (滚动更新) kubectl set image deployment/nginx-deployment nginx-deployment-containerwangyanglinux/myapp:v2.0 版本回滚 kubectl rollout undo deployment/nginx-deployment构建过程中的命令# 1. 创建 Deployment kubectl apply -f 1.dplmt.yaml # 2. 查看初始状态1 个 RS10 个 Pod kubectl get rs kubectl get pod # 3. 修改 YAML把镜像 v1.0 改成 v2.0 sed -i s/v1.0/v2.0/ 1.dplmt.yaml # 4. 应用更新触发滚动更新 kubectl apply -f 1.dplmt.yaml # 5. 实时观察滚动更新过程 kubectl rollout status deployment/myapp-deploy # 6. 查看 RS 变化会出现两个 RS旧的 v1.0 和新的 v2.0 kubectl get rs # 7. 查看 Pod 变化旧 Pod 逐个减少新 Pod 逐个增加 kubectl get pod -w # 8. 查看滚动更新历史 kubectl rollout history deployment/myapp-deploy # 9. 验证新 Pod 的镜像版本 kubectl get pod -o jsonpath{.items[*].spec.containers[*].image}金丝雀更新策略金丝雀部署是“把新版本先给 1% 的人用如果没问题再逐步扩大给 100% 的人用”#1.0版本 apiVersion: apps/v1 kind: Deployment metadata: name: deployment-demo spec: replicas: 10 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 # 每次最多多起 1 个新 Pod maxUnavailable: 0 # 保证服务绝对不中断 selector: matchLabels: app: myapp-deploy template: metadata: labels: app: myapp-deploy spec: containers: - image: wangyanglinux/myapp:v1.0 name: myapp #apply启动 kubectl apply -f 3.deployment.yaml #金丝雀更新本来是10个老pod新增一个2.0的新pod然后停止意思就是新增一个2.0pod后就停止 #如果更新策略是默认的25%25%需要设置一下更新策略为10 kubectl patch deployment deployment-demo -p {spec:{strategy:{rollingUpdate:{maxSurge:1,maxUnavailable:0}}}} #开始金丝雀部署部署完会发现多一个2.0 kubectl patch deployment deployment-demo --patch {spec:{template:{spec:{containers:[{name:myapp,image:wangyanglinux/myapp:v2.0}]}}}} kubectl rollout pause deploy deployment-demo #如果2.0没问题我就可以批量把那10个都设置为2.0了 kubectl rollout resume deploy deployment-demo #现在我有10个2.0我现在再弄个10个2.0,1个3。0 #然后发现3.0有问题必须全部升级到3.0才可以回滚感觉这一块好傻 kubectl rollout resume deployment deployment-demo #回滚到2.0 kubectl rollout undo deployment deployment-demo --to-revision2 # 直接回到 v2.0 kubectl rollout undo deployment deployment-demo --to-revision1 # 直接回到 v1.0 注意 1、2、是 Deployment 的历史版本序号不是镜像1.0和2.0编号。如果不指定 --to-revisionkubectl rollout undo 默认只会回滚到当前版本的前一个 Revision并不会自动一路退到最早的 1.0。三、DaemonSet控制器DaemonSet 确保全部或者一些Node 上运行一个 Pod 的副本。当有 Node 加入集群时也会为他们新增一个 Pod。当有 Node 从集群移除时这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。使用 DaemonSet 的一些典型用法运行集群存储 daemon例如在每个 Node 上运行glusterd、ceph在每个 Node 上运行日志收集 daemon例如fluentd、logstash在每个 Node 上运行监控 daemon例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理或 Gangliagmond#DaemonSet就是让每个node节点有一个pod # 指定 K8s API 版本DaemonSet 属于 apps/v1 组 apiVersion: apps/v1 # 资源类型DaemonSet守护进程集 kind: DaemonSet # 元数据描述 DaemonSet 自身的信息 metadata: name: daemonset-demo # DaemonSet 的名字正确拼写 labels: # 给 DaemonSet 自己打的标签用于管理分类 app: daemonset-demo # 规格定义 DaemonSet 的行为 spec: # 选择器定义 DaemonSet 要管理哪些 Pod selector: matchLabels: name: deamonset-demo #这里必须与下面 template 里的 labels 完全一致 # 模板定义要在每个节点上创建的 Pod 长什么样 template: metadata: labels: name: deamonset-demo # 必须与上面的 selector 保持一致 spec: containers: - name: daemonset-demo-container # 容器的名字 image: wangyanglinux/myapp:v1.0 # 容器使用的镜像 #生成pod [rootk8s-master01 daemonSet]# kubectl apply -f 1.DaemonSet.yaml daemonset.apps/daemonset-demo created [rootk8s-master01 daemonSet]# #查看每个机器上有一个pod [rootk8s-master01 daemonSet]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES daemonset-demo-5q7t2 1/1 Running 0 11s 10.244.85.206 k8s-node01 none none daemonset-demo-n76h4 1/1 Running 0 11s 10.244.58.222 k8s-node02 none none四、Job 控制器Job 是 Kubernetes 中用于运行一次性任务的控制器。它确保指定数量的 Pod成功完成而不是像 Deployment 那样持续保持运行。核心特点Pod 执行完任务后正常退出状态变为CompletedJob 不会重新创建它。如果 Pod 失败Job 会根据restartPolicy决定是否重试。适用于批处理、数据迁移、备份、报表生成等一次性的工作。特殊说明:spec.template 格式同 PodRestartPolicy 仅支持 Never永不重启或 OnFailure重启直到成功返回0单个 Pod 时默认 Pod 成功运行后 Job 即结束spec.completions 标志 Job 结束需要成功运行的 Pod 个数默认为 1spec.parallelism 标志并行运行的 Pod 的个数默认为 1spec.activeDeadlineSeconds 标志失败 Pod 的重试最大时间超过这个时间不会继续重试五、cronjob控制器CronJob周期性的创建Job典型的场景数据库的周期性备份.·apiVersion: batch/v1 kind: CronJob metadata: name: cronjob-demo spec: schedule: */1 * * * * jobTemplate: spec: template: spec: containers: - name: cronjob-demo-container image: busybox args: - /bin/sh - -c - date; echo Hello from the kubernetes cluster restartPolicy: OnFailure六、控制器区别守护进程类型控制器RC 控制器保障当前的 Pod 数量与期望值一致RS 控制器功能与 RC 控制器类似但是多了标签选择的运算方式Deployment支持了声明式表达支持滚动更新和回滚原理deployment RS podDaemonSet保障每个节点有且只有一个 Pod 的运行动态批处理任务的类型Job保障批处理任务一个或多个成功为止CronJob周期性的创建Job典型的场景数据库的周期性备份.·控制器核心职责干什么的理发店系统中的对应场景ReplicaSet (RS)只保证 Pod 数量够不管更新基本不用被 Deployment 替代Deployment管无状态应用Web、API支持滚动更新/回滚前端、后端 API 服务DaemonSet保证每个节点跑一个 Pod日志收集、监控 Agent、网络插件Job / CronJob一次性任务、定时任务每日销售报表、数据库备份

七、pod控制器

相关推荐

C++反射机制实现与应用深度解析

Stable Diffusion底层原理：CLIP、潜在扩散与UNet协同机制解析

算法竞赛中的概率期望与动态规划解题技巧

更多资讯

Cangjie 标准库 std.net 实战：用 UnixDatagramSocket 实现进程间数据报通信

机器学习论文太多看不过来？一套高效筛选与精读方法论

Tai 时间追踪：别再靠感觉估算工时

js-xlsx指南：Excel读取导出、合并单元格与公式写入避坑实战

UE5 C++变量类型全解析：从值语义到UObject生命周期

帝国CMS后台轻松保留Word图文混排：粘贴配置与常见问题排查

今日更新

防关联浏览器哪个好？三款产品实测差异解析

2026钢铁行业AI转型系统选型对比：多基地排产、大宗原燃料采购与质量追溯，六家厂商能力差异在哪里

影刀RPA深度实战：大模型Fine-tuning定制RPA专用Prompt与指令生成

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？