在 Kubernetes 的学习和实操过程中，很多配置表面看起来只是“照着写 YAML”，但一旦遇到异常或复杂场景，就会发现不理解底层逻辑很难排查问题。本文围绕几个高频、易混淆的核心知识点，从设计目的 + 实验现象两个角度进行整理，作为一份学习笔记。

 

1. Deployment 为什么不直接管理 Pod？

实验现象

• 修改 Deployment 镜像版本

• 使用 kubectl get rs 会发现新旧 ReplicaSet 同时存在

• 回滚时并不会重新创建 Pod，而是切换 RS

设计逻辑

Kubernetes 采用 三层控制模型：

• Pod：最小运行单元，只负责运行容器

• ReplicaSet：只做一件事 —— 保证 Pod 数量符合期望

• Deployment：只做“发布策略”，不关心具体 Pod

Deployment 通过“创建 / 缩容 ReplicaSet”来完成：

• 滚动更新

• 版本回滚

• 灰度发布

ReplicaSet 是执行者，Deployment 是决策者
分层是为了 解耦发布策略和副本管理

实验验证点

kubectl rollout history deployment demo-app
kubectl rollout undo deployment demo-app --to-revision=1

旧 RS 并不会立即删除，这正是回滚能“秒级完成”的原因。

---

2. Init 容器 vs Sidecar：不是“辅助”，而是“时序不同”

实验对比

• Init 容器失败 → Pod 一直处于 Init 状态

• Sidecar 崩溃 → 只重启自身，主容器不受影响

核心差异

对比点	Init 容器	Sidecar
执行时机	主容器前，串行	与主容器并行
生命周期	执行完即退出	与 Pod 同生共死
典型用途	依赖检查、初始化	日志、代理、监控

实操示例

• Init：启动前检测 Redis 是否可连

• Sidecar：HTTP 服务旁路 Envoy 做流量治理

Init 解决的是「能不能启动」
Sidecar 解决的是「如何更好地运行」

---

3. 静态 Pod：为什么能绕过 API Server？

实验现象

• 删除静态 Pod 的 YAML 文件，Pod 自动消失

• kubectl delete pod 对静态 Pod 无效

设计目的

静态 Pod 的存在是为了解决一个启动悖论：

API Server 还没起来，核心组件怎么跑？

因此：

• kubelet 直接监听本地目录

• 不依赖 API Server

• 专门用于启动控制平面组件

实验路径

ls /etc/kubernetes/manifests

这里的 YAML 一旦修改，kubelet 会立即响应。

---

4. CronJob：安全性和可控性不是“可选项”

实验问题

• 明文写密码 → YAML 泄露风险

• 并发执行 → 数据互相覆盖

• Pod 删除 → 结果文件消失

关键设计点

1）敏感信息

使用 Secret 注入环境变量，而不是硬编码：

env:
- name: DB_PASS
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: password

2）结果持久化

定时任务 ≠ 临时任务
必须挂载 PVC，避免 Pod 销毁即丢数据。

3）并发控制

concurrencyPolicy: Forbid

防止多个 Job 同时操作同一资源。

---

5. Pod 是谁在“关”？权限和控制器是两回事

实验现象

• 手动 kubectl delete pod

• Pod 很快又被拉起

原因拆解

权限层（RBAC）

是否“能删”由 RBAC 决定，本质是：

pods/delete

控制层（控制器）

是否“会重建”由控制器决定：

• Deployment / RS 发现副本数不够

• 自动补齐 Pod

正确操作顺序

kubectl scale deployment demo --replicas=0

而不是直接删 Pod。

---

6. StatefulSet：不是“高级 Deployment”，而是完全不同的模型

实验对比

• Deployment Pod 重建后名字变化

• StatefulSet Pod 重建后：

  • 名字不变

  • PVC 不变

  • DNS 不变

核心能力

• 稳定网络标识

• 一 Pod 一存储

• 有序启动 / 更新 / 缩容

选型原则

• 无状态服务 → Deployment

• 依赖身份、顺序、数据的服务 → StatefulSet

例如：

• MySQL / Etcd / ZooKeeper → StatefulSet

• Web / API / 网关 → Deployment

---

总结

Kubernetes 的复杂度并不来自“组件多”，而是来自设计上的强约束：

• 不同控制器只做一件事

• 状态与运行强解耦

• 自动化优先于人工干预

通过实验现象反推设计动机，比死记 YAML 字段要高效得多。