Kubernetes 架构与组件
Kubernetes 采用"控制面 + 工作节点"的主从架构：控制面是集群的大脑，负责决策与状态存储；工作节点是手脚，真正运行你的容器。看懂这套分工，故障时才知道该去检查哪个组件。
总体架构图
┌──────────────────── 控制面 Control Plane ────────────────────┐
│ kube-apiserver ◄─ 所有读写都经过的唯一 API 入口 │
│ kube-scheduler kube-controller-manager │
│ └────────────── etcd（状态存储） ──────────────────┘ │
└───────────────────────────┬──────────────────────────────────┘
│ 调度与指令下发
┌───────────────────────────▼──────────────────────────────────┐
│ 工作节点 node-1 工作节点 node-2 │
│ kubelet + kube-proxy + 容器运行时 （同样的三件套） │
└──────────────────────────────────────────────────────────────┘
控制面组件
| 组件 | 职责 | 备注 |
|---|---|---|
| kube-apiserver | 集群唯一 API 入口，负责认证、授权与校验 | 所有组件都只与它通信 |
| etcd | 分布式键值库，保存全部集群状态 | 只接受 apiserver 的读写 |
| kube-scheduler | 为新 Pod 挑选最合适的节点 | 综合资源、亲和性、污点 |
| kube-controller-manager | 运行各类控制器，维持期望状态 | 如节点控制器、副本控制器 |
kube-apiserver 是"中心枢纽"：kubectl、各控制器、kubelet 都通过它读写数据，etcd 不接受旁路访问，从机制上避免状态被绕过或写乱。
数据面组件
- kubelet：每个节点上的"管家"，负责本节点 Pod 的创建、监控与销毁，并向 apiserver 上报节点和容器状态。
- kube-proxy：维护节点上的网络规则（默认基于 iptables 或 ipvs），把发往 Service 虚拟 IP 的流量转发给后端 Pod。
- 容器运行时：真正创建与运行容器的程序，常见的是 containerd、CRI-O。kubelet 通过 CRI（容器运行时接口，Container Runtime Interface）与运行时交互，所以 Kubernetes 并不直接绑定 Docker。
一次部署请求的流转
从敲下命令到容器跑起来，一次请求这样流转：
- 你执行 kubectl apply，请求发往 kube-apiserver。
- apiserver 完成认证与校验，把"期望状态"写入 etcd。
- kube-scheduler 发现未调度的 Pod，结合资源用量选出目标节点，写回绑定关系。
- 目标节点上的 kubelet 发现 Pod 被调度到自己，通过 CRI 通知容器运行时拉镜像、启动容器。
- kubelet 把运行状态回报给 apiserver，你通过 kubectl 能看到 Pod 进入 Running。
以 Deployment 为例，控制回路这样闭环：ReplicaSet 控制器发现实际副本数少于期望值，就持续创建 Pod，直到数量一致：
kubectl apply -f app.yaml # 步骤 1：提交期望状态
kubectl get pods -w # 步骤 5：观察 Pod 逐个进入 Running
# NAME READY STATUS RESTARTS AGE
# app-7d9c5d6b9f-abc12 1/1 Running 0 30s
小结：控制面负责"决策与记账"（apiserver、etcd、scheduler、controller-manager），数据面负责"干活"（kubelet、kube-proxy、容器运行时）。一切状态变化都经 apiserver 落库，再由各组件协同完成。