Appearance
核心对象与控制器
这篇笔记聚焦 Kubernetes 最基础、也最容易只背名词不讲透的一条主线：
Pod是什么ReplicaSet是什么Deployment为什么重要控制器到底在控制什么
如果这条主线没有搞清楚，后面看 Service、Ingress、扩缩容和发布，都会缺少抓手。
1. 为什么 Kubernetes 要用“对象”来描述系统
Kubernetes 不是让你一条条手工执行容器管理命令，而是希望你声明：
- 我要跑什么
- 要跑多少个
- 用什么镜像
- 暴露什么端口
- 出故障后应该恢复到什么状态
这些描述，最终都会落成“对象”。
这里的 对象 可以理解成 Kubernetes 用来描述系统目标状态的一种资源模型。
2. Pod 到底是什么
Pod 是 Kubernetes 最小部署单元。
它可以看成 一组应该作为一个整体被调度和运行的容器。
为什么不是直接调度单个容器？
因为 Kubernetes 需要一个更高层抽象，来表达：
- 哪些容器共享网络命名空间
- 哪些容器共享生命周期
- 哪些容器应该一起被部署
大多数业务场景里，一个 Pod 里通常只有一个主业务容器。
但也可能有多个协作容器，例如：
- 主业务容器
- 负责日志、代理或初始化任务的辅助容器
3. 为什么 Pod 不是稳定的长期个体
这是很多人一开始容易误解的点。
Pod 可以被重新创建、重新调度、重新分配 IP。
这意味着：
- Pod 名字和实例不是永远不变的
- Pod IP 也不是稳定入口
- 不应该让别的服务直接依赖某个 Pod 的瞬时地址
这也是后面为什么一定会需要 Service 的原因。
4. ReplicaSet 是什么
ReplicaSet 可以理解成 负责保证某类 Pod 始终维持指定副本数的一层控制器。
它解决的是：
- 现在只剩 2 个 Pod 了，但目标应该有 3 个
- 某个 Pod 挂了，要不要补一个新的
如果把它压缩成一句话：ReplicaSet 关注的是“数量要对”。
5. Deployment 又是什么
Deployment 可以理解成 站在更高一层，管理无状态应用发布和副本演进的控制器。
它并不是直接替代 Pod，而是：通过管理 ReplicaSet，再间接管理 Pod。
它解决的是：
- 应用应该跑几个副本
- 发布时如何滚动更新
- 出现问题时如何回滚
所以：
Pod解决“最小运行单元”问题ReplicaSet解决“副本数量”问题Deployment解决“版本演进和发布控制”问题
6. 控制器到底在控制什么
控制器 可以理解成 持续观察实际状态，并不断把系统拉回目标状态的那类组件。
这也是 Kubernetes 声明式管理的关键。
例如你声明：我要 3 个副本
如果当前只剩 2 个，控制器就会继续创建新的 Pod，直到恢复成 3 个。
所以它控制的不是“某一条命令”，而是：实际状态和目标状态之间的差距。
7. 一个最常见的 Deployment 示例
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-app
spec:
replicas: 3
selector:
matchLabels:
app: demo-app
template:
metadata:
labels:
app: demo-app
spec:
containers:
- name: app
image: demo-app:1.0
ports:
- containerPort: 8080这份配置可以这样理解：
- 定义一个名为
demo-app的 Deployment - 目标是始终保持 3 个副本
- 每个副本都运行
demo-app:1.0这个镜像 - Pod 上打了
app: demo-app这个标签
这里的 label 可以理解成 Kubernetes 用来给对象打标记、做选择和归组的一种键值对。
它后面会被 selector 用来选中一组 Pod。
8. StatefulSet 为什么经常和 Deployment 放在一起比较
虽然这篇重点是无状态控制器，但还是需要先点出边界。
StatefulSet 更适合：
- 稳定网络身份
- 稳定存储绑定
- 对实例顺序和身份更敏感的应用
它和 Deployment 的区别，不在于“谁更高级”，而在于：它们服务的是不同类型的工作负载。
9. 工程上最常见的几个误区
9.1 误区一：直接手工创建 Pod 就够了
手工 Pod 可以用于临时实验，但项目里更常见的生产方式还是通过控制器管理。
9.2 误区二：Deployment 直接管理 Pod
更具体一点，是 Deployment 管理 ReplicaSet，再由 ReplicaSet 管理 Pod。
9.3 误区三：Pod 就是永久实例
Pod 是可以被替换和重建的，不能把它当成稳定不变的机器。
10. 一句话总结
Kubernetes 的核心对象与控制器这条主线，本质上是在解决：
怎样把应用的运行形态、目标副本数和发布演进方式用一组可声明、可持续维护的对象模型表达出来。