你有没有想过，为什么像抖音、美团这样的大厂，能同时支撑上亿人在线点餐、刷视频？背后少不了 ref="/tag/2020/" style="color:#E3A3CF;font-weight:bold;">Kubernetes 的身影。它就像一个智能调度员，把成千上万个应用“装”进容器里，再合理分配到服务器上运行。今天我们就用一张图，拆解 Kubernetes 的核心架构。
控制平面：集群的大脑
Kubernetes 集群最核心的部分叫控制平面（Control Plane），通常运行在主节点（Master Node）上。它不跑业务应用，专管整个集群的“交通指挥”。
其中最关键的组件是 kube-apiserver，它是所有操作的入口。你执行 kubectl 命令，实际上就是发请求给 apiserver。比如你想部署一个新服务：
kubectl apply -f deployment.yaml这条命令一敲，apiserver 就开始干活了。它会把请求存入 etcd —— 一个高可用的键值数据库，相当于集群的“记忆中枢”，保存着所有配置和状态信息。
接着，Controller Manager 开始监听变化。比如你定义了要运行 3 个副本的应用，它就时刻盯着实际数量，少了一个就自动补上。而 Scheduler 负责决定新 Pod 应该放在哪个工作节点上，考虑资源、亲和性等各种策略。
工作节点：干活的机器
真正运行业务代码的是工作节点（Worker Node）。每个节点上都有几个关键角色。
首先是 kubelet，它是节点上的“监工”，接收 apiserver 的指令，确保容器按预期运行。比如你定义了一个 Nginx 容器，kubelet 就会调用 Docker 或 containerd 把它拉起来。
另一个重要组件是 kube-proxy，负责网络代理。它维护节点上的网络规则，让 Pod 之间可以互相访问，也能对外提供服务。你可以把它想象成小区里的快递中转站，谁家买东西都得从这儿过。
还有个容易被忽略但至关重要的部分：容器运行时。虽然 Kubernetes 本身不管具体怎么跑容器，但它依赖底层运行时，比如 Docker、containerd 或 CRI-O。没有它们，Pod 就只是纸面计划。
举个生活中的例子
假设你在开连锁奶茶店。控制平面就像是总部，负责设计菜单、监控库存、安排人员调度。而每家门店就是工作节点，店长（kubelet）按照总部指令制作饮品，收银员（kube-proxy）处理顾客订单和出餐。etcd 就是总部的中央数据库，记录所有门店的营业数据。一旦某家店员工请假，控制器发现人手不够，立刻通知招聘补人。
Pod：最小部署单元
Kubernetes 不直接调度容器，而是把一个或多个容器打包成 Pod。这就像快递包裹，多个相关物品放在一起运输更高效。比如你的应用需要一个主容器和一个日志收集边车（sidecar），它们必须在同一 Pod 里，共享网络和存储。
当你部署应用时，通常写一个 YAML 文件：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest这个文件提交后，apiserver 接收，etcd 存储，scheduler 分配节点，kubelet 拉起容器。一套流程下来，三个 Nginx 实例就跑起来了。
网络模型：扁平化通信
Kubernetes 设计了一个扁平的网络模型：每个 Pod 都有独立 IP，所有 Pod 可以跨节点直接通信。实现靠的是 CNI 插件，比如 Calico、Flannel。它们在底层建立虚拟网络，屏蔽复杂的路由细节。
这种设计让微服务调用变得简单。订单服务想查用户信息，直接 http://user-service-pod-ip:8080 请求就行，不用关心对方在哪台物理机上。