61 K8s之Pod控制器与配置资源管理

文章目录

• 前言
• 理论部分
• • 1_Pod控制器概述
  • • 1.1_控制器核心功能
    • 1.2_控制器类型与适用场景
  • 2_Deployment控制器
  • • 2.1_核心特性
    • 2.2_工作原理
    • 2.3_关键配置参数
  • 3_StatefulSet控制器
  • • 3.1_核心特性
    • 3.2_依赖核心组件
    • 3.3_网络标识机制
  • 4_DaemonSet控制器
  • • 4.1_核心功能
  • 5_Job控制器
  • • 5.1_核心参数
  • 6_CronJob控制器
  • • 6.1_核心参数
  • 7_无状态与有状态应用对比
  • [8_常规Service与Headless Service对比](#8_常规Service与Headless Service对比)
  • 9_Secret配置管理
  • • 9.1_Secret类型
  • 10_ConfigMap配置管理
  • • 10.1_核心特性
• 实验部分
• • 1_Deployment控制器实验
  • • 1.1_创建Deployment
    • 1.2_滚动更新与回滚
  • 2_StatefulSet控制器实验
  • • [2.1_创建Headless Service](#2.1_创建Headless Service)
    • 2.2_创建StatefulSet
    • 2.3_Pod名称解析测试
  • 3_DaemonSet控制器实验
  • 4_Job控制器实验
  • • 4.1_基础Job示例
    • 4.2_失败重试限制
  • 5_CronJob控制器实验
  • 6_Secret配置管理实验
  • • 6.1_命令行创建Secret
    • 6.2_YAML方式创建Secret
    • 6.3_Secret使用方式
    • • [① 挂载为文件](#① 挂载为文件)
      • [② 注入环境变量](#② 注入环境变量)
  • 7_ConfigMap配置管理实验
  • • 7.1_创建ConfigMap
    • 7.2_ConfigMap使用方式
    • • [① 环境变量注入](#① 环境变量注入)
      • [② 卷挂载方式](#② 卷挂载方式)
      • [③ 触发滚动更新](#③ 触发滚动更新)
• 结语

前言

本文档系统梳理Kubernetes中Pod控制器类型及其配置资源管理机制，涵盖无状态/有状态应用部署方案、Secret与ConfigMap配置管理等核心内容。本文档重点包括：控制器功能特性对比、资源配置操作规范及企业级应用场景实现方案。

1. 什么是Pod控制器
2. Pod控制器多个类型（ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、CronJob）
3. Pod控制器之间的关系

理论部分

1_Pod控制器概述

Pod控制器(Controller) 又称为工作负载(Workload) ，是Kubernetes中用于管理Pod的中间层，职责是确保集群中的Pod资源始终符合用户定义的"期望状态"。

1.1_控制器核心功能

• 保证Pod副本数量与期望一致
• Pod异常退出时自动按重启策略重建
• 支持伸缩（扩容/缩容）、滚动更新、回滚操作

1.2_控制器类型与适用场景

控制器类型	是否有状态	功能简述	典型场景
ReplicaSet	❌	保证指定数量Pod副本存在	通常由Deployment管理
Deployment	❌	声明式部署、滚动升级、回滚	Web服务
StatefulSet	✅	有状态应用，稳定网络标识与存储	数据库、Zookeeper
DaemonSet	❌	每个Node上运行一个Pod	日志、监控、Agent
Job	❌	执行一次性任务	批处理、数据库迁移
CronJob	❌	周期性任务（类似Crontab）	定期备份、通知

2_Deployment控制器

声明式无状态应用部署方案，通过管理ReplicaSet实现应用生命周期管控。

2.1_核心特性

• 与ReplicaSet协作管理无状态应用
• 支持滚动更新与回滚机制
• 实现声明式配置更新管理

2.2_工作原理

Deployment与ReplicaSet关系
声明期望状态
滚动升级策略
创建新ReplicaSet
缩容旧Pod
Deployment
ReplicaSet
Pod 1
Pod 2
Pod N
配置更新
ReplicaSet v2
新Pod 1
新Pod 2
终止旧Pod

2.3_关键配置参数

Deployment配置核心字段

• replicas：期望的Pod副本数量（默认1）
• selector.matchLabels：Pod选择器标签
• spec.strategy.rollingUpdate：滚动更新参数
  • maxSurge：升级中允许超出期望Pod数量的比例（默认25%）
  • maxUnavailable：升级中可不可用的Pod数量比例（默认25%）
• spec.template：Pod模板定义区域

3_StatefulSet控制器

专为有状态应用设计的控制器，提供稳定网络标识和持久化存储。

3.1_核心特性

StatefulSet三大核心特点 ：

① 稳定存储 ：基于PVC实现每个Pod独立存储

② 稳定网络标识 ：Pod名称和DNS名称固定（格式：<pod-name>.<service-name>.<namespace>.svc.cluster.local）

③ 有序操作：按0→N-1顺序部署，N-1→0顺序删除

3.2_依赖核心组件

StatefulSet三大支柱

组件	必要性	作用说明
Headless Service	✅	为Pod生成可解析的DNS记录，解除Pod名称与ClusterIP关联
volumeClaimTemplates	✅	动态生成PVC，为每个Pod提供专属存储卷
StatefulSet控制器本身	✅	管控Pod生命周期，确保拓扑状态稳定性

3.3_网络标识机制

Pod服务发现原理
依赖
StatefulSet
Headless Service
PVC独立存储
Pod-0
myapp-0.myapp-svc.default.svc.cluster.local
Pod-1
myapp-1.myapp-svc.default.svc.cluster.local
Pod-2
myapp-2.myapp-svc.default.svc.cluster.local

4_DaemonSet控制器

确保集群每个Node上运行一个Pod副本的控制器。

4.1_核心功能

DaemonSet应用场景：

• 系统级后台任务：日志收集器（Fluentd/Logstash）
• 监控代理：Prometheus Node Exporter、collectd
• 节点存储服务：Ceph、GlusterFS
• 网络插件：Calico、Flannel

官方文档

5_Job控制器

用于执行一次性任务的控制器

5.1_核心参数

Job关键配置参数

• spec.template.spec.restartPolicy：必须设为Never或OnFailure
• spec.backoffLimit：失败重试次数（默认6次）
• spec.completions：需成功完成的任务数（默认1）
• spec.parallelism：并行执行的任务数量（默认1）

官方文档

6_CronJob控制器

周期性任务控制器（类似Linux Crontab）

6.1_核心参数

CronJob关键配置参数

• schedule：Cron格式计划任务时间表（*/1 * * * *表示每分钟）
• concurrencyPolicy：并发策略（Allow/Forbid/Replace）
• startingDeadlineSeconds：任务启动容忍时间（秒）
• successfulJobsHistoryLimit：保留成功任务数（默认3）
• failedJobsHistoryLimit：保留失败任务数（默认1）

7_无状态与有状态应用对比

核心差异对比表

对比项	无状态（Deployment）	有状态（StatefulSet）
Pod名称	随机生成	固定、有序（0→N-1）
存储卷	共享存储或无持久卷	每个Pod独立PVC
网络标识	不固定	稳定DNS名称
扩缩容顺序	无序	有序创建/删除
应用实例关系	实例等同，可随意替换	实例唯一，存在依赖关系
典型应用	Web服务、API网关	MySQL、ZooKeeper、Etcd

8_常规Service与Headless Service对比

两种Service的核心区别

类型	是否有ClusterIP	访问方式	核心作用
常规Service	✅	负载均衡+服务发现	集群统一访问入口
Headless Service	❌	直接解析到Pod IP地址	StatefulSet的DNS定位

9_Secret配置管理

安全存储敏感数据的Kubernetes资源类型。

9.1_Secret类型

Secret五种类型

类型	用途描述
Opaque	默认类型，用户自定义密码、密钥（Base64编码）
kubernetes.io/service-account-token	服务账户自动挂载的API访问凭证
kubernetes.io/dockerconfigjson	私有Docker镜像仓库认证信息
kubernetes.io/tls	SSL/TLS证书与私钥存储
bootstrap.kubernetes.io/token	节点引导凭证

官方文档

10_ConfigMap配置管理

存储非敏感配置数据的Kubernetes资源。

10.1_核心特性

ConfigMap与Secret关键差异

项目	Secret	ConfigMap
存储内容	敏感信息（密码/密钥）	普通配置信息
数据编码	Base64	纯文本
主要使用场景	凭据管理	应用配置管理
自动更新机制	Volume延迟更新，Env不更新	Volume延迟更新，Env不更新

---

实验部分

1_Deployment控制器实验

1.1_创建Deployment

• 创建nginx-deployment.yaml配置文件

kubectl create deployment nginx-deployment --image=nginx:1.15 --port=80 --replicas=3 --dry-run -oyaml >ngin x.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80

apiVersion: apps/v1：Deployment API版本
kind: Deployment：资源类型定义
replicas: 3：创建3个Pod副本
selector.matchLabels：选择器匹配Pod标签
template.metadata.labels：与选择器标签一致
containerPort: 80：容器暴露的HTTP端口

• 创建Deployment

kubectl create -f nginx-deployment.yaml

kubectl create：Kubernetes资源创建命令
-f：指定配置文件路径

• 验证资源状态

kubectl get pods,deploy,rs

pods：查看Pod运行状态
deploy：Deployment资源状态
rs：ReplicaSet资源状态（自动创建）

1.2_滚动更新与回滚

• 编辑Deployment配置

kubectl edit deployment/nginx-deployment

配置关键路径：spec.template.spec.containers[0].image

修改镜像版本为nginx:1.16.1触发滚动更新

• 查看历史版本

kubectl rollout history deployment nginx-deployment

输出结果格式：REVISION CHANGE-CAUSE

用于回滚时指定历史版本号

• 回滚到前一版本

kubectl rollout undo deployment/nginx-deployment

无参数回滚到上一版本

可通过--to-revision=2指定版本

---

2_StatefulSet控制器实验

2.1_创建Headless Service

• 创建stateful-headless.yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: myapp-pod

clusterIP: None：定义为Headless Service

无ClusterIP，直接解析到后端Pod IP
selector：匹配后端Pod标签

• 创建服务

kubectl apply -f stateful-headless.yaml

apply：声明式配置更新命令

2.2_创建StatefulSet

• 创建stateful-demo.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myapp
spec:
  serviceName: myapp-svc
  replicas: 3
  selector:
    matchLabels:
      app: myapp-pod
  template:
    metadata:
      labels:
        app: myapp-pod
    spec:
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: myappdata
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: myappdata
      annotations:
        volume.beta.kubernetes.io/storage-class: nfs-client-storageclass
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 2Gi

serviceName：关联的Headless Service名称
volumeClaimTemplates：存储卷声明模板
storage: 2Gi：请求2GB存储空间
storage-class：关联StorageClass

• 创建StatefulSet

kubectl apply -f stateful-demo.yaml

会自动创建3个PVC资源对象

• 验证资源创建

kubectl get sts,pvc,pv,pods

sts：StatefulSet资源
pvc：自动创建的持久卷声明
pv：绑定的持久卷

2.3_Pod名称解析测试

• 直接解析Pod

kubectl exec -it myapp-0 -- nslookup myapp-1.myapp-svc.default.svc.cluster.local

返回结果示例：Address 1: 10.244.1.14 myapp-1.myapp-svc.default.svc.cluster.local

DNS格式：<pod-name>.<service-name>.<namespace>.svc.cluster.local

• 观察滚动更新

kubectl edit sts myapp

修改镜像版本为ikubernetes/myapp:v2

观察更新顺序：myapp-2 → myapp-1 → myapp-0

kubectl get pods -w

-w：实时监控Pod状态变化

验证按序更新机制

---

3_DaemonSet控制器实验

• 创建ds.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-daemonSet
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80

kind: DaemonSet：资源类型定义

无replicas字段（每个Node自动创建一个Pod）

• 部署DaemonSet

kubectl apply -f ds.yaml

• 验证部署结果

kubectl get pods

所有Node节点均存在Pod实例

实例名包含节点标识（如nginx-daemonSet-abcde）

---

4_Job控制器实验

4.1_基础Job示例

• 创建job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

restartPolicy: Never：任务失败不重启
backoffLimit: 4：最大重试4次
command：执行圆周率计算

• 创建并查看Job

kubectl apply -f job.yaml
kubectl logs job/pi

logs命令直接获取Job结果

输出结果包含圆周率2000位计算结果

4.2_失败重试限制

• 创建job-limit.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: busybox
spec:
  template:
    spec:
      containers:
      - name: busybox
        image: busybox
        imagePullPolicy: IfNotPresent
        command: ["/bin/sh", "-c", "sleep 10;date;exit 1"]
      restartPolicy: Never
  backoffLimit: 2

exit 1：制造容器非正常退出
backoffLimit: 2：只剩余2次重试机会

• 验证失败机制

kubectl get job,pods

观察到3个Pod实例（3次失败后终止）

Job状态：COMPLETIONS 0/1

kubectl describe job busybox

关键事件：Warning BackoffLimitExceeded

表明已达到重试上限

---

5_CronJob控制器实验

• 创建cronjob.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

schedule: "*/1 * * * *"：每分钟执行
v1beta1：API版本（1.25+版本需用v1）
restartPolicy: OnFailure：失败时重启

• 部署并验证

kubectl create -f cronjob.yaml
kubectl get cronjob

关键状态字段：LAST SCHEDULE

显示最近一次执行时间

kubectl get pods

按时间生成任务Pod（含时间戳）

如hello-1621587180-mffj6

• 查看执行结果

kubectl logs hello-1621587180-mffj6

输出格式：Tue Oct 14 16:07:16 UTC 2025\nHello from the Kubernetes cluster

---

6_Secret配置管理实验

6.1_命令行创建Secret

• 生成凭证文件

echo -n 'zhangsan' > username.txt
echo -n 'abc1234' > password.txt

-n：避免输出换行符

影响Base64编码结果

• 创建Secret

kubectl create secret generic mysecret --from-file=username.txt --from-file=password.txt

generic：Opaque类型的别称
--from-file：从文件导入数据

• 查看Secret信息

kubectl describe secret mysecret

不显示实际数据（安全保护）

仅显示数据项数量：Type: Opaque, Data: 2 items

6.2_YAML方式创建Secret

• Base64编码处理

echo -n zhangsan | base64  # emhhbmdzYW4=
echo -n abc1234 | base64   # YWJjMTIzNAo=

编码需严格验证

末尾=为Base64填充符

• 创建secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mysecret1
type: Opaque
data:
  password: 'YWJjMTIzNAo='
  username: 'emhhbmdzYW4='

data部分必须为Base64编码

原始数据可通过echo -n {base64} | base64 -d解码

• 部署Secret

kubectl apply -f secret.yaml

6.3_Secret使用方式

① 挂载为文件

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: secrets
      mountPath: "/etc/secrets"
      readOnly: true
  volumes:
  - name: secrets
    secret:
      secretName: mysecret

volumeMounts：挂载点配置
readOnly: true：防止配置误改

• 验证挂载

kubectl exec -it mypod -- ls /etc/secrets

显示：username password两个文件

② 注入环境变量

env:
  - name: TEST_USER
    valueFrom:
      secretKeyRef:
        name: mysecret1
        key: username
  - name: TEST_PASSWORD
    valueFrom:
      secretKeyRef:
        name: mysecret1
        key: password

secretKeyRef：引用Secret特定项

容器内通过$TEST_USER访问

• 验证环境变量

kubectl exec -it mypod1 -- printenv | grep TEST

输出：TEST_USER=zhangsan

---

7_ConfigMap配置管理实验

7.1_创建ConfigMap

• 目录方式

mkdir /opt/configmap/
vim /opt/configmap/game.properties  #编辑配置文件
kubectl create configmap game-config --from-file=/opt/configmap/

目录下所有文件转为键值对

键名=文件名，值=文件内容

• 文件方式

kubectl create configmap game-config-2 \
  --from-file=/opt/configmap/game.properties \
  --from-file=/opt/configmap/ui.properties

精确控制文件映射关系

• 字面值方式

kubectl create configmap special-config \
  --from-literal=special.how=very \
  --from-literal=special.type=good

创建双键值对：special.how: very和special.type: good

7.2_ConfigMap使用方式

① 环境变量注入

env:
  - name: SPECIAL_HOW_KEY
    valueFrom:
      configMapKeyRef:
        name: special-config
        key: special.how
  - name: LOG_LEVEL
    valueFrom:
      configMapKeyRef:
        name: env-config
        key: log_level

多配置源无缝混合使用

支持直接引用或跨CM引用

• 验证配置

kubectl logs test-pod  #查看环境变量输出

② 卷挂载方式

volumeMounts:
  - name: config-volume
    mountPath: /etc/config
volumes:
  - name: config-volume
    configMap:
      name: special-config

文件挂载路径为/etc/config

键名成为文件名，值成为文件内容

• 实时更新测试

kubectl edit configmap log-config
# 修改log_level:DEBUG
kubectl exec -it my-nginx-pod -- cat /etc/config/log_level

Volume挂载约10秒后同步更新

环境变量需重启容器生效

③ 触发滚动更新

kubectl patch deployment my-nginx \
  --patch '{"spec": {"template": {"metadata": {"annotations": {"version/config": "20251016" }}}}}'

通过注解更新触发新ReplicaSet创建

实现配置更新与服务滚动发布

---

结语

Secret与ConfigMap核心机制：Secret需Base64编码存储敏感数据，挂载时文件或环境变量方式使用；ConfigMap存储明文配置，支持热更新特性（Volume约10秒生效），通过注解触发Deployment滚动更新可实现配置动态加载。

控制器核心差异：无状态部署用Deployment实现滚动更新，有状态应用必选StatefulSet（配合Headless Service+PVC），守护进程场景用DaemonSet，一次性任务用Job，周期任务用CronJob。

服务发现机制 ：1.11+集群使用CoreDNS，StatefulSet通过Headless Service实现稳定网络标识，格式为<pod-name>.<service>.<ns>.svc.cluster.local。

!question\] 请问StatefulSet为什么需要配合Headless Service使用？ 答：因为StatefulSet要求Pod名称固定可解析，Headless Service能直接返回Pod IP而不经负载均衡，确保DNS记录持续绑定到特定Pod实例。 \[!question\] 请问如何安全地更新ConfigMap配置？ 答：1) 修改ConfigMap资源 2) 通过kubectl patch更新Deployment注解触发滚动更新 3) 观察新Pod挂载的新配置（Volume约10秒生效） \[!question\] Deployment和StatefulSet在扩缩容行为上有何本质区别？ 答：Deployment扩缩容无序，可能同时创建多个Pod；StatefulSet严格按序创建（0→N）和删除（N→0），确保有状态服务拓扑稳定性。 \[!question\] Job控制器的backoffLimit参数起到什么作用？ 答：限定任务失败后的重试次数（默认6次），超过该限制后Job状态置为Failed并停止重试，避免持续失败消耗资源。 \[!question\] 如何验证Secret数据是否正确编码？ 答：执行`echo {base64字符串} | base64 -d`可解码验证，如`echo 'emhhbmdzYW4=' | base64 -d`输出zhangsan