K8S架构图怎么看？你真的理解了吗？

当我们面对一张复杂的Kubernetes（K8S）架构图时，很多人会产生这样的困惑：这些密密麻麻的组件究竟如何协同工作？为什么需要Etcd、API Server、Scheduler这么多模块？本文将通过11张解析图，带你穿透表象理解设计逻辑，同时破解3个最常见的认知误区。

一、K8S架构的核心组成

1.1 两大核心平面解析

Kubernetes架构由控制平面（Control Plane）和工作节点（Worker Node）构成，就像城市的交通指挥中心与道路网络的关系：

控制平面组件：

• ▶ API Server：集群的”中央枢纽”，处理所有REST请求
• ▶ Scheduler：智能调度专家，决定Pod的运行位置
• ▶ Controller Manager：集群状态监护系统
• ▶ Etcd：分布式键值数据库，存储集群所有配置数据

1.2 节点架构详解

每个Worker Node都是具体任务的执行单元，包含三个核心模块：

1. Kubelet：节点代理，负责与Master通信
2. Kube-proxy：网络流量调度器
3. 容器运行时：Docker/containerd等容器引擎

二、请求处理全流程解析

2.1 外部请求的生命周期

以用户访问Web应用为例，完整流程如下：

1. 用户请求通过Nginx Ingress进入集群
2. API Server接收创建Pod的指令
3. Scheduler选择最优节点（考虑资源、亲和性等）
4. 目标节点的Kubelet启动容器
5. Service通过iptables/ipvs实现负载均衡

2.2 数据存储核心机制

Etcd采用Raft算法保证数据一致性，但需要注意：

• 写操作需要获得多数节点确认
• 单节点故障不会导致数据丢失
• 数据变更通过Watch机制实时同步

三、三大常见认知误区

3.1 误区一：”Master节点越多越好”

实际情况：

• 生产环境建议3或5个Master节点
• 过多Master节点会降低etcd性能
• 使用反亲和性策略避免单点故障

3.2 误区二：”Service直接暴露容器端口”

关键要点：

• Service通过虚拟IP实现抽象层
• kube-proxy维护iptables/ipvs规则
• 外部访问需配合Ingress或NodePort

3.3 误区三：”Pod就是容器”

本质区别：

• Pod是K8S最小调度单元
• 一个Pod可包含多个容器
• 共享网络命名空间和存储卷

四、架构优化实战技巧

4.1 高可用部署方案

1. 多Master节点负载均衡
2. etcd集群独立部署
3. 工作节点自动伸缩组

4.2 监控体系构建

必备监控指标：

• API Server请求延迟
• etcd存储空间使用率
• 节点资源饱和度
• 网络插件健康状态

理解Kubernetes架构需要把握分层设计思想和声明式API哲学。通过将控制平面与数据平面分离，K8S实现了惊人的扩展能力。建议在掌握架构原理后，使用kubectl get –raw命令直接观察组件状态，或通过Prometheus收集运行时指标，在实践中深化认知。