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 管理通信 → 系统持续自愈与同步状态。