Lesson 03：Kubernetes 全局架构 —— 六大组件与协作流程

学习目标

完成本课后，你将能够：

画出 Kubernetes 的控制面与数据面架构图
说出六大核心组件各自的职责
完整描述从 kubectl apply 到 Pod Running 的全链路流程
解释为什么所有组件只通过 API Server 通信

前置知识

Lesson 01-02：理解容器是什么、容器的底层原理

1. 为什么需要 Kubernetes？

上一课我们学会了容器。当你只有 5 个容器时，手动管理完全可行。但在生产环境中：

场景	挑战
流量突增	需要在秒级内从 10 个容器扩容到 500 个
服务器宕机	某节点突然断电，上面 50 个容器需要在其他节点自动重建
版本发布	新版本上线要做到零停机，逐步用新容器替换旧容器
服务发现	容器重建后 IP 地址会变，调用方如何找到新地址？
资源调度	哪台机器还有空闲资源来运行新容器？

Kubernetes（K8s）就是解决这些问题的容器编排系统。 它是一个自动化的"超级管家"，负责在集群中调度、管理、监控和修复容器。

2. Master-Worker 主从架构

Kubernetes 集群的节点分为两种角色：

┌──────────────────────────────────────────────┐
│              Control Plane (Master)           │
│                                              │
│   ┌──────────┐  ┌──────┐  ┌──────────────┐  │
│   │API Server│  │ etcd │  │Controller Mgr│  │
│   └──────────┘  └──────┘  └──────────────┘  │
│   ┌──────────┐                               │
│   │Scheduler │                               │
│   └──────────┘                               │
└──────────────────────────────────────────────┘
         │              │              │
    ┌────┴────┐    ┌────┴────┐    ┌────┴────┐
    │Worker-01│    │Worker-02│    │Worker-03│
    │┌───────┐│    │┌───────┐│    │┌───────┐│
    ││Kubelet││    ││Kubelet││    ││Kubelet││
    │├───────┤│    │├───────┤│    │├───────┤│
    ││K-proxy││    ││K-proxy││    ││K-proxy││
    │├───────┤│    │├───────┤│    │├───────┤│
    ││contd  ││    ││contd  ││    ││contd  ││
    │└───────┘│    │└───────┘│    │└───────┘│
    └─────────┘    └─────────┘    └─────────┘

Control Plane（控制面 / Master 节点）：负责决策和管理。不运行业务容器，只负责指挥调度。
Worker Node（数据面 / 工作节点）：负责实际运行业务容器，接受控制面的指令。

3. 控制面四大组件详解

3.1 API Server —— 集群的唯一入口

职责：所有的操作请求（不管是外部的 kubectl 命令、还是内部组件之间的通信）都必须经过 API Server。它是整个集群唯一的"咽喉要道"。

为什么这样设计：

安全审计：所有操作经过统一入口，可以做认证（你是谁）、授权（你有没有权限）、准入控制（你的操作是否合规）
解耦：组件之间不直接通信，任何组件故障都不会导致连锁崩溃

技术细节：

API Server 是一个 RESTful HTTP 服务，监听在 6443 端口（HTTPS）
所有资源操作都是标准的 HTTP 动词：GET（查询）、POST（创建）、PUT（更新）、DELETE（删除）
支持 Watch 机制：组件可以"订阅"资源变化，实时收到通知

3.2 etcd —— 集群的"数据库"

职责：存储集群的所有状态数据。节点信息、Pod 定义、Service 配置、Secret 密钥——一切都存在 etcd 里。

关键特性：

分布式 Key-Value 存储，支持高可用（生产环境通常部署 3 或 5 个 etcd 节点）
使用 Raft 共识算法保证数据一致性
支持 Watch 机制，数据变化时主动通知订阅者

为什么这么重要：etcd 是集群的"记忆"。即使整个集群断电重启，只要 etcd 的数据完好，K8s 就能照着 etcd 中记录的"期望状态"把所有服务恢复原样。

[!WARNING] etcd 是整个集群中最关键的组件。如果 etcd 数据丢失且没有备份，集群将无法恢复。生产环境必须定期备份 etcd。

3.3 Controller Manager —— 自动化控制循环

职责：持续监控集群的"实际状态"与"期望状态"是否一致，如果不一致就自动修复。

控制循环（Control Loop）的工作方式：

无限循环 {
    实际状态 = 从 API Server 获取当前情况
    期望状态 = 从 API Server 获取用户定义的期望
    if (实际状态 ≠ 期望状态) {
        执行操作使实际状态趋向期望状态
    }
}

举例：你定义了一个 Deployment 要求 3 个副本。如果某个 Pod 崩溃了，实际副本变成 2 个，Controller Manager（具体是 ReplicaSet Controller）会立刻发现差异，并通知 API Server 创建一个新 Pod 来补齐。

这就是 K8s 的核心哲学——声明式管理：你只需要告诉 K8s"我要什么"（期望状态），它会自动想办法达到和维持这个状态，而不需要你告诉它"怎么做"。

3.4 Scheduler —— 智能调度器

职责：当有新的 Pod 需要创建时，决定它应该运行在哪个 Worker 节点上。

调度决策过程：

过滤（Filtering）：排除不满足条件的节点（资源不足、有污点、不匹配亲和性规则等）
评分（Scoring）：对剩余的可用节点打分，选择最优的节点
绑定（Binding）：将 Pod 分配到得分最高的节点

评分考虑因素：

节点剩余资源（CPU、内存）
Pod 亲和性/反亲和性规则
数据局部性（Pod 使用的存储卷在哪个节点上）
负载均衡（尽量让各节点负载均匀）

4. 数据面两大组件详解

4.1 Kubelet —— 节点代理

职责：运行在每个 Worker 节点上，是控制面在基层的"代言人"。

核心工作：

持续向 API Server 注册并汇报节点状态（心跳机制，默认每 10 秒一次）
接收 API Server 的指令，调用容器运行时（Containerd）来创建、启动、停止容器
执行探针检查（Liveness / Readiness），判断容器是否健康
管理容器的日志和资源使用情况

关键理解：Kubelet 挂了≠容器挂了。Kubelet 宕机只意味着控制面失去了对该节点的管理能力（节点变为 NotReady），但已经运行的容器进程不受影响——因为容器的父进程是 containerd-shim，不是 Kubelet。

4.2 Kube-proxy —— 网络规则管理器

职责：在每个节点上维护网络规则，实现 Service（服务）的负载均衡和网络转发。

工作模式：

iptables 模式（默认）：通过修改 Linux 的 iptables 规则来实现流量转发
IPVS 模式（高性能）：使用 Linux 内核的 IPVS（IP Virtual Server）模块，性能更好，适合大规模集群

举例：当你创建一个 Service 指向 3 个 Pod 时，kube-proxy 会在每个节点上创建相应的 iptables/IPVS 规则，使得任何节点上的进程访问 Service IP 时，流量会被均匀分发到这 3 个 Pod。

5. 完整请求生命周期

从你在键盘敲下 kubectl apply -f nginx.yaml 开始，背后发生了什么：

Containerd (运行时)Kubelet (Worker节点)SchedulerController ManageretcdAPI Server运维工程师 (kubectl)Containerd (运行时)Kubelet (Worker节点)SchedulerController ManageretcdAPI Server运维工程师 (kubectl)提交 YAML："创建一个 3 副本的 Nginx Deployment"1认证、授权、准入控制检查2将 Deployment 对象写入 etcd3返回 "deployment.apps/nginx created"4[Watch] 发现新的 Deployment，创建对应的 ReplicaSet5[Watch] 发现 ReplicaSet 期望 3 副本但实际 0 个，创建 3 个 Pod 对象6[Watch] 发现 3 个未调度的 Pod7对所有节点评分：Worker-01(85分) Worker-02(92分)8将 Pod-1 绑定到 Worker-01，Pod-2/3 绑定到 Worker-029[Watch] Worker-01 的 Kubelet 发现有新 Pod 分配给自己10调用 Containerd 拉取 Nginx 镜像并启动容器11汇报 Pod-1 状态：Running12[Watch] Worker-02 的 Kubelet 处理 Pod-2 和 Pod-313启动两个 Nginx 容器14汇报 Pod-2/3 状态：Running15

[!NOTE] 整个流程中，所有组件都只和 API Server 通信，组件之间互不直接联系。这种 Hub-and-Spoke（轮辐式） 架构保证了高度解耦：任何一个组件故障，其他组件不受影响。

动手实验

实验 3.1：验证控制面组件状态

在 Master 节点上执行：

bash# 查看所有控制面组件的 Pod 状态
kubectl get pods -n kube-system

# 查看各组件的详细信息
kubectl get componentstatuses 2>/dev/null || echo "注：此命令在新版本中已弃用，使用下面的方式"

# 验证 API Server 是否正常（直接调用 API）
kubectl get --raw /healthz

# 验证 etcd 健康状态
kubectl get --raw /livez/etcd

# 查看 Scheduler 和 Controller Manager 的领导者选举信息
kubectl get endpoints -n kube-system kube-scheduler -o yaml

实验 3.2：观察控制循环的自愈能力

bash# 创建一个 3 副本的 Nginx 部署
kubectl create deployment nginx-test --image=registry.aliyuncs.com/google_containers/nginx:1.25 --replicas=3

# 等待所有 Pod 变为 Running
kubectl get pods -l app=nginx-test -w

# 手动删除一个 Pod，模拟容器崩溃
kubectl delete pod $(kubectl get pods -l app=nginx-test -o jsonpath='{.items[0].metadata.name}')

# 立即观察：Controller Manager 会自动创建新 Pod 补齐到 3 个
kubectl get pods -l app=nginx-test

# 清理
kubectl delete deployment nginx-test

观察要点：删除一个 Pod 后，几秒钟内就会有一个新的 Pod 被自动创建。这就是 Controller Manager 的控制循环在工作。