Kubernetes 架构解析
1. 整体架构：管理层 + 执行层
管理层（Master 节点）——"老板团队"
- API 服务器（kube-apiserver）
▶️ 公司的"前台"，所有指令必须通过这里传达（如部署应用、查看状态） - 调度器（kube-scheduler）
▶️ 像"项目经理"，决定把任务（Pod）分配给哪个"员工"（Node 节点）最合理 - 控制器（kube-controller-manager）
▶️ 类似"监督员"，确保实际工作状态符合预期（如节点故障时自动重启任务） - 数据库（etcd）
▶️ 公司的"档案柜"，存储集群所有关键信息（节点状态、Pod 配置等）
执行层（Node 节点）——"一线员工"
- 监工（kubelet）
▶️ 每个员工的"直属领导"，确保老板下发的任务（Pod）按时完成 - 接线员（kube-proxy）
▶️ 处理网络通信，实现负载均衡（如将用户请求分发给不同 Pod） - 工人（容器运行时）
▶️ 真正干活的执行者（如 Docker），负责运行具体容器
2. 核心组件的作用
Pod
- 最小工作单元：包含 1 个或多个容器（如 Web 服务 + 日志助手），共享网络/存储
- 特点：
- 临时性（任务完成即销毁）
- 可替换（自动故障转移）
Deployment
- 自动化流水线：
▶️ 管理应用版本更新（滚动升级）
▶️ 保障副本数量（如始终保持 3 个实例在线）
Service
- 统一接入层：
▶️ 对外提供固定 IP/DNS（如客服热线）
▶️ 自动负载均衡到后端 Pod
Namespace
- 部门隔离机制：
▶️ 划分资源边界（如开发/测试环境隔离）
▶️ 支持细粒度权限控制（RBAC）
3. 实际运行案例：部署网站
-
需求下达
用户向"前台"（API Server）提交："需要运行 3 个网站实例" -
任务分配
- "项目经理"（Scheduler）选择 3 个空闲 Node
- "监工"（kubelet）在 Node 上启动容器
-
网络配置
- "接线员"（kube-proxy）创建 Service，分配集群 IP
- 用户通过 Service IP 访问网站
-
故障恢复
某 Node 宕机 → "监督员"（Controller）自动在其他 Node 重建 Pod
总结：Kubernetes 核心优势
| 特性 | 说明 |
|---|---|
| 自动化运维 | 自动处理故障恢复、滚动更新、弹性扩缩容 |
| 资源高效利用 | 动态调度 Pod 到最优节点，避免资源浪费 |
| 跨平台一致性 | 从单机到千节点集群，管理接口完全统一 |
| 声明式配置 | 只需描述"想要什么状态"，无需关心"如何实现" |
通过这种分工协作，Kubernetes 让大规模应用管理变得像点外卖一样简单：你只管"要什么"，系统自动解决"怎么做" 🔧
