描述 Kubernetes 架构：control plane 与 worker node 及其组件。

Question

IT Interview Practice · Accepted Answer

一个 Kubernetes 集群有两类机器：**control plane**（做决策并存储状态的“大脑”）和 **worker node**（你的 Pod 实际运行的地方）。每一类都有一小组定义良好的组件。

## 全局图景

```text
┌──────────────── CONTROL PLANE（大脑）────────────────┐
│                                                            │
│   kube-apiserver ── 前门；所有通信都经过它                 │
│        │                                                   │
│   etcd ───────── 键值存储：集群的唯一真相来源              │
│                  (所有对象与期望状态)                      │
│   kube-scheduler ── 决定新 Pod 运行在哪个 node 上          │
│   controller-manager ── 运行控制循环 (reconciler)          │
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (你的应用)  │ │  └ Pods (你的应用)  │
└─────────────────────┘ └─────────────────────┘
```

## Control plane 组件

```text
kube-apiserver        唯一入口。暴露 REST API；校验并把对象
                      持久化到 etcd。kubectl、controller 和 kubelet
                      都只与 apiserver 通信。
etcd                  分布式、一致的键值存储。保存整个集群状态
                      (期望 + 当前)。丢了 etcd = 丢了集群。
kube-scheduler        监视尚未分配 node 的 Pod，并挑选最佳 node
                      (依据 resource request、affinity、taint 等)。
kube-controller-      运行各控制循环：node controller、replication (ReplicaSet)、
manager               deployment、job、endpoints 等。每个循环把实际 → 期望。
cloud-controller-     (在云上) 与云厂商集成：load balancer、路由、
manager               node 生命周期。
```

## Worker node 组件

```text
kubelet          node 上的 agent。与 apiserver 通信，通过 runtime 启停容器，
                 并上报 Pod 与 node 状态。它让 node 的现实与分配给它的
                 Pod 相匹配。
kube-proxy       编排 node 的网络 (iptables/IPVS)，使 Service 虚拟
                 IP 被负载均衡到正确的 Pod endpoint。
container runtime 真正运行容器的软件 (containerd, CRI-O)。
```

## 一次 “kubectl apply” 如何在系统中流转

```text
1. kubectl → kube-apiserver：“我想要一个含 3 个副本的 Deployment”
2. apiserver 校验并把对象写入 etcd
3. controller-manager (deployment→replicaset controller) 看到后，创建 3 个 Pod 对象
4. scheduler 看到 3 个未分配的 Pod，把每个分配到某个 node（经 apiserver 写回）
5. 每个 node 的 kubelet 看到属于自己的 Pod，让 runtime 拉取镜像并启动容器
6. kube-proxy 接好 Service 网络，使流量到达新 Pod
一切都是由 apiserver 中介的 WATCH + RECONCILE 循环。
```

```bash
kubectl get nodes                 # 列出 node (control-plane + worker)
kubectl get pods -n kube-system   # 查看 control-plane / 系统组件
kubectl get componentstatuses     # 核心 control-plane 组件的健康状况
```

## 为什么这很重要

理解 control plane 与 worker node 之间的划分——以及每个组件的角色——正是把 Kubernetes 从一个黑盒变成一个你能推理和运维的系统的关键，因此它是任何中级及以上工程师的核心知识。**control plane** 是负责决策的大脑：**kube-apiserver** 是每个组件和用户与之通信的唯一前门；**etcd** 是保存整个集群状态、作为唯一真相来源的一致键值存储（丢了它就意味着丢了集群）；**scheduler** 决定每个新 Pod 落到哪个 node 上；而 **controller-manager** 运行不断把实际状态推向期望状态的调和循环。在每个 **worker node** 上，**kubelet** 是让 node 的容器与分配给它的 Pod 相匹配的 agent，**kube-proxy** 编排使 Service 虚拟 IP 路由到正确 Pod 的网络，而 **container runtime**（containerd, CRI-O）真正运行容器。看清一次 `kubectl apply` 如何在这个系统中流转——从 apiserver 到 etcd，controller 创建对象，scheduler 放置 Pod，kubelet 启动容器，kube-proxy 接好网络，全都作为监视与调和循环——就揭示了该平台背后优雅而一致的设计。这套心智模型正是你调试为何某个 Pod 卡在 Pending（scheduler）、为何集群无响应（apiserver/etcd）或为何某个 Service 不路由（kube-proxy）时所需要的，使其对运维和排查真实集群不可或缺。

全局图景

Control plane 组件

Worker node 组件

一次 “kubectl apply” 如何在系统中流转

为什么这很重要

相关问题