Kubernetes 架构的主要组件有哪些？每个组件负责什么？

Kubernetes 集群由一个 控制平面 以及一组称为 节点 的工作机器组成，这些节点在 Pod 中运行容器化应用。每个集群至少需要一个工作节点来运行 Pod。

从概念上说，Kubernetes 是 声明式 的：你将期望状态提交给 API server（存储在 etcd 中），然后控制器运行持续的协调循环，观察差异并采取行动，使实际状态向期望状态靠拢。

控制平面组件

控制平面负责对集群做出全局决策（例如调度），并响应集群事件。在生产环境中，它通常跨多台机器运行以实现高可用。

• kube-apiserver — 暴露 Kubernetes HTTP API 的核心组件。它是控制平面的 前端 和唯一入口：所有认证、授权、请求校验以及集群状态的读写都通过它进行。它支持水平扩展。在正常部署中，它是唯一直接读写 etcd 中集群状态的 Kubernetes 组件；其他所有组件都通过 API server 与状态交互。
• etcd — 一个一致且高可用的键值存储，用作 Kubernetes 存放所有集群数据的后端：配置、状态和元数据。etcd 是必需的，也是唯一事实来源——失去它就意味着失去全部集群状态，因此它必须以法定人数（奇数个成员）运行，并定期备份。
• kube-scheduler — 监视尚未绑定到节点的 Pod，并根据资源、约束和策略，将每个 Pod 分配到合适的节点。
• kube-controller-manager — 运行实现 Kubernetes API 行为的控制器（例如 Node controller、Job controller、EndpointSlice controller）。每个控制器都会观察期望状态，并将实际状态协调到该状态。
• cloud-controller-manager（可选）— 与底层云提供商集成，将云相关逻辑与核心 Kubernetes 组件隔离开来。

节点组件

这些组件运行在每个节点上，负责让 Pod 持续运行并提供运行环境。

• kubelet — 确保 Pod 正在运行的代理，包括其中的容器。它从 API server 监听 Pod 分配，借助运行时启动容器，挂载卷，执行存活/就绪探针，并报告节点状态。
• kube-proxy — 通过在节点上编程 iptables 或 IPVS 规则来实现 Service 网络，使发往某个 Service 的流量转发到正确的 Pod IP。之所以标记为可选，是因为某些 CNI 插件（例如 eBPF 模式下的 Cilium）会接管它的工作，但在标准集群中它是必需的。
• Container runtime — 负责运行容器的软件（例如 containerd、CRI-O 等，通过 CRI 接口）。

附加组件

附加组件扩展集群功能：集群 DNS（默认使用 CoreDNS）、Dashboard Web UI、容器资源监控以及集群级日志记录。

常见后续问题： 所有通信都通过 API server 进行——调度器、控制器和 kubelet 只是监听它并作出响应——这使 API server 成为集群的关键枢纽。