Kubernetes 架构
一、Kubernetes 架构分层解析
整个架构可以分为三层：
1️⃣ 控制平面（Control Plane）
包括以下关键组件：
| 组件 | 作用 |
|---|---|
| API Server | 所有组件交互的统一入口，负责接收来自 kubectl、web UI 或其他组件的请求。它是整个集群的“前门”。 |
| etcd | 分布式键值存储，用来保存所有集群状态数据（包括节点信息、Pod 定义、副本数、配置等）。API Server 会将集群的状态写入或读取 etcd。 |
| Scheduler | 负责调度 Pod —— 即决定“哪个 Pod 运行在哪个 Node 上”。调度依据包括资源、亲和性、污点/容忍等策略。 |
| Controller Manager（或 replication controller） | 负责集群状态的“自愈”与“期望状态保持”。当实际状态与期望状态不符时，会创建或删除 Pod、Service 等资源以达到目标。 |
2️⃣ 节点层（Node Layer）
每个 Node（工作节点）都运行以下关键组件：
| 组件 | 作用 |
|---|---|
| kubelet | 负责与 API Server 通信，根据指令创建或销毁 Pod，监控容器状态，并上报节点资源使用情况。 |
| kube-proxy | 管理节点上的网络规则，确保服务间的负载均衡和网络访问。 |
| Pod（容器组） | 最小的调度单元，一个 Pod 内可包含一个或多个容器。 |
3️⃣ 用户访问层
| 组件 | 说明 |
|---|---|
| kubectl | 命令行工具，用于与 API Server 通信，提交配置、查看状态。 |
| Web UI (Dashboard) | 图形化管理界面。 |
| Internet / Firewall | 指外部访问流量或安全层。 |
✅ 二、Kubernetes 的工作流程（按图中箭头顺序）
1️⃣ 用户发出请求
用户通过 kubectl 或 Web UI 提交一个 YAML 清单（例如定义了一个 Deployment，指定需要运行 3 个副本的 Nginx Pod）。
2️⃣ API Server 接收请求
API Server 作为入口，验证请求合法性并将资源信息写入 etcd。
3️⃣ Controller Manager 监控状态
Controller Manager 监控 etcd 中的数据，发现“期望副本数为3，但实际为0”，于是会创建 3 个新的 Pod 对象。
4️⃣ Scheduler 负责调度
Scheduler 负责为这些待创建的 Pod 选择合适的 Node（根据资源负载、亲和性、污点等规则）。
5️⃣ Node 执行任务
每个 Node 上的 kubelet 接收到调度结果后，通过容器运行时（如 containerd、Docker）真正创建出容器。
6️⃣ kube-proxy 处理网络
kube-proxy 更新 iptables/ipvs 规则，实现 Pod 与 Service 之间的通信和负载均衡。
7️⃣ 状态反馈
各 Node 将 Pod 运行状态上报给 API Server，Controller Manager 持续监控并维持系统的期望状态。
⚠️ 三、你原理解中的小问题与补充建议
| 问题 / 不足 | 修正 / 补充说明 |
|---|---|
| 你提到 “scheduler 进行任务调用，将任务分给不同 node” | ✅ 基本正确，但 scheduler 并不直接“执行任务”，它只做“调度决策”，告诉 kubelet 哪个 Pod 该在哪个节点运行。实际创建容器的动作由 kubelet 执行。 |
| “api server 将请求写入 etcd” | ✅ 正确。需要补充：API Server 同时也负责认证、授权、数据校验和变更通知（watch机制）。 |
| “replication controller 用于维护副本数” | ✅ 对的，但更准确地说，现在推荐使用 ReplicaSet / Deployment 来管理副本。ReplicationController 已逐渐被替代。 |
| “scheduler、controller 等组件都在一个 node 中” | ❌ 不完全准确。控制平面（包含 scheduler/controller/api-server/etcd）通常运行在 Master 节点（现在称为 Control Plane Node），而不是普通 node 上。 |
| “改写 Pod 的数量” | ✅ 思路对，但 RC/ReplicaSet 实际上是通过修改 YAML 定义中的 replicas 字段，从而触发控制器调整 Pod 数量。 |
✅ 四、总结一句话流程
用户通过 kubectl → API Server 接收请求并写入 etcd → Controller 发现期望状态与实际状态不符 → Scheduler 选择节点 → kubelet 在节点上启动 Pod → kube-proxy 管理通信 → 系统持续自愈与同步状态。