一、Kubernetes 架构总览¶
Kubernetes 集群可以概括为两大部分：
- 控制面：负责接收请求、保存状态、调度资源和持续控制。
- 工作节点：负责真正运行 Pod，并承担网络、运行时和节点级管理职责。
二、控制面的核心组件¶
控制面是整个集群的“大脑”，主要由以下组件构成。
1. API Server¶
API Server 是 Kubernetes 的统一入口。无论是 kubectl、控制器还是其他客户端，最终都要通过它来读写资源对象。
它既负责认证、鉴权、准入控制，也负责把最终资源状态持久化到 etcd 中。可以把它理解为整个集群的控制中枢。
2. Scheduler¶
Scheduler 负责给尚未绑定节点的 Pod 选择合适的运行位置。
它会基于资源、约束、亲和性、污点容忍等条件进行过滤和打分，最终把 Pod 调度到最适合的节点上。
3. Controller Manager¶
Controller Manager 的职责是持续比对“期望状态”和“当前状态”，并不断做出修正。
例如 Deployment 控制器会维护副本数，ReplicaSet 控制器会补齐 Pod，节点控制器会处理节点状态变化。Kubernetes 的“声明式收敛”能力，核心就来自这里。
4. Etcd¶
Etcd 是 Kubernetes 的后端数据存储，保存着集群关键状态。它通常建议采用奇数节点部署，并使用可靠的高速磁盘，以保证一致性和恢复能力。
三、工作节点上的核心组件¶
工作节点负责真正把 Pod 跑起来。
1. kubelet¶
kubelet 是节点上的核心代理。它监听分配到本节点的 Pod，调用容器运行时拉取镜像、创建容器，并持续上报节点和 Pod 状态。
2. kube-proxy¶
kube-proxy 负责维护 Service 相关的转发规则，常见实现是 iptables 或 IPVS。它让集群内外的访问请求能够被正确转发到后端 Pod。
3. Container Runtime¶
容器运行时负责管理容器生命周期，常见实现包括 Containerd。它通过 CRI 与 kubelet 对接，是 Kubernetes 真正落地到容器执行层的关键组件。
4. CoreDNS、CNI 和监控扩展¶
在典型集群里，还会配合 CoreDNS 做服务解析，配合 Calico 等 CNI 插件完成 Pod 网络分配与网络策略控制，配合 Metrics Server 提供自动扩缩需要的指标数据。
四、几个非常关键的组件细节¶
真正进入生产环境后，有几个细节非常值得记住：
- API Server 是唯一直接和 etcd 通信的核心入口组件。
- Scheduler 和 Controller Manager 都支持高可用和选主机制。
- kube-proxy 并不是绝对必需，某些基于 eBPF 的网络方案可以替代它的部分能力。
- etcd 的可靠性直接决定控制面的稳定性。
- 只要有
kubeconfig和kubectl，就可以在合适权限范围内管理集群。
五、一次 Pod 创建请求是怎样流转的¶
把一次典型部署过程串起来，Kubernetes 的工作机制会更直观。
- 用户执行
kubectl，把 YAML 提交给 API Server。 - API Server 完成认证、鉴权和准入控制后，把资源对象写入 etcd。
- 相关控制器通过 Watch 机制感知资源变化，创建 ReplicaSet、Pod 等对象。
- Scheduler 发现待调度 Pod 后，为它挑选目标节点。
- 目标节点上的 kubelet 监听到分配给自己的 Pod，随后调用容器运行时拉取镜像并启动容器。
- 存储插件和 CNI 插件分别负责卷挂载与网络配置。
- Service Controller 和 Ingress Controller 再继续把访问流量接入到后端服务。
这条链路体现出 Kubernetes 最核心的设计思想：用户只声明目标状态，平台负责持续把目标状态变成现实状态。