Kubernetes组件及工作原理详解（kubernetes各组件协调工作）

Kubernetes 的组件可分为控制平面（Master）组件、节点（Node）组件和附加组件，协同工作以管理容器化应用。以下是详细分类和功能说明：

一、控制平面（Master）组件

控制平面负责集群的全局决策和状态管理，通常部署在 Master 节点上。

1. API Server（kube-apiserver）

O 作用：集群的入口，处理所有 REST 请求，验证并更新数据到 etcd。

O 特点：无状态，可水平扩展，通过负载均衡对外提供服务。

2. Scheduler（kube-scheduler）

O 作用：将 Pod 调度到合适的 Node，基于资源需求、亲和性策略等条件。

O 流程：监听未调度的 Pod，选择最佳节点（不负责实际启动 Pod）。

3. Controller Manager（kube-controller-manager）

O 作用：运行核心控制循环，确保集群状态与期望一致。

O 包含控制器：

Node Controller（监控节点状态）

Replication Controller（维护 Pod 副本数）

Deployment Controller（管理滚动更新）

Service Controller（处理负载均衡配置）等。

4.etcd

O 作用：分布式键值存储，保存集群配置和状态数据。

O 特点：高可用性需集群化部署，是 Kubernetes 的“唯一数据源”。

二、节点（Node）组件

每个工作节点（Worker）运行以下组件，负责容器生命周期和网络。

1. kubelet

O 作用：与 API Server 通信，管理节点上的 Pod 及容器。

O 功能：执行 PodSpec 描述的任务，监控容器健康状态，汇报节点资源。

2. kube-proxy

O 作用：维护节点网络规则（如 iptables/IPVS），实现 Service 的负载均衡和流量转发。

O 支持模式：userspace（旧）、iptables（默认）、IPVS（高性能）。

3. 容器运行时（Container Runtime）

O 作用：拉取镜像、启停容器（如 Docker、containerd、CRI-O）。

O 接口规范：遵循 CRI（Container Runtime Interface）。

三、附加组件（Add-ons）

非核心但常用，扩展集群功能。

1. CoreDNS

O 作用：集群内 DNS 服务器，解析 Service 和 Pod 的域名。

2. Ingress Controller

O 作用：管理外部访问（如 Nginx、Traefik），路由 HTTP(S) 流量到 Service。

3. CNI 网络插件

O 作用：实现 Pod 网络通信（如 Calico、Flannel、Cilium），分配 IP 地址。

4. Metrics Server

O 作用：收集资源使用指标，供 HPA（自动扩缩容）和 kubectl top 使用。

5. Dashboard

O 作用：提供 Web UI 管理集群（需额外部署）。

6. CSI（Container Storage Interface）

O 作用：标准化动态存储卷管理（如 AWS EBS、Google Persistent Disk）。

四、交互流程示例

1. 用户通过 kubectl 或 API 请求创建 Deployment。
2. API Server 验证请求并写入 etcd。
3. Controller Manager 检测到新对象，创建 ReplicaSet 确保 Pod 副本数。
4. Scheduler 为未调度的 Pod 选择节点，更新 etcd。
5. 目标节点的 kubelet 创建 Pod，容器运行时启动容器。
6. kube-proxy 配置网络规则，Service 流量被正确路由。

五、高可用（HA）设计

• etcd 集群：至少 3 节点，通过 Raft 协议保证数据一致性。
• 多 Master 节点：API Server 无状态可扩展，Scheduler 和 Controller Manager 通过 Leader 选举避免冲突。
• 负载均衡：前置负载均衡器（如 HAProxy）分发 API Server 流量。

Kubernetes 的模块化设计使其灵活且可扩展，各组件通过 API Server 协同，确保集群状态始终向期望状态收敛。理解组件职责是运维和故障排查的基础。