05.Kubernetes 学习笔记：特殊工作负载与配置管理

七、DaemonSet 和 Job：特殊的工作负载#

1. DaemonSet：每个节点都需要的”守护神”#

1.1 DaemonSet是什么#

DaemonSet 是Kubernetes的一种工作负载控制器，它确保在集群的每个（或特定）节点上都运行一个Pod副本。

用生活化的比喻来理解：

1
想象一个小区的物业管理：
2

3
节点（Node） = 每栋楼
4
DaemonSet Pod = 每栋楼的保安（每栋楼必须有且只有一个保安）
5

6
小区新建一栋楼 → 自动分配一个保安
7
拆除一栋楼 → 这栋楼的保安也会撤离

核心特点：

节点覆盖
- 每个节点运行一个Pod副本（且只有一个）
- 新节点加入集群，自动创建Pod
- 节点离开集群，自动删除Pod
不受调度器控制
- DaemonSet Pod绕过Scheduler直接调度
- 即使节点有污点（Taint），也能运行（如果配置了容忍）
自动修复
- Pod被删除后，会立即在同一节点上重建

1.2 为什么需要DaemonSet#

在前面的章节中，我们学习了Deployment，它管理的Pod可能分散在不同节点上。但有些服务有特殊需求：

必须在每个节点上运行一个实例

想象这些场景：

场景1：日志收集

1
没有DaemonSet：
2
┌─────────┐ ┌─────────┐ ┌─────────┐
3
│ Node1   │ │ Node2   │ │ Node3   │
4
│         │ │         │ │         │
5
│ 3个Pod  │ │ 5个Pod  │ │ 2个Pod  │
6
└─────────┘ └─────────┘ └─────────┘
7
     ?          ?          ?
8
  怎么收集日志？要在哪里部署日志收集器？
9

10
有DaemonSet：
11
┌─────────┐ ┌─────────┐ ┌─────────┐
12
│ Node1   │ │ Node2   │ │ Node3   │
13
│ Fluentd │ │ Fluentd │ │ Fluentd │  <- 每个节点都有日志收集器
14
│ 3个Pod  │ │ 5个Pod  │ │ 2个Pod  │     自动收集本节点日志
15
└─────────┘ └─────────┘ └─────────┘

场景2：节点监控

1
需求：监控每个节点的CPU、内存、磁盘
2
解决：在每个节点上运行监控Agent（如node-exporter）

场景3：网络插件

1
需求：每个节点都需要网络组件（如Calico、Flannel）
2
解决：用DaemonSet部署网络插件

1.3 DaemonSet的典型应用场景#

场景	示例	说明
日志收集	Fluentd、Filebeat、Logstash	收集节点上所有容器的日志
监控Agent	Prometheus Node Exporter、Datadog Agent	监控节点资源和容器指标
网络插件	Calico、Flannel、Weave	为Pod提供网络功能
存储插件	Ceph、GlusterFS客户端	提供分布式存储支持
安全扫描	Falco、Sysdig	监控节点安全事件
性能分析	cAdvisor	收集容器性能数据

DaemonSet vs Deployment对比：

1
Deployment：我需要3个副本，调度器帮我分配到合适的节点
2
┌─────────┐ ┌─────────┐ ┌─────────┐
3
│ Node1   │ │ Node2   │ │ Node3   │
4
│ Pod1    │ │ Pod2    │ │         │
5
│         │ │ Pod3    │ │         │
6
└─────────┘ └─────────┘ └─────────┘
7

8
DaemonSet：每个节点必须运行一个副本
9
┌─────────┐ ┌─────────┐ ┌─────────┐
10
│ Node1   │ │ Node2   │ │ Node3   │
11
│ Pod1    │ │ Pod2    │ │ Pod3    │  <- 每个节点都有
12
└─────────┘ └─────────┘ └─────────┘

2. DaemonSet的实现逻辑和工作原理#

2.1 DaemonSet Controller的工作机制#

DaemonSet由DaemonSet Controller管理，它的工作原理很像一个”节点巡查员”：

工作流程：

flowchart TD A["1. 监听节点变化 Watch Node资源"] --> B B["2. 遍历所有节点 检查每个节点是否应该运行DaemonSet Pod"] --> C C{"3. 判断节点 是否匹配条件?"} --> |"匹配"| D C --> |"不匹配"| E D{"4. 节点上是否 已有Pod?"} --> |"没有"| F D --> |"有"| G F["5. 创建Pod 在该节点上"] --> G E{"6. 节点上是否 有Pod?"} --> |"有"| H E --> |"没有"| G H["7. 删除Pod 不应该运行"] --> G G["8. 继续监听 持续调谐"]

详细步骤解析：

持续监听
- DaemonSet Controller watch API Server的Node和Pod资源
- 一旦有变化（新增节点、节点标签改变、Pod删除），立即响应
节点匹配
- 检查节点是否满足nodeSelector、affinity等条件
- 检查节点是否有Taint，Pod是否有对应的Toleration
Pod创建
- 如果节点需要Pod但没有，创建一个
- 直接指定Pod运行的节点（不通过Scheduler）
- 设置Pod的ownerReference指向DaemonSet
Pod删除
- 如果节点不应该运行Pod但有Pod，删除它
- 节点被删除时，自动清理Pod

2.2 DaemonSet调度机制#

与Deployment的重要区别：

1
Deployment Pod创建流程：
2
用户 → API Server → Deployment Controller创建ReplicaSet
3
→ ReplicaSet Controller创建Pod（状态：Pending，未分配节点）
4
→ Scheduler选择节点并绑定
5
→ Kubelet创建容器
6

7
DaemonSet Pod创建流程：
8
用户 → API Server → DaemonSet Controller创建Pod
9
→ 直接指定nodeName（绕过Scheduler）
10
→ Kubelet创建容器

为什么要绕过Scheduler？

明确的调度需求
- DaemonSet知道Pod必须运行在哪个节点
- 不需要Scheduler的复杂调度算法
忽略资源限制
- 某些系统组件（如网络插件）必须运行，即使节点资源不足
- Scheduler可能因资源不足拒绝调度，但DaemonSet强制创建
忽略污点
- DaemonSet可以配置Toleration容忍所有污点
- 在master节点上运行也没问题

2.3 DaemonSet的自我修复#

场景1：Pod被意外删除

1
# 删除DaemonSet的一个Pod
2
kubectl delete pod <daemonset-pod> -n kube-system
3

4
# 立即（几秒内）重建
5
kubectl get pods -n kube-system -w
6
# 你会看到Pod立即进入Pending → Running

场景2：节点宕机后恢复

1
节点宕机 → Pod状态变为Unknown
2
→ 节点恢复 → DaemonSet Controller检测到
3
→ 重建Pod

场景3：新节点加入集群

1
# 添加新节点
2
kubeadm join ...
3

4
# DaemonSet自动在新节点上创建Pod
5
kubectl get pods -o wide
6
# 你会看到新节点上已经有DaemonSet的Pod

3. DaemonSet配置详解#

3.1 基本YAML结构#

最简单的DaemonSet：

1
apiVersion: apps/v1
2
kind: DaemonSet
3
metadata:
4
  name: example-daemonset
5
  namespace: default
6
spec:
7
  selector:
8
    matchLabels:
9
      app: example
10
  template:
11
    metadata:
12
      labels:
13
        app: example
14
    spec:
15
      containers:
16
      - name: example-container
17
        image: busybox
18
        command: ['sh', '-c', 'echo Hello from $(hostname) && sleep 3600']

核心字段说明：

字段	说明	必需
apiVersion	apps/v1	✓
kind	DaemonSet	✓
metadata.name	DaemonSet名称	✓
spec.selector	标签选择器，匹配Pod	✓
spec.template	Pod模板（与Pod的spec一样）	✓
spec.updateStrategy	更新策略（RollingUpdate/OnDelete）
spec.minReadySeconds	Pod就绪后多久才认为可用（秒）

3.2 节点选择：控制在哪些节点上运行#

方式1：nodeSelector（简单标签匹配）

1
apiVersion: apps/v1
2
kind: DaemonSet
3
metadata:
4
  name: nginx-daemonset
5
spec:
6
  selector:
7
    matchLabels:
8
      app: nginx
9
  template:
10
    metadata:
11
      labels:
12
        app: nginx
13
    spec:
14
      nodeSelector:
15
        disktype: ssd    # 只在有disktype=ssd标签的节点上运行
16
      containers:
17
      - name: nginx
18
        image: nginx:1.20

使用示例：

1
# 给节点打标签
2
kubectl label nodes k8s-node1 disktype=ssd
3
kubectl label nodes k8s-node2 disktype=ssd
4

5
# DaemonSet只会在node1和node2上创建Pod
6
kubectl get pods -o wide

方式2：nodeAffinity（灵活的节点亲和性）

1
apiVersion: apps/v1
2
kind: DaemonSet
3
metadata:
4
  name: monitoring-daemonset
5
spec:
6
  selector:
7
    matchLabels:
8
      app: monitoring
9
  template:
10
    metadata:
11
      labels:
12
        app: monitoring
13
    spec:
14
      affinity:
15
        nodeAffinity:
16
          requiredDuringSchedulingIgnoredDuringExecution:
17
            nodeSelectorTerms:
18
            - matchExpressions:
19
              - key: kubernetes.io/hostname
20
                operator: In
21
                values:
22
                - k8s-node1
23
                - k8s-node2
24
      containers:
25
      - name: node-exporter
26
        image: prom/node-exporter:latest

操作符说明：

操作符	说明	示例
In	标签值在列表中	`key: In values: [v1, v2]`
NotIn	标签值不在列表中	`key: NotIn values: [v1]`
Exists	标签存在（不管值是什么）	`key: Exists`
DoesNotExist	标签不存在	`key: DoesNotExist`
Gt	标签值大于指定值（数值比较）	`key: Gt value: "100"`
Lt	标签值小于指定值	`key: Lt value: "50"`

3.3 污点和容忍：在特殊节点上运行#

什么是Taint（污点）和Toleration（容忍）？

1
污点（Taint）= 节点的"拒客牌"
2
容忍（Toleration）= Pod的"通行证"
3

4
想象一个VIP餐厅：
5
- 餐厅门口挂牌："只接待VIP客户"（这是污点）
6
- 你有VIP卡（这是容忍），就能进去

污点的三种效果：

效果	说明
NoSchedule	不允许新Pod调度到该节点（已有Pod不受影响）
PreferNoSchedule	尽量不调度新Pod到该节点（不是硬性要求）
NoExecute	不允许Pod运行，已有Pod如果不容忍污点会被驱逐

DaemonSet容忍所有污点的示例：

1
apiVersion: apps/v1
2
kind: DaemonSet
3
metadata:
4
  name: fluent-bit
5
  namespace: kube-system
6
spec:
7
  selector:
8
    matchLabels:
9
      app: fluent-bit
10
  template:
11
    metadata:
12
      labels:
13
        app: fluent-bit
14
    spec:
15
      tolerations:
16
      # 容忍master节点污点（允许在master上运行）
17
      - key: node-role.kubernetes.io/master
18
        operator: Exists
19
        effect: NoSchedule
20
      - key: node-role.kubernetes.io/control-plane
21
        operator: Exists
22
        effect: NoSchedule
23
      # 容忍节点未就绪
24
      - key: node.kubernetes.io/not-ready
25
        operator: Exists
26
        effect: NoExecute
27
      # 容忍节点不可达
28
      - key: node.kubernetes.io/unreachable
29
        operator: Exists
30
        effect: NoExecute
31
      containers:
32
      - name: fluent-bit
33
        image: fluent/fluent-bit:latest

容忍的配置项：

字段	说明
key	污点的键（留空表示匹配所有键）
operator	匹配操作符（Exists=存在即可，Equal=值必须相等）
value	污点的值（operator为Equal时必须指定）
effect	污点效果（NoSchedule/PreferNoSchedule/NoExecute，留空表示匹配所有效果）

4. DaemonSet更新策略#

4.1 更新策略类型#

DaemonSet支持两种更新策略：

策略	说明	使用场景
RollingUpdate	滚动更新（默认）	自动化更新，推荐
OnDelete	手动删除Pod后才更新	需要精细控制更新时机

4.2 滚动更新（RollingUpdate）#

工作原理：

1
滚动更新流程：
2
1. 更新DaemonSet的Pod模板
3
2. DaemonSet Controller逐个节点更新Pod
4
   - 删除旧Pod
5
   - 等待旧Pod终止
6
   - 创建新Pod
7
   - 等待新Pod就绪
8
   - 继续下一个节点

配置示例：

1
apiVersion: apps/v1
2
kind: DaemonSet
3
metadata:
4
  name: fluentd
5
spec:
6
  updateStrategy:
7
    type: RollingUpdate
8
    rollingUpdate:
9
      maxUnavailable: 1    # 同时更新的最大节点数（默认1）
10
  selector:
11
    matchLabels:
12
      app: fluentd
13
  template:
14
    metadata:
15
      labels:
16
        app: fluentd
17
    spec:
18
      containers:
19
      - name: fluentd
20
        image: fluent/fluentd:v1.14    # 镜像版本

maxUnavailable参数：

1
maxUnavailable: 1 （保守更新）
2
┌─────────┐ ┌─────────┐ ┌─────────┐
3
│ Node1   │ │ Node2   │ │ Node3   │
4
│ v1.14 ✓ │ │ v1.13   │ │ v1.13   │  <- 一个一个更新
5
└─────────┘ └─────────┘ └─────────┘
6
     ↓           等待         等待
7
┌─────────┐ ┌─────────┐ ┌─────────┐
8
│ Node1   │ │ Node2   │ │ Node3   │
9
│ v1.14 ✓ │ │ v1.14 ✓ │ │ v1.13   │
10
└─────────┘ └─────────┘ └─────────┘
11

12
maxUnavailable: 2 （激进更新）
13
┌─────────┐ ┌─────────┐ ┌─────────┐
14
│ Node1   │ │ Node2   │ │ Node3   │
15
│ v1.14 ✓ │ │ v1.14 ✓ │ │ v1.13   │  <- 两个同时更新
16
└─────────┘ └─────────┘ └─────────┘

执行更新：

1
# 方式1：修改镜像
2
kubectl set image daemonset/fluentd fluentd=fluent/fluentd:v1.15 -n kube-system
3

4
# 方式2：修改YAML后apply
5
kubectl apply -f fluentd-daemonset.yaml
6

7
# 查看更新状态
8
kubectl rollout status daemonset/fluentd -n kube-system
9

10
# 查看更新历史
11
kubectl rollout history daemonset/fluentd -n kube-system

监控更新过程：

1
# 实时监控Pod变化
2
kubectl get pods -n kube-system -l app=fluentd -w
3

4
# 查看DaemonSet状态
5
kubectl get daemonset fluentd -n kube-system
6
# 输出：
7
# NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE
8
# fluentd   3         3         2       1            2
9
#
10
# DESIRED: 期望的Pod数量（节点数）
11
# CURRENT: 当前运行的Pod数量
12
# READY: 就绪的Pod数量
13
# UP-TO-DATE: 已更新到最新版本的Pod数量
14
# AVAILABLE: 可用的Pod数量

4.3 手动更新（OnDelete）#

使用场景：

需要在特定时间窗口更新
需要逐个验证更新效果
关键服务不能自动更新

配置示例：

1
apiVersion: apps/v1
2
kind: DaemonSet
3
metadata:
4
  name: critical-monitoring
5
spec:
6
  updateStrategy:
7
    type: OnDelete    # 手动更新模式
8
  selector:
9
    matchLabels:
10
      app: monitoring
11
  template:
12
    metadata:
13
      labels:
14
        app: monitoring
15
    spec:
16
      containers:
17
      - name: monitor
18
        image: monitoring:v2.0

更新流程：

1
# 1. 修改DaemonSet（只更新模板，不影响现有Pod）
2
kubectl apply -f daemonset.yaml
3

4
# 2. 手动删除节点1的Pod（触发更新）
5
kubectl delete pod critical-monitoring-xxxxx -n default
6

7
# 3. 新Pod自动创建，使用新模板
8

9
# 4. 验证新Pod正常后，继续删除下一个
10
kubectl delete pod critical-monitoring-yyyyy -n default

4.4 回滚DaemonSet#

查看历史版本：

1
# 查看DaemonSet的历史版本
2
kubectl rollout history daemonset/fluentd -n kube-system
3

4
# 输出：
5
# REVISION  CHANGE-CAUSE
6
# 1         <none>
7
# 2         kubectl apply --filename=fluentd-v1.14.yaml
8
# 3         kubectl set image daemonset/fluentd fluentd=fluent/fluentd:v1.15

回滚到上一个版本：

1
# 回滚到上一版本
2
kubectl rollout undo daemonset/fluentd -n kube-system
3

4
# 查看回滚状态
5
kubectl rollout status daemonset/fluentd -n kube-system

回滚到指定版本：

1
# 回滚到revision 2
2
kubectl rollout undo daemonset/fluentd --to-revision=2 -n kube-system

暂停和恢复更新：

1
# 暂停更新（已更新的不会回滚，未更新的停止更新）
2
kubectl rollout pause daemonset/fluentd -n kube-system
3

4
# 恢复更新
5
kubectl rollout resume daemonset/fluentd -n kube-system

5. Job：一次性任务执行器#

5.1 Job是什么#

Job 是Kubernetes中用于运行一次性任务的工作负载控制器。

与Deployment/DaemonSet的区别：

1
Deployment: 我要这个服务一直运行着（长期运行服务）
2
  - Web服务器
3
  - API服务
4
  - 数据库
5

6
DaemonSet: 每个节点都要运行一个服务（节点级长期服务）
7
  - 日志收集
8
  - 监控Agent
9

10
Job: 执行一个任务，完成就结束（一次性任务）
11
  - 数据库备份
12
  - 批量数据处理
13
  - 定时清理任务

生活化比喻：

1
Deployment = 餐厅的厨师（一直工作）
2
DaemonSet = 每层楼的保洁（每层都有，一直工作）
3
Job = 搬家工人（搬完就走）

5.2 Job的核心特点#

任务完成即终止
- Pod运行完成（退出码0）后，Job标记为Complete
- Pod不会重启（除非失败重试）
失败重试
- 支持配置重试次数
- 失败的Pod会被删除并重建
并行执行
- 支持同时运行多个Pod
- 支持顺序执行或并行执行
保留历史
- 完成的Pod默认保留（可以查看日志）
- 可配置自动清理

5.3 Job的工作模式#

模式1：单次执行（最常见）

1
apiVersion: batch/v1
2
kind: Job
3
metadata:
4
  name: backup-job
5
spec:
6
  template:
7
    spec:
8
      containers:
9
      - name: backup
10
        image: mysql:8.0
11
        command: ['sh', '-c', 'mysqldump -h mysql -u root -pPassword123 mydb > /backup/mydb.sql']
12
      restartPolicy: Never    # 重要：Job必须设置为Never或OnFailure

执行流程：

1
创建Job → 创建Pod → Pod运行 → 任务完成(退出码0) → Pod状态Completed → Job状态Complete

模式2：固定完成次数（completions）

1
apiVersion: batch/v1
2
kind: Job
3
metadata:
4
  name: data-process-job
5
spec:
6
  completions: 5    # 需要成功完成5次
7
  template:
8
    spec:
9
      containers:
10
      - name: processor
11
        image: data-processor:latest
12
      restartPolicy: Never

执行流程：

1
创建5个Pod（可能顺序执行）→ 每个Pod完成一个任务 → 5个全部成功 → Job完成

模式3：并行执行（parallelism）

1
apiVersion: batch/v1
2
kind: Job
3
metadata:
4
  name: parallel-job
5
spec:
6
  completions: 10       # 总共需要完成10个任务
7
  parallelism: 3        # 同时运行3个Pod
8
  template:
9
    spec:
10
      containers:
11
      - name: worker
12
        image: worker:latest
13
      restartPolicy: Never

执行流程：

1
第一批：创建3个Pod同时运行
2
  → Pod1完成 → 创建Pod4
3
  → Pod2完成 → 创建Pod5
4
  → Pod3完成 → 创建Pod6
5
...
6
→ 10个全部完成 → Job完成

对比图：

1
顺序执行（parallelism=1, completions=3）：
2
时间 →
3
Pod1 [████████]
4
              Pod2 [████████]
5
                            Pod3 [████████]
6

7
并行执行（parallelism=3, completions=3）：
8
时间 →
9
Pod1 [████████]
10
Pod2 [████████]
11
Pod3 [████████]
12

13
混合模式（parallelism=2, completions=5）：
14
时间 →
15
Pod1 [████████]
16
Pod2 [████████]
17
              Pod3 [████████]
18
              Pod4 [████████]
19
                            Pod5 [████████]

5.4 Job配置详解#

完整的Job YAML结构：

1
apiVersion: batch/v1
2
kind: Job
3
metadata:
4
  name: example-job
5
  namespace: default
6
spec:
7
  # 并行控制
8
  completions: 3              # 需要成功完成的Pod数量（默认1）
9
  parallelism: 2              # 同时运行的最大Pod数量（默认1）
10

11
  # 失败控制
12
  backoffLimit: 6             # 最大失败重试次数（默认6）
13

14
  # 超时控制
15
  activeDeadlineSeconds: 600  # Job运行的最大时间（秒），超时则终止
16

17
  # 清理控制
18
  ttlSecondsAfterFinished: 100  # Job完成后多久自动删除（秒）
19

20
  # Pod模板
21
  template:
22
    spec:
23
      restartPolicy: Never    # 必须是Never或OnFailure
24
      containers:
25
      - name: worker
26
        image: busybox
27
        command: ['sh', '-c', 'echo Processing... && sleep 10 && echo Done!']

关键字段详解：

字段	说明	默认值
completions	需要成功完成的Pod总数	1
parallelism	同时运行的最大Pod数	1
backoffLimit	失败重试次数限制	6
activeDeadlineSeconds	Job运行最大时长（秒），超时终止所有Pod
ttlSecondsAfterFinished	Job完成后自动清理时间（秒）
restartPolicy	必须是Never或OnFailure（不能是Always）	Never

restartPolicy的区别：

1
# Never: Pod失败后不重启，Job Controller创建新Pod
2
restartPolicy: Never
3
# 行为：Pod1失败 → 创建Pod2 → Pod2失败 → 创建Pod3 ...
4

5
# OnFailure: Pod失败后在原地重启容器
6
restartPolicy: OnFailure
7
# 行为：Pod1失败 → 容器重启 → 失败 → 容器再重启 ...

使用建议：

Never：适合有状态任务或需要重新初始化环境的任务
OnFailure：适合无状态任务，节省Pod创建开销

5.5 Job失败处理#

场景1：backoffLimit限制重试次数

1
apiVersion: batch/v1
2
kind: Job
3
metadata:
4
  name: retry-job
5
spec:
6
  backoffLimit: 3    # 最多失败3次
7
  template:
8
    spec:
9
      restartPolicy: Never
10
      containers:
11
      - name: worker
12
        image: busybox
13
        command: ['sh', '-c', 'exit 1']  # 故意失败

执行结果：

1
创建Pod1 → 失败（退出码1）
2
→ 创建Pod2 → 失败
3
→ 创建Pod3 → 失败
4
→ 创建Pod4 → 失败
5
→ 达到backoffLimit限制，Job标记为Failed

场景2：超时控制

1
apiVersion: batch/v1
2
kind: Job
3
metadata:
4
  name: timeout-job
5
spec:
6
  activeDeadlineSeconds: 30  # 30秒超时
7
  template:
8
    spec:
9
      restartPolicy: Never
10
      containers:
11
      - name: worker
12
        image: busybox
13
        command: ['sh', '-c', 'sleep 60']  # 睡眠60秒

执行结果：

1
创建Pod → 运行30秒 → 超时 → Job终止Pod → Job状态Failed

查看Job状态：

1
# 查看Job
2
kubectl get jobs
3

4
# 输出示例：
5
# NAME        COMPLETIONS   DURATION   AGE
6
# backup-job  1/1           15s        1m     <- 成功
7
# retry-job   0/1           2m         2m     <- 失败
8

9
# 查看详细状态
10
kubectl describe job retry-job
11

12
# 查看失败的Pod日志
13
kubectl logs <pod-name>

5.6 Job清理#

问题：Job完成后Pod会一直存在

1
kubectl get jobs
2
# NAME        COMPLETIONS   DURATION   AGE
3
# backup-job  1/1           15s        7d    <- 7天前完成的Job还在
4

5
kubectl get pods
6
# NAME              READY   STATUS      RESTARTS   AGE
7
# backup-job-xxxxx  0/1     Completed   0          7d    <- Pod也还在

解决方案1：自动清理（推荐）

1
apiVersion: batch/v1
2
kind: Job
3
metadata:
4
  name: auto-cleanup-job
5
spec:
6
  ttlSecondsAfterFinished: 100  # 完成后100秒自动删除
7
  template:
8
    spec:
9
      restartPolicy: Never
10
      containers:
11
      - name: worker
12
        image: busybox
13
        command: ['sh', '-c', 'echo Done && sleep 10']

解决方案2：手动清理

1
# 删除Job（会级联删除Pod）
2
kubectl delete job backup-job
3

4
# 批量删除已完成的Job
5
kubectl delete jobs --field-selector status.successful=1
6

7
# 批量删除失败的Job
8
kubectl delete jobs --field-selector status.failed=1

6. CronJob：定时任务调度器#

6.1 CronJob是什么#

CronJob 是Kubernetes中用于定时执行任务的控制器，就像Linux的crontab。

生活化比喻：

1
Job = 临时工（干完活就走）
2
CronJob = 定时闹钟（每天早上7点叫你起床）
3

4
示例：
5
- 每天凌晨2点备份数据库
6
- 每小时清理临时文件
7
- 每周一生成报表

核心特点：

定时执行
- 按照Cron表达式定时创建Job
- Job执行完成后自动清理
历史管理
- 保留最近几次成功/失败的Job
- 自动清理旧Job
并发控制
- 控制同时运行的Job数量
- 处理上次Job未完成的情况

6.2 Cron表达式详解#

格式：

1
分钟  小时  日期  月份  星期
2
*    *    *    *    *

字段说明：

字段	取值范围	特殊字符
分钟	0-59	* , - /
小时	0-23	* , - /
日期	1-31	* , - / ?
月份	1-12	* , - /
星期	0-7 (0和7都是周日)	* , - / ?

特殊字符含义：

字符	含义	示例
*****	任意值	`* * * * *` = 每分钟
,	列举多个值	`0 8,12,18 * * *` = 8点、12点、18点
-	范围	`0 9-17 * * *` = 9点到17点每小时
/	步长/间隔	`/5 * * *` = 每5分钟
?	不指定（日期和星期互斥时使用）	`0 0 1 * ?` = 每月1号

常用示例：

Cron表达式	说明
`/5 * * *`	每5分钟
`0 * * * *`	每小时整点
`0 0 * * *`	每天凌晨0点
`0 2 * * *`	每天凌晨2点
`0 0 * * 0`	每周日凌晨0点
`0 0 1 * *`	每月1号凌晨0点
`0 9-17 * * 1-5`	周一到周五，9点到17点每小时
`/10 9-17 * *`	9点到17点，每10分钟
`0 0 1 1 *`	每年1月1号凌晨0点

在线测试工具： https://crontab.guru/

6.3 CronJob基本配置#

最简单的CronJob：

1
apiVersion: batch/v1
2
kind: CronJob
3
metadata:
4
  name: hello-cronjob
5
spec:
6
  schedule: "*/1 * * * *"    # 每分钟执行一次
7
  jobTemplate:
8
    spec:
9
      template:
10
        spec:
11
          restartPolicy: Never
12
          containers:
13
          - name: hello
14
            image: busybox
15
            command: ['sh', '-c', 'date; echo Hello from CronJob']

完整配置：

1
apiVersion: batch/v1
2
kind: CronJob
3
metadata:
4
  name: backup-cronjob
5
  namespace: default
6
spec:
7
  # Cron表达式
8
  schedule: "0 2 * * *"              # 每天凌晨2点
9

10
  # 时区（Kubernetes 1.25+）
11
  timeZone: "Asia/Shanghai"          # 使用中国时区
12

13
  # 并发策略
14
  concurrencyPolicy: Forbid          # Allow/Forbid/Replace
15

16
  # Job历史保留
17
  successfulJobsHistoryLimit: 3      # 保留3个成功的Job
18
  failedJobsHistoryLimit: 1          # 保留1个失败的Job
19

20
  # 启动延迟
21
  startingDeadlineSeconds: 100       # 如果错过调度时间，100秒内还可以启动
22

23
  # 暂停调度
24
  suspend: false                     # true表示暂停，不创建新Job
25

26
  # Job模板（与Job的spec相同）
27
  jobTemplate:
28
    spec:
29
      template:
30
        spec:
31
          restartPolicy: Never
32
          containers:
33
          - name: backup
34
            image: mysql:8.0
35
            command: ['sh', '-c', 'mysqldump -h mysql -u root -p$MYSQL_PWD mydb > /backup/backup-$(date +%Y%m%d-%H%M%S).sql']
36
            env:
37
            - name: MYSQL_PWD
38
              valueFrom:
39
                secretKeyRef:
40
                  name: mysql-secret
41
                  key: password

关键字段详解：

字段	说明	默认值
schedule	Cron表达式	必填
timeZone	时区（K8s 1.25+）	UTC
concurrencyPolicy	并发策略	Allow
successfulJobsHistoryLimit	保留成功Job数量	3
failedJobsHistoryLimit	保留失败Job数量	1
startingDeadlineSeconds	错过调度后的启动宽限期（秒）	无限制
suspend	是否暂停	false

6.4 并发策略详解#

concurrencyPolicy决定如何处理Job重叠的情况：

策略1：Allow（允许并发，默认）

1
spec:
2
  schedule: "*/1 * * * *"
3
  concurrencyPolicy: Allow    # 允许多个Job同时运行

场景：

1
时间线：
2
0:00 → Job1创建，运行中
3
0:01 → Job2创建，运行中（Job1还没完成）
4
0:02 → Job3创建，运行中（Job1、Job2都还没完成）
5

6
结果：3个Job同时运行

适用场景： 任务之间互不影响，可以并行执行

策略2：Forbid（禁止并发）

1
spec:
2
  schedule: "*/1 * * * *"
3
  concurrencyPolicy: Forbid   # 如果上一个Job还在运行，跳过本次调度

场景：

1
时间线：
2
0:00 → Job1创建，运行中
3
0:01 → 检查：Job1还在运行 → 跳过，不创建Job2
4
0:02 → 检查：Job1还在运行 → 跳过，不创建Job3
5
0:03 → Job1完成
6
0:04 → Job2创建，运行中
7

8
结果：同一时间只有1个Job运行

适用场景： 任务不能并发（如数据库备份、资源清理）

策略3：Replace（替换）

1
spec:
2
  schedule: "*/1 * * * *"
3
  concurrencyPolicy: Replace  # 终止旧Job，创建新Job

场景：

1
时间线：
2
0:00 → Job1创建，运行中
3
0:01 → 检查：Job1还在运行 → 终止Job1 → 创建Job2
4
0:02 → 检查：Job2还在运行 → 终止Job2 → 创建Job3
5

6
结果：旧Job被新Job替换

适用场景： 只关心最新的任务结果（如监控数据采集）

6.5 CronJob管理命令#

创建和查看：

1
# 创建CronJob
2
kubectl apply -f cronjob.yaml
3

4
# 查看CronJob
5
kubectl get cronjobs
6
# 输出：
7
# NAME            SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
8
# backup-cronjob  0 2 * * *     False     0        15h             3d
9

10
# 查看详细信息
11
kubectl describe cronjob backup-cronjob
12

13
# 查看CronJob创建的Job
14
kubectl get jobs
15
# NAME                      COMPLETIONS   DURATION   AGE
16
# backup-cronjob-28441920   1/1           15s        15h
17
# backup-cronjob-28443360   1/1           16s        39m

手动触发：

1
# 手动创建一个Job（不等调度时间）
2
kubectl create job --from=cronjob/backup-cronjob manual-backup-job
3

4
# 查看手动创建的Job
5
kubectl get jobs manual-backup-job

暂停和恢复：

1
# 暂停CronJob（不创建新Job，已有Job继续运行）
2
kubectl patch cronjob backup-cronjob -p '{"spec":{"suspend":true}}'
3

4
# 恢复CronJob
5
kubectl patch cronjob backup-cronjob -p '{"spec":{"suspend":false}}'

删除：

1
# 删除CronJob（不删除已创建的Job）
2
kubectl delete cronjob backup-cronjob
3

4
# 删除CronJob及其所有Job
5
kubectl delete cronjob backup-cronjob --cascade=foreground

7. 实战1：部署Fluentd DaemonSet收集日志#

7.1 实战目标#

部署Fluentd日志收集器到集群的每个节点，收集所有容器的日志并输出到stdout（生产环境会输出到Elasticsearch等）。

架构图：

graph TB subgraph "K8s Cluster" subgraph "Node1" P1["应用Pod1 写日志到/var/log/containers/"] F1["Fluentd DaemonSet Pod 收集/var/log/containers/"] P1 -.日志文件.-> F1 end subgraph "Node2" P2["应用Pod2 写日志到/var/log/containers/"] F2["Fluentd DaemonSet Pod 收集/var/log/containers/"] P2 -.日志文件.-> F2 end subgraph "Node3" P3["应用Pod3 写日志到/var/log/containers/"] F3["Fluentd DaemonSet Pod 收集/var/log/containers/"] P3 -.日志文件.-> F3 end end F1 --> Output["输出到stdout (或Elasticsearch)"] F2 --> Output F3 --> Output

7.2 理解Fluentd工作原理#

Fluentd是什么？

Fluentd是一个开源的日志收集器，专门设计用于统一日志收集和分发。

在K8s中的工作方式：

容器日志位置

1
容器日志 → Docker/containerd写入 → /var/log/containers/
2

3
日志文件命名格式：
4
<pod-name>_<namespace>_<container-name>-<container-id>.log
5

6
示例：
7
nginx-deployment-5d59d67564-abcde_default_nginx-a1b2c3d4.log

Fluentd收集策略

1
DaemonSet部署到每个节点
2
→ 挂载宿主机的/var/log/containers目录
3
→ 读取所有日志文件
4
→ 解析、过滤、格式化
5
→ 发送到目标（Elasticsearch、S3、Kafka等）

7.3 准备ConfigMap配置#

Fluentd需要配置文件告诉它如何处理日志。

创建fluentd-config.yaml：

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: fluentd-config
5
  namespace: kube-system
6
data:
7
  fluent.conf: |
8
    # 输入源：读取容器日志
9
    <source>
10
      @type tail                           # 使用tail插件（类似tail -f命令）
11
      path /var/log/containers/*.log       # 监控所有容器日志
12
      pos_file /var/log/fluentd-containers.log.pos  # 记录读取位置（避免重复）
13
      tag kubernetes.*                     # 日志标签
14
      read_from_head true                  # 从头开始读取
15
      <parse>
16
        @type json                         # 解析JSON格式日志
17
        time_key time
18
        time_format %Y-%m-%dT%H:%M:%S.%NZ
19
        keep_time_key true
20
      </parse>
21
    </source>
22

23
    # 过滤器：添加Kubernetes元数据
24
    <filter kubernetes.**>
25
      @type kubernetes_metadata            # 添加Pod名称、命名空间等信息
26
    </filter>
27

28
    # 输出：打印到stdout（测试用）
29
    <match **>
30
      @type stdout                         # 输出到标准输出
31
    </match>

配置解释：

配置项	说明
@type tail	监控文件变化（类似`tail -f`）
path	日志文件路径（支持通配符）
pos_file	记录读取位置的文件（重启后从上次位置继续）
tag	日志标签，用于路由
@type json	解析JSON格式的日志
@type kubernetes_metadata	自动添加Pod名称、命名空间、标签等Kubernetes信息
@type stdout	输出到标准输出（生产环境改为elasticsearch等）

创建ConfigMap：

1
kubectl apply -f fluentd-config.yaml

7.4 创建Fluentd DaemonSet#

创建fluentd-daemonset.yaml：

1
apiVersion: apps/v1
2
kind: DaemonSet
3
metadata:
4
  name: fluentd
5
  namespace: kube-system
6
  labels:
7
    app: fluentd
8
spec:
9
  selector:
10
    matchLabels:
11
      app: fluentd
12
  template:
13
    metadata:
14
      labels:
15
        app: fluentd
16
    spec:
17
      # 服务账号（需要权限读取Pod元数据）
18
      serviceAccountName: fluentd
19

20
      # 容忍master节点污点（在所有节点运行）
21
      tolerations:
22
      - key: node-role.kubernetes.io/master
23
        operator: Exists
24
        effect: NoSchedule
25
      - key: node-role.kubernetes.io/control-plane
26
        operator: Exists
27
        effect: NoSchedule
28

29
      containers:
30
      - name: fluentd
31
        image: fluent/fluentd-kubernetes-daemonset:v1-debian-elasticsearch
32
        env:
33
        # 禁用Elasticsearch输出（我们只用stdout测试）
34
        - name: FLUENT_ELASTICSEARCH_HOST
35
          value: "localhost"
36
        resources:
37
          limits:
38
            memory: 200Mi
39
          requests:
40
            cpu: 100m
41
            memory: 200Mi
42
        volumeMounts:
43
        # 挂载配置文件
44
        - name: config
45
          mountPath: /fluentd/etc/fluent.conf
46
          subPath: fluent.conf
47
        # 挂载容器日志目录
48
        - name: varlog
49
          mountPath: /var/log
50
          readOnly: true
51
        # 挂载容器运行时目录
52
        - name: varlibdockercontainers
53
          mountPath: /var/lib/docker/containers
54
          readOnly: true
55

56
      volumes:
57
      - name: config
58
        configMap:
59
          name: fluentd-config
60
      - name: varlog
61
        hostPath:
62
          path: /var/log
63
      - name: varlibdockercontainers
64
        hostPath:
65
          path: /var/lib/docker/containers

关键配置说明：

ServiceAccount

1
Fluentd需要调用K8s API获取Pod信息
2
→ 需要创建ServiceAccount和对应的RBAC权限

tolerations

1
允许在master节点运行
2
→ 收集master节点上的系统组件日志

volumeMounts
- /var/log: 宿主机日志目录
- /var/lib/docker/containers: 容器日志文件的软链接源

7.5 创建RBAC权限#

创建fluentd-rbac.yaml：

1
---
2
apiVersion: v1
3
kind: ServiceAccount
4
metadata:
5
  name: fluentd
6
  namespace: kube-system
7
---
8
apiVersion: rbac.authorization.k8s.io/v1
9
kind: ClusterRole
10
metadata:
11
  name: fluentd
12
rules:
13
- apiGroups: [""]
14
  resources:
15
  - pods
16
  - namespaces
17
  verbs:
18
  - get
19
  - list
20
  - watch
21
---
22
apiVersion: rbac.authorization.k8s.io/v1
23
kind: ClusterRoleBinding
24
metadata:
25
  name: fluentd
26
roleRef:
27
  apiGroup: rbac.authorization.k8s.io
28
  kind: ClusterRole
29
  name: fluentd
30
subjects:
31
- kind: ServiceAccount
32
  name: fluentd
33
  namespace: kube-system

权限说明：

get/list/watch pods: 获取Pod信息（名称、标签、命名空间）
get/list/watch namespaces: 获取命名空间信息

7.6 部署和验证#

1. 部署Fluentd

1
# 创建RBAC权限
2
kubectl apply -f fluentd-rbac.yaml
3

4
# 创建ConfigMap
5
kubectl apply -f fluentd-config.yaml
6

7
# 创建DaemonSet
8
kubectl apply -f fluentd-daemonset.yaml

2. 验证部署

1
# 查看DaemonSet状态
2
kubectl get daemonset -n kube-system fluentd
3

4
# 输出：
5
# NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
6
# fluentd   3         3         3       3            3           <none>          1m
7

8
# 查看Pod分布
9
kubectl get pods -n kube-system -l app=fluentd -o wide
10

11
# 输出：
12
# NAME            READY   STATUS    RESTARTS   AGE   IP           NODE
13
# fluentd-abc12   1/1     Running   0          1m    10.244.0.5   k8s-master
14
# fluentd-def34   1/1     Running   0          1m    10.244.1.5   k8s-node1
15
# fluentd-ghi56   1/1     Running   0          1m    10.244.2.5   k8s-node2

3. 创建测试应用生成日志

1
# 创建一个简单的Pod生成日志
2
kubectl run log-generator --image=busybox --restart=Never -- sh -c 'while true; do echo "Log message at $(date)"; sleep 5; done'

4. 查看Fluentd收集的日志

1
# 查看Fluentd日志（会看到收集到的应用日志）
2
kubectl logs -n kube-system -l app=fluentd --tail=50
3

4
# 输出示例：
5
# 2024-01-15 10:30:15 +0000 kubernetes.var.log.containers.log-generator_default_log-generator-xxx.log:
6
# {
7
#   "log":"Log message at Mon Jan 15 10:30:15 UTC 2024\n",
8
#   "stream":"stdout",
9
#   "time":"2024-01-15T10:30:15.123456789Z",
10
#   "kubernetes":{
11
#     "pod_name":"log-generator",
12
#     "namespace_name":"default",
13
#     "pod_id":"abc123",
14
#     "container_name":"log-generator",
15
#     "host":"k8s-node1"
16
#   }
17
# }

5. 测试更新DaemonSet

1
# 修改Fluentd镜像版本（触发滚动更新）
2
kubectl set image daemonset/fluentd fluentd=fluent/fluentd-kubernetes-daemonset:v1.15-debian-elasticsearch-1 -n kube-system
3

4
# 查看更新状态
5
kubectl rollout status daemonset/fluentd -n kube-system
6

7
# 监控更新过程
8
kubectl get pods -n kube-system -l app=fluentd -w

8. 实战2：使用Job执行一次性数据处理任务#

8.1 实战目标#

创建Job执行批量数据处理任务，演示并行执行、失败重试机制。

场景： 批量处理图片缩略图（模拟）

8.2 准备测试镜像#

在harbor机器上创建处理镜像：

1
mkdir -p /root/k8s-demo/image-processor
2
cd /root/k8s-demo/image-processor

创建process.sh：

1
cat > process.sh << 'EOF'
2
#!/bin/sh
3
TASK_ID=${TASK_ID:-"unknown"}
4
echo "=== Task $TASK_ID Started at $(date) ==="
5
SLEEP_TIME=$((5 + RANDOM % 10))
6
echo "Processing for $SLEEP_TIME seconds..."
7
sleep $SLEEP_TIME
8
echo "=== Task $TASK_ID Completed at $(date) ==="
9
exit 0
10
EOF
11
chmod +x process.sh

Dockerfile和构建：

1
FROM alpine:3.18
2
COPY process.sh /usr/local/bin/
3
CMD ["/usr/local/bin/process.sh"]

1
docker build -t reg.westos.org/library/image-processor:v1 .
2
docker push reg.westos.org/library/image-processor:v1

8.3 创建并行Job#

parallel-job.yaml：

1
apiVersion: batch/v1
2
kind: Job
3
metadata:
4
  name: parallel-image-job
5
spec:
6
  completions: 10
7
  parallelism: 3
8
  backoffLimit: 20
9
  ttlSecondsAfterFinished: 300
10
  template:
11
    spec:
12
      restartPolicy: Never
13
      containers:
14
      - name: processor
15
        image: reg.westos.org/library/image-processor:v1
16
        env:
17
        - name: TASK_ID
18
          valueFrom:
19
            fieldRef:
20
              fieldPath: metadata.name

执行：

1
kubectl apply -f parallel-job.yaml
2
watch kubectl get jobs parallel-image-job
3
kubectl get pods -l job-name=parallel-image-job -w

9. 实战3：etcd备份完全指南#

9.1 为什么必须备份etcd？#

9.1.1 etcd在K8s中的地位#

1
┌─────────────────────────────────────────────────────────────────────────┐
2
│                    K8s集群的"大脑"与"记忆"                               │
3
├─────────────────────────────────────────────────────────────────────────┤
4
│                                                                         │
5
│  etcd存储了K8s集群的【一切状态信息】：                                    │
6
│                                                                         │
7
│  ┌─────────────────────────────────────────────────────────────────┐   │
8
│  │  所有资源对象                                                     │   │
9
│  │  ├── Namespace、Pod、Deployment、Service...                      │   │
10
│  │  ├── ConfigMap、Secret（包含敏感数据！）                          │   │
11
│  │  ├── PV、PVC、StorageClass                                       │   │
12
│  │  ├── RBAC规则（Role、ClusterRole、Binding）                      │   │
13
│  │  └── 所有自定义资源（CRD）                                        │   │
14
│  └─────────────────────────────────────────────────────────────────┘   │
15
│                                                                         │
16
│  集群配置                                                               │
17
│  ├── 节点信息、调度数据                                                 │
18
│  ├── 服务发现信息（Endpoints）                                         │
19
│  └── 租约（Lease）信息                                                  │
20
│                                                                         │
21
│  ⚠️ 一旦etcd数据丢失 = 整个集群配置全部丢失 = 集群报废！                  │
22
│                                                                         │
23
└─────────────────────────────────────────────────────────────────────────┘

9.1.2 什么情况需要从备份恢复？#

灾难场景	后果	需要备份恢复？
Master节点硬盘损坏	etcd数据全丢	✅ 必须
误删除关键资源（如所有Deployment）	业务全挂	✅ 必须
etcd集群脑裂	数据不一致	✅ 可能需要
K8s升级失败	集群无法启动	✅ 必须
勒索软件/恶意攻击	数据被加密或删除	✅ 必须

🧠 思维模型：把etcd想象成银行的账本数据库。所有客户的存款记录都在里面。如果没有备份，银行失火后客户的钱就”消失”了——虽然钱（容器镜像）还在，但谁有多少钱（Pod配置）的记录没了。

9.2 etcd备份原理#

9.2.1 备份的本质是什么？#

1
┌─────────────────────────────────────────────────────────────────────────┐
2
│                        etcd备份机制                                      │
3
├─────────────────────────────────────────────────────────────────────────┤
4
│                                                                         │
5
│  etcd数据存储在：/var/lib/etcd/member/                                   │
6
│  ├── snap/  ← 快照文件（数据的压缩存档）                                  │
7
│  └── wal/   ← 预写日志（Write-Ahead Log，记录所有变更）                   │
8
│                                                                         │
9
│  ❌ 直接复制这些文件？                                                    │
10
│  └── 不行！文件可能正在写入，复制出来的是不一致的"半成品"                  │
11
│                                                                         │
12
│  ✅ 正确做法：使用etcdctl snapshot save                                  │
13
│  └── etcd会：                                                           │
14
│      ├── 1. 暂停接受新写入（或使用MVCC快照）                              │
15
│      ├── 2. 将当前状态导出为一个一致的快照文件                            │
16
│      └── 3. 快照包含某一时刻的【完整数据镜像】                            │
17
│                                                                         │
18
│  快照文件（.db）：                                                       │
19
│  ├── 二进制格式，包含所有键值对                                          │
20
│  ├── 通常几MB到几百MB（取决于集群资源数量）                               │
21
│  └── 可以用来恢复到快照时刻的状态                                        │
22
│                                                                         │
23
└─────────────────────────────────────────────────────────────────────────┘

9.2.2 etcd的安全认证#

etcd使用**mTLS（双向TLS）**认证，备份时必须提供证书：

1
┌─────────────────────────────────────────────────────────────────────────┐
2
│                    etcd证书认证流程                                      │
3
├─────────────────────────────────────────────────────────────────────────┤
4
│                                                                         │
5
│  etcd服务端                              备份客户端（etcdctl）            │
6
│  ┌────────────┐                         ┌────────────┐                  │
7
│  │            │  ←─── 1. 建立TLS连接 ───→ │            │                  │
8
│  │   验证     │                         │   提供     │                  │
9
│  │ 客户端证书 │  ←─── 2. 客户端证书 ─────  │  客户端证书│                  │
10
│  │            │                         │            │                  │
11
│  │   允许     │  ───→ 3. 数据访问 ──────→ │  执行备份  │                  │
12
│  │   访问     │                         │            │                  │
13
│  └────────────┘                         └────────────┘                  │
14
│                                                                         │
15
│  需要的证书文件（kubeadm集群位于 /etc/kubernetes/pki/etcd/）：            │
16
│  ├── ca.crt      ← CA证书，用于验证服务端身份                            │
17
│  ├── server.crt  ← 客户端证书，证明"我有权访问"                          │
18
│  └── server.key  ← 客户端私钥，用于签名                                  │
19
│                                                                         │
20
└─────────────────────────────────────────────────────────────────────────┘

9.3 手动备份etcd（先学会手动，再自动化）#

9.3.1 第一步：确认etcd信息#

1
# 登录到master节点
2
ssh root@192.168.100.20
3

4
# 1. 确认etcd正在运行
5
kubectl get pods -n kube-system | grep etcd
6
# 输出示例：etcd-k8s-master   1/1   Running   0   10d
7

8
# 2. 查看etcd的配置（从静态Pod定义中获取）
9
cat /etc/kubernetes/manifests/etcd.yaml | grep -E "listen-client|cert-file|key-file|trusted-ca"
10
# 你会看到：
11
# --listen-client-urls=https://127.0.0.1:2379,https://192.168.100.20:2379
12
# --cert-file=/etc/kubernetes/pki/etcd/server.crt
13
# --key-file=/etc/kubernetes/pki/etcd/server.key
14
# --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
15

16
# 3. 确认证书文件存在
17
ls -la /etc/kubernetes/pki/etcd/
18
# 应该看到：ca.crt, server.crt, server.key 等文件

9.3.2 第二步：设置环境变量（简化命令）#

1
# 为了避免每次都输入长长的参数，先设置环境变量
2

3
# etcd API版本（必须是3，v2 API已废弃）
4
export ETCDCTL_API=3
5

6
# etcd服务地址（HTTPS协议）
7
export ETCD_ENDPOINTS="https://192.168.100.20:2379"
8

9
# 证书路径
10
export ETCD_CACERT="/etc/kubernetes/pki/etcd/ca.crt"
11
export ETCD_CERT="/etc/kubernetes/pki/etcd/server.crt"
12
export ETCD_KEY="/etc/kubernetes/pki/etcd/server.key"
13

14
# 验证变量是否设置成功
15
echo $ETCDCTL_API $ETCD_ENDPOINTS

9.3.3 第三步：拷贝etcdctl并测试etcd连接#

1
#拷贝etcdctl
2
etcd_id=crictl ps | grep etcd | awk '{print $1}'
3
PID=$(crictl inspect $etcd_id | grep pid | head -2 | tail -1 | awk '{print $2}' | tr -d ',')
4
# 直接去该进程的文件系统里拷
5
cp /proc/$PID/root/usr/local/bin/etcdctl /usr/local/bin/
6
chmod +x /usr/local/bin/etcdctl
7

8
# 先测试能否连接到etcd（这一步很重要！）
9
etcdctl --endpoints=$ETCD_ENDPOINTS \
10
        --cacert=$ETCD_CACERT \
11
        --cert=$ETCD_CERT \
12
        --key=$ETCD_KEY \
13
        endpoint health
14

15
# 预期输出：
16
# https://192.168.100.20:2379 is healthy: successfully committed proposal: took = 1.234ms
17

18
# 如果报错，常见原因：
19
# - "connection refused"：etcd没运行或端口不对
20
# - "certificate"相关：证书路径错误或证书不匹配
21
# - "context deadline exceeded"：网络不通或防火墙阻止

9.3.4 第四步：执行备份#

1
# 创建备份目录
2
mkdir -p /data/etcd-backup
3

4
# 生成带时间戳的备份文件名
5
BACKUP_FILE="/data/etcd-backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db"
6
echo "备份文件将保存到: $BACKUP_FILE"
7

8
# 执行备份！
9
etcdctl --endpoints=$ETCD_ENDPOINTS \
10
        --cacert=$ETCD_CACERT \
11
        --cert=$ETCD_CERT \
12
        --key=$ETCD_KEY \
13
        snapshot save $BACKUP_FILE
14

15
# 预期输出：
16
# {"level":"info","ts":"2024-01-15T10:30:00.123Z","msg":"created temporary snapshot file","path":"/data/etcd-backup/etcd-snapshot-20240115-103000.db.part"}
17
# {"level":"info","ts":"2024-01-15T10:30:00.456Z","msg":"saved snapshot","path":"/data/etcd-backup/etcd-snapshot-20240115-103000.db"}
18
# Snapshot saved at /data/etcd-backup/etcd-snapshot-20240115-103000.db

命令参数解释：

参数	含义	为什么需要
`--endpoints`	etcd服务地址	告诉etcdctl去哪里连接etcd
`--cacert`	CA证书	验证etcd服务端身份（防止连到假的etcd）
`--cert`	客户端证书	向etcd证明”我有权限访问”
`--key`	客户端私钥	配合证书使用，用于TLS握手
`snapshot save`	保存快照	etcdctl的备份子命令

9.3.5 第五步：验证备份文件#

1
# 查看备份文件大小
2
ls -lh /data/etcd-backup/
3
# 示例输出：
4
# -rw------- 1 root root 5.2M Jan 15 10:30 etcd-snapshot-20240115-103000.db
5

6
# 验证备份文件完整性（非常重要！）
7
etcdctl --write-out=table snapshot status $BACKUP_FILE
8

9
# 输出示例（表格形式）：
10
# +----------+----------+------------+------------+
11
# |   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
12
# +----------+----------+------------+------------+
13
# | 3c5a6d2e |    12345 |       1024 |     5.2 MB |
14
# +----------+----------+------------+------------+
15

16
# 各字段含义：
17
# HASH       - 快照的哈希值，用于校验完整性
18
# REVISION   - etcd的修订版本号（每次写操作+1）
19
# TOTAL KEYS - 快照中包含的键值对数量
20
# TOTAL SIZE - 快照文件大小

⚠️ 重要：如果snapshot status报错，说明备份文件损坏，不要使用！

9.3.6 手动备份完整脚本（一键执行版）#

1
#!/bin/bash
2
# 用途：手动备份etcd，可直接在master节点执行
3

4
set -e  # 任何命令失败立即退出
5

6
# ============== 配置区 ==============
7
ETCDCTL_API=3
8
ETCD_ENDPOINTS="https://192.168.100.20:2379"
9
ETCD_CACERT="/etc/kubernetes/pki/etcd/ca.crt"
10
ETCD_CERT="/etc/kubernetes/pki/etcd/server.crt"
11
ETCD_KEY="/etc/kubernetes/pki/etcd/server.key"
12
BACKUP_DIR="/data/etcd-backup"
13
RETENTION_DAYS=7  # 保留最近7天的备份
14
# ====================================
15

16
# 生成备份文件名
17
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
18
BACKUP_FILE="${BACKUP_DIR}/etcd-snapshot-${TIMESTAMP}.db"
19

20
echo "========================================="
21
echo "  etcd备份脚本"
22
echo "  时间: $(date)"
23
echo "  目标: $BACKUP_FILE"
24
echo "========================================="
25

26
# 创建备份目录
27
mkdir -p ${BACKUP_DIR}
28

29
# 测试连接
30
echo "[1/4] 测试etcd连接..."
31
etcdctl --endpoints=$ETCD_ENDPOINTS \
32
        --cacert=$ETCD_CACERT \
33
        --cert=$ETCD_CERT \
34
        --key=$ETCD_KEY \
35
        endpoint health
36

37
# 执行备份
38
echo "[2/4] 执行备份..."
39
etcdctl --endpoints=$ETCD_ENDPOINTS \
40
        --cacert=$ETCD_CACERT \
41
        --cert=$ETCD_CERT \
42
        --key=$ETCD_KEY \
43
        snapshot save $BACKUP_FILE
44

45
# 验证备份
46
echo "[3/4] 验证备份完整性..."
47
etcdctl snapshot status $BACKUP_FILE --write-out=table
48

49
# 清理旧备份
50
echo "[4/4] 清理${RETENTION_DAYS}天前的旧备份..."
51
find ${BACKUP_DIR} -name "etcd-snapshot-*.db" -mtime +${RETENTION_DAYS} -delete -print
52

53
echo "========================================="
54
echo "  备份完成！"
55
echo "  文件: $BACKUP_FILE"
56
echo "  大小: $(ls -lh $BACKUP_FILE | awk '{print $5}')"
57
echo "========================================="

1
# 保存脚本并执行
2
chmod +x manual-etcd-backup.sh
3
./manual-etcd-backup.sh

9.4 使用CronJob自动定时备份#

9.4.1 为什么不直接用Linux的crontab？#

方式	优点	缺点
Linux crontab	简单直接	只在一台机器上运行，机器挂了就不备份了；日志管理麻烦
K8s CronJob	高可用（可调度到任意节点）；统一管理；日志集中	需要容器化；依赖K8s本身运行

💡 最佳实践：两种方式都配置，CronJob作为主备份，crontab作为兜底。

9.4.2 构建备份镜像#

为什么需要专门的镜像？

CronJob运行在Pod中，Pod是隔离的容器环境。我们需要：

容器里有etcdctl工具
容器能访问etcd的证书
容器能把备份文件写到宿主机

Step 1：创建备份脚本

1
mkdir -p /root/k8s-demo/etcd-backup
2
cd /root/k8s-demo/etcd-backup
3

4
# 创建备份脚本（容器内执行版）
5
cat > backup.sh << 'EOF'
6
#!/bin/sh
7
# etcd备份脚本 - 容器版
8
# 环境变量由CronJob的Pod定义传入
9

10
set -e  # 任何错误立即退出
11

12
echo "========================================="
13
echo "  etcd自动备份"
14
echo "  时间: $(date)"
15
echo "========================================="
16

17
# 配置
18
BACKUP_DIR="/backup"
19
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
20
BACKUP_FILE="${BACKUP_DIR}/etcd-snapshot-${TIMESTAMP}.db"
21

22
# 创建目录
23
mkdir -p ${BACKUP_DIR}
24

25
# 执行备份
26
echo "[1/3] 执行备份..."
27
ETCDCTL_API=3 etcdctl snapshot save ${BACKUP_FILE} \
28
  --endpoints=${ETCD_ENDPOINTS} \
29
  --cacert=${ETCD_CACERT} \
30
  --cert=${ETCD_CERT} \
31
  --key=${ETCD_KEY}
32

33
# 验证备份
34
echo "[2/3] 验证备份..."
35
ETCDCTL_API=3 etcdctl snapshot status ${BACKUP_FILE} -w table
36

37
# 显示文件信息
38
ls -lh ${BACKUP_FILE}
39

40
# 清理7天前的旧备份
41
echo "[3/3] 清理旧备份..."
42
find ${BACKUP_DIR} -name "etcd-snapshot-*.db" -mtime +7 -delete -print 2>/dev/null || true
43

44
echo "========================================="
45
echo "  备份完成: ${BACKUP_FILE}"
46
echo "========================================="
47
EOF
48

49
chmod +x backup.sh

Step 2：创建Dockerfile

1
cat > Dockerfile << 'EOF'
2
# 基础镜像：Alpine（小巧、安全）
3
FROM alpine:3.18
4

5
# 安装etcdctl工具
6
# 为什么不用etcd镜像？因为我们只需要etcdctl客户端，完整etcd太大了
7
RUN apk add --no-cache curl && \
8
    ETCD_VER=v3.5.9 && \
9
    echo "下载etcd ${ETCD_VER}..." && \
10
    curl -L https://github.com/etcd-io/etcd/releases/download/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz -o /tmp/etcd.tar.gz && \
11
    tar xzvf /tmp/etcd.tar.gz -C /tmp && \
12
    mv /tmp/etcd-${ETCD_VER}-linux-amd64/etcdctl /usr/local/bin/ && \
13
    rm -rf /tmp/etcd* && \
14
    apk del curl && \
15
    etcdctl version
16

17
# 复制备份脚本
18
COPY backup.sh /usr/local/bin/backup.sh
19

20
# 设置入口点
21
ENTRYPOINT ["/usr/local/bin/backup.sh"]
22
EOF

Step 3：构建并推送镜像

1
# 构建镜像
2
docker build -t reg.westos.org/library/etcd-backup:v1 .
3

4
# 验证镜像
5
docker run --rm reg.westos.org/library/etcd-backup:v1 etcdctl version
6

7
# 推送到私有仓库
8
docker push reg.westos.org/library/etcd-backup:v1

9.4.3 在Master节点创建备份目录#

1
# CronJob会把备份文件写到这个目录
2
ssh root@192.168.100.20 "mkdir -p /data/etcd-backup && chmod 755 /data/etcd-backup"

9.4.4 创建CronJob资源#

1
apiVersion: batch/v1
2
kind: CronJob
3
metadata:
4
  name: etcd-backup
5
  namespace: kube-system        # 放在系统命名空间，与etcd在一起
6
spec:
7
  # ============== 调度配置 ==============
8
  schedule: "0 2 * * *"         # Cron表达式：每天凌晨2点执行
9
  #         │ │ │ │ │
10
  #         │ │ │ │ └── 星期几 (0-7, 0和7都是周日)
11
  #         │ │ │ └──── 月份 (1-12)
12
  #         │ │ └────── 日期 (1-31)
13
  #         │ └──────── 小时 (0-23)
14
  #         └────────── 分钟 (0-59)
15

16
  concurrencyPolicy: Forbid     # 禁止并发：上一个没跑完，不启动新的
17
  successfulJobsHistoryLimit: 3 # 保留最近3个成功Job的记录
18
  failedJobsHistoryLimit: 1     # 保留最近1个失败Job的记录
19
  startingDeadlineSeconds: 200  # 如果错过调度时间超过200秒，跳过本次
20

21
  # ============== Job模板 ==============
22
  jobTemplate:
23
    spec:
24
      template:
25
        spec:
26
          restartPolicy: OnFailure  # 失败时重试
27

28
          # 调度到Master节点（因为etcd证书在Master上）
29
          nodeSelector:
30
            node-role.kubernetes.io/control-plane: ""
31

32
          # 容忍Master节点的污点
33
          tolerations:
34
          - key: node-role.kubernetes.io/control-plane
35
            operator: Exists
36
            effect: NoSchedule
37

38
          containers:
39
          - name: etcd-backup
40
            image: reg.westos.org/library/etcd-backup:v1
41

42
            # 通过环境变量传递配置（脚本中使用）
43
            env:
44
            - name: ETCD_ENDPOINTS
45
              value: "https://192.168.100.20:2379"
46
            - name: ETCD_CACERT
47
              value: "/etc/kubernetes/pki/etcd/ca.crt"
48
            - name: ETCD_CERT
49
              value: "/etc/kubernetes/pki/etcd/server.crt"
50
            - name: ETCD_KEY
51
              value: "/etc/kubernetes/pki/etcd/server.key"
52

53
            # 挂载卷
54
            volumeMounts:
55
            - name: etcd-certs
56
              mountPath: /etc/kubernetes/pki/etcd  # 挂载证书目录
57
              readOnly: true                       # 只读，安全
58
            - name: backup-dir
59
              mountPath: /backup                   # 备份文件写入位置
60

61
          # 卷定义
62
          volumes:
63
          - name: etcd-certs
64
            hostPath:
65
              path: /etc/kubernetes/pki/etcd      # Master上的证书目录
66
              type: Directory
67
          - name: backup-dir
68
            hostPath:
69
              path: /data/etcd-backup             # Master上的备份目录
70
              type: DirectoryOrCreate             # 不存在则创建

关键配置解释：

1
┌─────────────────────────────────────────────────────────────────────────┐
2
│                    CronJob配置详解                                       │
3
├─────────────────────────────────────────────────────────────────────────┤
4
│                                                                         │
5
│  为什么要用nodeSelector调度到Master？                                    │
6
│  └── etcd证书只在Master节点的/etc/kubernetes/pki/etcd目录下              │
7
│      如果调度到Worker节点，证书目录是空的，备份必然失败                    │
8
│                                                                         │
9
│  为什么要配置tolerations容忍污点？                                        │
10
│  └── Master节点默认有污点，普通Pod无法调度上去                            │
11
│      node-role.kubernetes.io/control-plane:NoSchedule                   │
12
│      必须容忍这个污点，Pod才能调度到Master                                │
13
│                                                                         │
14
│  为什么用hostPath挂载？                                                  │
15
│  └── 证书和备份文件都在宿主机上，必须用hostPath访问                       │
16
│      etcd-certs: 读取证书用于认证                                        │
17
│      backup-dir: 写入备份文件到宿主机                                    │
18
│                                                                         │
19
│  为什么concurrencyPolicy设为Forbid？                                     │
20
│  └── 备份是独占操作，同时运行多个备份没意义，还可能冲突                    │
21
│                                                                         │
22
└─────────────────────────────────────────────────────────────────────────┘

9.4.5 部署CronJob#

1
# 应用CronJob
2
kubectl apply -f etcd-backup-cronjob.yaml
3

4
# 查看CronJob状态
5
kubectl get cronjob -n kube-system etcd-backup
6
# NAME          SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
7
# etcd-backup   0 2 * * *   False     0        <none>          5s

9.4.6 手动触发测试（不等到凌晨2点）#

1
# 从CronJob模板创建一个立即执行的Job
2
kubectl create job etcd-backup-manual --from=cronjob/etcd-backup -n kube-system
3

4
# 查看Job状态
5
kubectl get jobs -n kube-system | grep etcd-backup
6
# etcd-backup-manual   1/1           12s        20s
7

8
# 实时查看备份日志
9
kubectl logs -n kube-system -l job-name=etcd-backup-manual -f
10

11
# 预期看到：
12
# =========================================
13
#   etcd自动备份
14
#   时间: Mon Jan 15 10:30:00 UTC 2024
15
# =========================================
16
# [1/3] 执行备份...
17
# Snapshot saved at /backup/etcd-snapshot-20240115-103000.db
18
# [2/3] 验证备份...
19
# +----------+----------+------------+------------+
20
# |   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
21
# +----------+----------+------------+------------+
22
# | 3c5a6d2e |    12345 |       1024 |     5.2 MB |
23
# +----------+----------+------------+------------+
24
# [3/3] 清理旧备份...
25
# =========================================
26
#   备份完成: /backup/etcd-snapshot-20240115-103000.db
27
# =========================================

9.4.7 验证备份文件#

1
# 登录Master查看备份文件
2
ssh root@192.168.100.20 "ls -lh /data/etcd-backup/"
3
# -rw------- 1 root root 5.2M Jan 15 10:30 etcd-snapshot-20240115-103000.db
4

5
# 验证备份文件完整性
6
ssh root@192.168.100.20 "ETCDCTL_API=3 etcdctl snapshot status /data/etcd-backup/etcd-snapshot-*.db --write-out=table"

9.5 备份策略建议#

1
┌─────────────────────────────────────────────────────────────────────────┐
2
│                    生产环境备份策略                                       │
3
├─────────────────────────────────────────────────────────────────────────┤
4
│                                                                         │
5
│  备份频率：                                                              │
6
│  ├── 生产环境：每2-4小时一次                                             │
7
│  ├── 测试环境：每天一次                                                  │
8
│  └── 重大变更前：手动备份一次                                            │
9
│                                                                         │
10
│  备份保留：                                                              │
11
│  ├── 本地保留：7天                                                       │
12
│  └── 远程备份：至少30天（异地存储！）                                     │
13
│                                                                         │
14
│  备份存储：                                                              │
15
│  ├── 本地：/data/etcd-backup（快速恢复）                                 │
16
│  ├── NFS：挂载网络存储（防单点故障）                                     │
17
│  └── 对象存储：S3/OSS/MinIO（异地容灾）                                  │
18
│                                                                         │
19
│  ⚠️ 关键原则：备份文件绝不能只存在etcd所在的同一台机器上！                 │
20
│     机器挂了，etcd和备份一起丢失 = 没有备份                               │
21
│                                                                         │
22
└─────────────────────────────────────────────────────────────────────────┘

10. 实战4：etcd恢复演练（灾难恢复）#

10.1 恢复原理#

1
┌─────────────────────────────────────────────────────────────────────────┐
2
│                    etcd恢复原理                                          │
3
├─────────────────────────────────────────────────────────────────────────┤
4
│                                                                         │
5
│  etcdctl snapshot restore 做了什么？                                    │
6
│                                                                         │
7
│  1. 读取快照文件 (.db)                                                   │
8
│     └── 解析其中的所有键值对                                             │
9
│                                                                         │
10
│  2. 创建新的数据目录                                                     │
11
│     └── --data-dir=/var/lib/etcd （必须是空目录或不存在）                │
12
│                                                                         │
13
│  3. 初始化etcd成员信息                                                   │
14
│     ├── --name：当前节点名称                                             │
15
│     ├── --initial-cluster：集群成员列表                                  │
16
│     └── --initial-advertise-peer-urls：节点间通信地址                    │
17
│                                                                         │
18
│  4. 写入数据                                                             │
19
│     └── 将快照数据写入新数据目录                                         │
20
│                                                                         │
21
│  ⚠️ 注意：restore后的etcd是"新集群"，节点ID会变化                        │
22
│     所以必须重新配置集群成员信息                                         │
23
│                                                                         │
24
└─────────────────────────────────────────────────────────────────────────┘

10.2 准备工作#

⚠️ 警告：以下操作会破坏集群，仅在测试环境执行！

1
# 第一步：创建虚拟机快照（必做！）
2
# 在VMware/KVM中为所有节点创建快照
3
# 快照名称建议："Before-etcd-recovery-test-$(date +%Y%m%d)"
4

5
# 第二步：确保有可用的备份
6
kubectl create job etcd-backup-before-test --from=cronjob/etcd-backup -n kube-system
7
kubectl wait --for=condition=complete job/etcd-backup-before-test -n kube-system --timeout=60s
8

9
# 验证备份存在
10
ssh root@192.168.100.20 "ls -lh /data/etcd-backup/"

10.3 模拟创建业务资源#

1
# 创建一些测试资源，恢复后验证是否存在
2
kubectl create namespace recovery-test
3
kubectl create deployment nginx --image=nginx:1.20 --replicas=3 -n recovery-test
4
kubectl expose deployment nginx --port=80 -n recovery-test
5
kubectl create configmap test-config --from-literal=env=production --from-literal=version=1.0 -n recovery-test
6
kubectl create secret generic test-secret --from-literal=password=abc123 -n recovery-test
7

8
# 记录当前资源（恢复后对比）
9
echo "=== 当前资源 ==="
10
kubectl get all,cm,secret -n recovery-test

10.4 模拟etcd灾难#

1
# 登录Master节点
2
ssh root@192.168.100.20
3

4
# 1. 停止etcd（移走静态Pod配置）
5
mv /etc/kubernetes/manifests/etcd.yaml /tmp/etcd.yaml.bak
6

7
# 等待etcd Pod终止
8
sleep 10
9
crictl ps | grep etcd  # 应该看不到etcd容器了
10

11
# 2. 破坏etcd数据（模拟磁盘损坏）
12
mv /var/lib/etcd /var/lib/etcd.broken
13

14
# 此时集群完全不可用
15
kubectl get nodes
16
# Error: dial tcp: lookup ... connect: connection refused

10.5 执行恢复#

1
# 以下所有操作在Master节点（192.168.100.20）上执行
2

3
# ============== 第一步：停止所有控制平面组件 ==============
4
cd /etc/kubernetes/manifests
5
mv kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml /tmp/
6
# 等待组件停止
7
sleep 15
8

9
# ============== 第二步：恢复etcd数据 ==============
10
# 找到最新的备份文件
11
BACKUP_FILE=$(ls -t /data/etcd-backup/*.db | head -1)
12
echo "使用备份文件: $BACKUP_FILE"
13

14
# 执行恢复（关键命令！）
15
ETCDCTL_API=3 etcdctl snapshot restore $BACKUP_FILE \
16
  --data-dir=/var/lib/etcd \
17
  --name=k8s-master \
18
  --initial-cluster=k8s-master=https://192.168.100.20:2380 \
19
  --initial-advertise-peer-urls=https://192.168.100.20:2380
20

21
# 参数解释：
22
# --data-dir          : 恢复到的数据目录（会自动创建）
23
# --name              : 当前etcd节点名称（必须与原来一致）
24
# --initial-cluster   : 集群成员列表（格式：name=url）
25
# --initial-advertise-peer-urls : 节点间通信地址
26

27
# ============== 第三步：设置正确的权限 ==============
28
chown -R root:root /var/lib/etcd
29
chmod 700 /var/lib/etcd
30

31
# ============== 第四步：恢复控制平面组件 ==============
32
mv /tmp/etcd.yaml.bak /etc/kubernetes/manifests/etcd.yaml
33
mv /tmp/kube-apiserver.yaml /etc/kubernetes/manifests/
34
mv /tmp/kube-controller-manager.yaml /etc/kubernetes/manifests/
35
mv /tmp/kube-scheduler.yaml /etc/kubernetes/manifests/
36

37
# 等待组件启动
38
echo "等待控制平面启动..."
39
sleep 30
40

41
# 退出Master
42
exit

10.6 验证恢复结果#

1
# 回到管理机验证
2

3
# 1. 检查节点状态
4
kubectl get nodes
5
# NAME         STATUS   ROLES           AGE   VERSION
6
# k8s-master   Ready    control-plane   10d   v1.28.0
7
# k8s-node1    Ready    <none>          10d   v1.28.0
8
# k8s-node2    Ready    <none>          10d   v1.28.0
9

10
# 2. 检查系统组件
11
kubectl get pods -n kube-system
12
# 所有组件应该都是Running
13

14
# 3. 检查测试资源是否恢复
15
kubectl get all,cm,secret -n recovery-test
16
# 应该看到之前创建的nginx Deployment、Service、ConfigMap、Secret
17

18
# 4. 验证应用可访问
19
kubectl exec -it $(kubectl get pod -n recovery-test -o name | head -1) -n recovery-test -- curl localhost
20
# 应该看到nginx欢迎页

10.7 恢复后清理#

1
# 删除测试资源
2
kubectl delete namespace recovery-test
3

4
# 删除测试Job
5
kubectl delete job etcd-backup-before-test -n kube-system
6

7
# 清理Master上的临时文件
8
ssh root@192.168.100.20 "rm -rf /var/lib/etcd.broken"

10.8 恢复流程总结#

1
┌─────────────────────────────────────────────────────────────────────────┐
2
│                    etcd恢复完整流程                                      │
3
├─────────────────────────────────────────────────────────────────────────┤
4
│                                                                         │
5
│  第一步：停止所有控制平面组件                                             │
6
│  └── 移走 /etc/kubernetes/manifests/ 下的yaml文件                       │
7
│                                                                         │
8
│  第二步：清理旧数据（如果存在损坏的数据）                                  │
9
│  └── rm -rf /var/lib/etcd 或 mv /var/lib/etcd /var/lib/etcd.old        │
10
│                                                                         │
11
│  第三步：使用etcdctl snapshot restore恢复数据                            │
12
│  └── 指定正确的--name、--initial-cluster等参数                          │
13
│                                                                         │
14
│  第四步：设置权限                                                        │
15
│  └── chown -R root:root /var/lib/etcd && chmod 700 /var/lib/etcd       │
16
│                                                                         │
17
│  第五步：恢复控制平面组件                                                │
18
│  └── 移回yaml文件到 /etc/kubernetes/manifests/                          │
19
│                                                                         │
20
│  第六步：验证                                                            │
21
│  └── kubectl get nodes/pods，确认集群正常                               │
22
│                                                                         │
23
└─────────────────────────────────────────────────────────────────────────┘

总结#

本章学习了三种特殊的工作负载：

DaemonSet：

每个节点运行一个Pod
用于日志收集、监控、网络插件
支持滚动更新和回滚

Job：

一次性任务执行
支持并行和失败重试
自动清理机制

CronJob：

定时任务调度
Cron表达式控制执行时间
并发策略控制

实战收获：

部署Fluentd DaemonSet收集日志
使用Job并行处理任务
CronJob定时备份etcd
etcd备份恢复演练

生产建议：

DaemonSet用于节点级服务
Job用于批处理任务
CronJob必须备份关键数据
etcd备份是集群安全的最后防线

八、配置管理：ConfigMap和Secret#

1. 为什么需要配置管理#

在前面章节中，我们把配置信息直接写在YAML文件里。这样做有严重问题：

问题：

密码明文存储
无法复用配置
环境差异难以处理
版本管理混乱

Kubernetes解决方案：

ConfigMap：存储非敏感配置（数据库地址、端口）
Secret：存储敏感信息（密码、密钥）

2. ConfigMap：配置数据的”字典”#

2.1 ConfigMap是什么#

ConfigMap 存储非敏感配置数据，以键值对形式。

创建方式：

1
# 方式1：从字面量
2
kubectl create configmap app-config \
3
  --from-literal=DB_HOST=mysql.example.com \
4
  --from-literal=DB_PORT=3306
5

6
# 方式2：从文件
7
kubectl create configmap app-config --from-file=app.properties
8

9
# 方式3：从YAML

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: mysql-config
5
data:
6
  DB_HOST: "mysql-service"
7
  DB_PORT: "3306"
8
  my.cnf: |
9
    [mysqld]
10
    max_connections=200

2.2 ConfigMap使用方式#

方式1：环境变量注入

1
#方式1：单独导入
2
containers:
3
- name: app
4
  image: nginx:1.20
5
  env:
6
  - name: DATABASE_HOST
7
    valueFrom:
8
      configMapKeyRef:
9
        name: mysql-config
10
        key: DB_HOST
11

12
#方式2: 批量导入
13
containers:
14
- name: app
15
  image: nginx:1.20
16
  envFrom:
17
  - configMapRef:
18
      name: mysql-config

方式2：文件挂载

1
containers:
2
- name: app
3
  volumeMounts:
4
  - name: config-volume
5
    mountPath: /etc/config
6
volumes:
7
- name: config-volume
8
  configMap:
9
    name: mysql-config

2.3 ConfigMap热更新#

⚠️ 重要特性：

Volume方式：支持热更新（30-60秒）
环境变量：需要重启Pod

3. Secret：敏感数据的”保险箱”#

3.1 Secret是什么#

Secret 存储敏感信息，数据Base64编码（注意：不是加密！）

Secret类型：

类型	说明	用途
Opaque	通用类型	密码、密钥
kubernetes.io/dockerconfigjson	Docker凭证	拉取私有镜像
kubernetes.io/tls	TLS证书	HTTPS

3.2 Secret创建方式#

1
# 创建通用Secret
2
kubectl create secret generic mysql-secret \
3
  --from-literal=username=root \
4
  --from-literal=password='MyP@ssw0rd123'
5

6
# 创建Docker镜像仓库Secret
7
kubectl create secret docker-registry harbor-secret \
8
  --docker-server=reg.westos.org \
9
  --docker-username=admin \
10
  --docker-password=Harbor12345

YAML方式（stringData自动编码）：

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: mysql-secret
5
type: Opaque
6
stringData:
7
  username: root
8
  password: MyP@ssw0rd123

3.3 Secret使用方式#

环境变量注入：

1
#方式1：单个读取
2
containers:
3
- name: mysql
4
  image: mysql:8.0
5
  env:
6
  - name: MYSQL_ROOT_PASSWORD
7
    valueFrom:
8
      secretKeyRef:
9
        name: mysql-secret
10
        key: password
11

12
#方式2: 批量导入
13
containers:
14
- name: mysql
15
  image: mysql:8.0
16
  envFrom:
17
  - secretRef:
18
      name: mysql-secret

文件挂载：

1
containers:
2
- name: app
3
  volumeMounts:
4
  - name: secret-volume
5
    mountPath: /etc/secret
6
    readOnly: true
7
volumes:
8
- name: secret-volume
9
  secret:
10
    secretName: mysql-secret

⚠️ 安全注意：

Base64不是加密
不要提交到Git
使用RBAC限制访问
避免在日志中打印

4. 实战：ConfigMap和Secret综合应用#

4.1 实战目标#

创建一个完整的Web应用，展示配置管理的最佳实践。

架构：

1
ConfigMap (app-config)  →  环境变量
2
Secret (db-secret)      →  数据库密码
3
Nginx Pod              →  显示配置信息

4.2 创建ConfigMap#

app-configmap.yaml：

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: app-config
5
data:
6
  APP_NAME: "ConfigDemo"
7
  APP_ENV: "production"
8
  DB_HOST: "mysql-service"
9
  DB_PORT: "3306"
10

11
  index.html: |
12
    <!DOCTYPE html>
13
    <html>
14
    <head>
15
      <title>Config Demo</title>
16
      <style>
17
        body { font-family: Arial; max-width: 800px; margin: 50px auto; padding: 20px; }
18
        .box { background: white; padding: 20px; border-radius: 8px; margin: 10px 0; }
19
        h1 { color: #333; }
20
      </style>
21
    </head>
22
    <body>
23
      <h1>ConfigMap和Secret演示</h1>
24
      <div class="box">
25
        <h2>配置信息：</h2>
26
        <p>应用名称：<span id="app-name"></span></p>
27
        <p>运行环境：<span id="app-env"></span></p>
28
        <p>数据库地址：<span id="db-host"></span></p>
29
      </div>
30
      <div class="box">
31
        <h2>敏感信息（从Secret读取）：</h2>
32
        <p>数据库用户：<span id="db-user"></span></p>
33
        <p>数据库密码：<span id="db-pass"></span></p>
34
      </div>
35
    </body>
36
    </html>

1
kubectl apply -f app-configmap.yaml

4.3 创建Secret#

db-secret.yaml：

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: db-secret
5
type: Opaque
6
stringData:
7
  DB_USER: "root"
8
  DB_PASSWORD: "MySecretPass123"

1
kubectl apply -f db-secret.yaml

4.4 创建应用#

app-deployment.yaml：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: config-demo
5
spec:
6
  replicas: 1
7
  selector:
8
    matchLabels:
9
      app: config-demo
10
  template:
11
    metadata:
12
      labels:
13
        app: config-demo
14
    spec:
15
      containers:
16
      - name: nginx
17
        image: nginx:1.20
18
        ports:
19
        - containerPort: 80
20

21
        # ConfigMap环境变量
22
        env:
23
        - name: APP_NAME
24
          valueFrom:
25
            configMapKeyRef:
26
              name: app-config
27
              key: APP_NAME
28
        - name: APP_ENV
29
          valueFrom:
30
            configMapKeyRef:
31
              name: app-config
32
              key: APP_ENV
33
        - name: DB_HOST
34
          valueFrom:
35
            configMapKeyRef:
36
              name: app-config
37
              key: DB_HOST
38

39
        # Secret环境变量
40
        - name: DB_USER
41
          valueFrom:
42
            secretKeyRef:
43
              name: db-secret
44
              key: DB_USER
45
        - name: DB_PASSWORD
46
          valueFrom:
47
            secretKeyRef:
48
              name: db-secret
49
              key: DB_PASSWORD
50

51
        volumeMounts:
52
        - name: html
53
          mountPath: /usr/share/nginx/html/index.html
54
          subPath: index.html
55

56
        # 启动脚本：生成页面
57
        command: ["/bin/sh", "-c"]
58
        args:
59
        - |
60
          cat > /usr/share/nginx/html/index.html << EOF
61
          <!DOCTYPE html>
62
          <html>
63
          <head><title>Config Demo</title>
64
          <style>
65
            body { font-family: Arial; max-width: 800px; margin: 50px auto; padding: 20px; background: #f0f0f0; }
66
            .box { background: white; padding: 20px; border-radius: 8px; margin: 10px 0; box-shadow: 0 2px 4px rgba(0,0,0,0.1); }
67
            h1 { color: #333; }
68
            .label { font-weight: bold; }
69
            .value { color: #0066cc; }
70
          </style>
71
          </head>
72
          <body>
73
            <h1>🎯 ConfigMap和Secret演示</h1>
74
            <div class="box">
75
              <h2>ConfigMap配置：</h2>
76
              <p><span class="label">应用名称：</span><span class="value">$APP_NAME</span></p>
77
              <p><span class="label">运行环境：</span><span class="value">$APP_ENV</span></p>
78
              <p><span class="label">数据库地址：</span><span class="value">$DB_HOST</span></p>
79
            </div>
80
            <div class="box">
81
              <h2>Secret敏感信息：</h2>
82
              <p><span class="label">数据库用户：</span><span class="value">$DB_USER</span></p>
83
              <p><span class="label">数据库密码：</span><span class="value">$DB_PASSWORD</span></p>
84
            </div>
85
            <div class="box">
86
              <p>💡 提示：此页面展示了ConfigMap和Secret的使用</p>
87
            </div>
88
          </body>
89
          </html>
90
          EOF
91
          nginx -g 'daemon off;'
92

93
      volumes:
94
      - name: html
95
        emptyDir: {}
96
---
97
apiVersion: v1
98
kind: Service
99
metadata:
100
  name: config-demo
101
spec:
102
  selector:
103
    app: config-demo
104
  ports:
105
  - port: 80
106
    targetPort: 80
107
    nodePort: 30088
108
  type: NodePort

1
kubectl apply -f app-deployment.yaml

4.5 访问和测试#

1
# 查看Pod
2
kubectl get pods -l app=config-demo
3

4
# 获取Service地址
5
kubectl get svc config-demo
6

7
# 访问应用（浏览器打开）
8
http://192.168.100.21:30088

测试配置更新：

1
# 1. 更新ConfigMap
2
kubectl patch configmap app-config -p '{"data":{"APP_ENV":"development"}}'
3

4
# 2. 重启Pod（环境变量需要重启）
5
kubectl rollout restart deployment config-demo
6

7
# 3. 再次访问，看到环境变量已更新

测试Secret更新：

1
# 更新Secret
2
kubectl patch secret db-secret -p '{"stringData":{"DB_PASSWORD":"NewPassword456"}}'
3

4
# 重启Pod
5
kubectl rollout restart deployment config-demo
6

7
# 验证密码已更新

总结#

ConfigMap：

存储非敏感配置
支持文件热更新
多种创建和使用方式

Secret：

存储敏感信息
Base64编码（不是加密）
RBAC权限控制

最佳实践：

配置与代码分离
不要把Secret提交到Git
环境变量用于简单配置
文件挂载用于复杂配置
生产环境启用etcd加密

Simple Blog

七、DaemonSet 和 Job：特殊的工作负载#

1. DaemonSet：每个节点都需要的”守护神”#

1.1 DaemonSet是什么#

1.2 为什么需要DaemonSet#

1.3 DaemonSet的典型应用场景#

2. DaemonSet的实现逻辑和工作原理#

2.1 DaemonSet Controller的工作机制#

2.2 DaemonSet调度机制#

2.3 DaemonSet的自我修复#

3. DaemonSet配置详解#

3.1 基本YAML结构#

3.2 节点选择：控制在哪些节点上运行#

3.3 污点和容忍：在特殊节点上运行#

4. DaemonSet更新策略#

4.1 更新策略类型#

4.2 滚动更新（RollingUpdate）#

4.3 手动更新（OnDelete）#

4.4 回滚DaemonSet#

5. Job：一次性任务执行器#

5.1 Job是什么#

5.2 Job的核心特点#

5.3 Job的工作模式#

5.4 Job配置详解#

5.5 Job失败处理#

5.6 Job清理#

6. CronJob：定时任务调度器#

6.1 CronJob是什么#

6.2 Cron表达式详解#

6.3 CronJob基本配置#

6.4 并发策略详解#

6.5 CronJob管理命令#

7. 实战1：部署Fluentd DaemonSet收集日志#

7.1 实战目标#

7.2 理解Fluentd工作原理#

7.3 准备ConfigMap配置#

7.4 创建Fluentd DaemonSet#

7.5 创建RBAC权限#

7.6 部署和验证#

8. 实战2：使用Job执行一次性数据处理任务#

8.1 实战目标#

8.2 准备测试镜像#

8.3 创建并行Job#

9. 实战3：etcd备份完全指南#

9.1 为什么必须备份etcd？#

9.1.1 etcd在K8s中的地位#

9.1.2 什么情况需要从备份恢复？#

9.2 etcd备份原理#

9.2.1 备份的本质是什么？#

9.2.2 etcd的安全认证#

9.3 手动备份etcd（先学会手动，再自动化）#

9.3.1 第一步：确认etcd信息#

9.3.2 第二步：设置环境变量（简化命令）#

9.3.3 第三步：拷贝etcdctl并测试etcd连接#

9.3.4 第四步：执行备份#

9.3.5 第五步：验证备份文件#

9.3.6 手动备份完整脚本（一键执行版）#

9.4 使用CronJob自动定时备份#

9.4.1 为什么不直接用Linux的crontab？#

9.4.2 构建备份镜像#

9.4.3 在Master节点创建备份目录#

9.4.4 创建CronJob资源#

9.4.5 部署CronJob#

9.4.6 手动触发测试（不等到凌晨2点）#

9.4.7 验证备份文件#

9.5 备份策略建议#

10. 实战4：etcd恢复演练（灾难恢复）#

10.1 恢复原理#

10.2 准备工作#

10.3 模拟创建业务资源#

10.4 模拟etcd灾难#

10.5 执行恢复#

10.6 验证恢复结果#

10.7 恢复后清理#

10.8 恢复流程总结#

总结#

八、配置管理：ConfigMap和Secret#

1. 为什么需要配置管理#

2. ConfigMap：配置数据的”字典”#

2.1 ConfigMap是什么#