Kubernetes 架构 - 技术栈

整个架构可以分为三层：

包括以下关键组件：

组件	作用
API Server	所有组件交互的统一入口，负责接收来自 `kubectl`、`web UI` 或其他组件的请求。它是整个集群的"前门"。
etcd	分布式键值存储，用来保存所有集群状态数据（包括节点信息、Pod 定义、副本数、配置等）。API Server 会将集群的状态写入或读取 etcd。
Scheduler	负责调度 Pod ------ 即决定"哪个 Pod 运行在哪个 Node 上"。调度依据包括资源、亲和性、污点/容忍等策略。
Controller Manager（或 replication controller）	负责集群状态的"自愈"与"期望状态保持"。当实际状态与期望状态不符时，会创建或删除 Pod、Service 等资源以达到目标。

每个 Node（工作节点）都运行以下关键组件：

组件	作用
kubelet	负责与 API Server 通信，根据指令创建或销毁 Pod，监控容器状态，并上报节点资源使用情况。
kube-proxy	管理节点上的网络规则，确保服务间的负载均衡和网络访问。
Pod（容器组）	最小的调度单元，一个 Pod 内可包含一个或多个容器。

组件	说明
kubectl	命令行工具，用于与 API Server 通信，提交配置、查看状态。
Web UI (Dashboard)	图形化管理界面。
Internet / Firewall	指外部访问流量或安全层。

用户通过 kubectl 或 Web UI 提交一个 YAML 清单（例如定义了一个 Deployment，指定需要运行 3 个副本的 Nginx Pod）。

API Server 作为入口，验证请求合法性并将资源信息写入 etcd。

Controller Manager 监控 etcd 中的数据，发现"期望副本数为3，但实际为0"，于是会创建 3 个新的 Pod 对象。

Scheduler 负责为这些待创建的 Pod 选择合适的 Node（根据资源负载、亲和性、污点等规则）。

每个 Node 上的 kubelet 接收到调度结果后，通过容器运行时（如 containerd、Docker）真正创建出容器。

kube-proxy 更新 iptables/ipvs 规则，实现 Pod 与 Service 之间的通信和负载均衡。

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