Kubernetes 完全指南：从集群架构到应用模型

Kubernetes 完全指南：从集群架构到应用模型

一、Kubernetes 集群架构

一个 Kubernetes 集群由**控制平面（Control Plane）和工作节点（Worker Nodes）**构成。控制平面负责全局决策与状态管理，工作节点负责运行实际的容器化应用。

架构速览：你可以想象一个典型的集群包含至少一个控制平面节点（通常为 3 个以实现高可用）和多个工作节点。控制平面节点上运行着 API Server、etcd、Scheduler、Controller Manager 等组件；工作节点上运行着 kubelet、kube-proxy 和容器运行时。所有组件通过 API Server 进行通信，形成一个有机整体。

1.1 控制平面组件

控制平面组件对集群做出全局决策，并存储所有状态数据。它们通常部署在专用节点上以保证稳定性。

API Server（kube-apiserver）

API Server 是整个集群的'交通枢纽'，它暴露了 Kubernetes API，供用户、命令行工具（如 kubectl）以及内部组件通信。所有对集群的操作请求都经过 API Server，它会执行认证（Authentication）、**授权（Authorization）和准入控制（Admission Control）**三层安全校验，然后将资源状态持久化到后端存储中。API Server 是唯一直接与 etcd 交互的组件。

etcd

etcd 是一个高可用、强一致性的分布式键值存储，作为 Kubernetes 的后端数据库。它保存了所有集群数据，包括 Pod、Service、Deployment 等资源的定义和当前状态。etcd 通常以奇数个节点集群部署，并基于 Raft 共识算法确保数据一致性（例如，3 节点集群可容忍 1 节点故障）。etcd 被视为集群的'真相来源'，定期备份 etcd 数据是灾难恢复的关键。

Scheduler（kube-scheduler）

Scheduler 负责监视新创建的、尚未分配到节点的 Pod，并根据一系列策略（如资源需求、节点亲和性、污点容忍等）选择一个最合适的节点运行该 Pod。调度决策会考虑单个 Pod 和集群整体的资源状况、硬件/软件约束以及高可用要求。常见的调度策略包括：nodeSelector（节点标签选择）、节点亲和性/反亲和性、Pod 亲和性/反亲和性，以及自定义调度器扩展。

Controller Manager（kube-controller-manager）

Controller Manager 运行着多个控制器进程，每个控制器通过 API Server 监视集群状态，并努力将当前状态调整为期望状态。这些控制器并发运行，各自负责不同的资源类型。常见的内置控制器包括：

• 节点控制器：监控节点健康，处理节点宕机时的 Pod 驱逐。
• 副本控制器：确保指定数量的 Pod 副本正在运行（Deployment 等高级资源依赖此逻辑）。
• 端点控制器：维护 Service 与 Pod 之间的端点（Endpoints）对象。
• Service 账户与令牌控制器：管理命名空间中的默认账户和 API 访问令牌。
• 其他控制器（如 Namespace、Job、CronJob 等）。 所有控制器被编译成单个二进制文件并作为单个进程运行，以降低复杂性。

Cloud Controller Manager（cloud-controller-manager）

这是一个可选组件，用于将 Kubernetes 与特定云服务商（如 AWS、GCP、Azure）的 API 集成。它运行云平台相关的控制器，例如：

• 节点控制器：检查云平台以确定节点是否已被删除。
• 路由控制器：在云基础设施中设置网络路由。
• 服务控制器：创建、更新和删除云负载均衡器（当 Service 类型为 LoadBalancer 时）。 引入 Cloud Controller Manager 使得核心 Kubernetes 代码与云平台逻辑解耦，便于云原生扩展。在自建机房（on-premise）环境中，通常不需要此组件。