Kubernetes 不只是容器编排，它代表了一种“状态驱动”运维模式：你描述期望状态，系统自动发现偏差并修复。
🧩 背景：容器难题与 Kubernetes 的诞生
容器解决了打包和隔离的问题，却留下了新的挑战：
- 容器挂掉后谁负责重启？
- 如何统一管理成百上千个服务？
- 配置、存储、权限如何集中控制？
Kubernetes 的出现，正是为了解决这些复杂性，让系统像“自愈生物”一样运行。
🧠 一、核心思想：声明式 + 控制循环
Kubernetes 的运作基于两个关键概念：
- 声明式配置：你只需写下想要的状态（YAML）
- 控制循环：系统不断对比当前状态与期望状态，并做出修正
# 示意：我想要三个副本
replicas: 3
并非“请一次性创建 3 个 Pod”，而是“系统始终保持 3 个运行实例”。
📦 二、资源对象：系统的建模单元
在 Kubernetes 中，一切都是资源：
| 类型 | 说明 |
|---|---|
| Pod | 最小运行单位 |
| Deployment | 副本管理与滚动升级 |
| Service | 负载均衡与服务发现 |
| ConfigMap | 非敏感配置管理 |
| Secret | 密钥和敏感数据存储 |
| PersistentVolume + Claim | 持久化存储 |
每个资源均包含：
metadata: # 资源标识、标签
spec: # 期望状态
status: # 实际状态（只读）
系统的所有动作均由这些对象的 spec 驱动。
🏷 三、标签与注解：不只是标记，而是系统语言
- Label：参与控制器、Service、策略选择，类似“路由标签”
- Annotation：附加额外信息，仅供人或工具参考，不影响调度
metadata:
labels:
app: frontend
annotations:
build: "2025-06-18"
误区：以为 label 只为检索——实际上，这是系统内部定位资源的关键机制。
🔄 四、生命周期：删除也有学问
Kubernetes 并非简单地 delete 就完事：
- Finalizer：在删除前挂钩，让控制器做额外清理（如卸载存储）
- OwnerReference：父子资源关联，父对象删除时级联清理子资源
示例：删除 Deployment 会自动清理关联的 ReplicaSet 和 Pod。
⚙️ 五、控制平面 & 工作节点：团队协作分工
| 部分 | 组件 | 职责 |
|---|---|---|
| 控制平面 | kube-apiserver, etcd, scheduler, controller-manager | 接收配置、调度决策并下发任务、存储集群状态 |
| 工作节点 | kubelet, kube-proxy, container runtime | 运行 Pod、实现网络、连接容器运行时 |
理解数据流：API Server → 控制器 → kubelet → 容器。
🔌 六、API & 扩展：CRD 与 Operator
- 所有资源皆 API 对象，支持 CRUD、Watch ；
- CRD（自定义资源）让你定义新类型；
- Operator 通过控制器模式将业务逻辑纳入集群自愈体系。
可以自己实现 Database 资源，并让 Operator 自动在云上创建数据库实例。
🔒 七、命名空间与隔离：租户 vs 环境
- Namespace：逻辑隔离，便于多团队/多环境管理；
- 默认不隔离网络，需配合 NetworkPolicy；
- 应从 Day-1 规划命名空间策略和资源配额。
📋 八、误区与建议：从实践中学习
| 误区 | 建议 |
|---|---|
| 只关注 YAML 写对即可 | 同步关注 status 与事件，观察控制器行为 |
| 随意命名 Label | 按官方 Common Labels 规范，便于工具集成 |
| 使用 default Namespace | 按团队/环境划分 Namespace，防止资源冲突 |
| 误以为 Namespace 自动隔离网络 | 必配 NetworkPolicy 才能真正实现网络层隔离 |
✅ 总结：从手动到自愈，Kubernetes 的价值在于
- 状态驱动：写意图，不写过程；
- 抽象化建模：用资源对象描述系统；
- 自愈闭环：系统自动对比并修正偏差；
- 扩展性：CRD + Operator 构筑业务自愈平台。
Kubernetes 是一种“系统治理语言”，学会它，就是学会让基础设施自己运维。
