一、控制平面（Control Plane）组件深度剖析：集群的 “决策与指挥中枢”

控制平面作为K8S集群的核心指挥层，通过各组件的协同，实现集群状态的精准管控、资源的智能调度与全局决策的统一执行，每个组件均承担不可替代的核心职责：

1. API Server：集群的 “唯一入口与通信网关”

核心定位：K8S集群的“前端门户”，所有操作（如创建Pod、查询节点状态）均需要通过API Server发起，是控制平面与外部（如kubectl）、控制平面内部组件（如Scheduler、Controller Manager）、工作节点（如kubelet）的唯一通信桥梁。

核心能力：

协议处理：仅支持RESTful API （HTTP/HTTPS）,接收并验证请求的合法性（如权限校验、资源格式校验），拒绝非法或格式错误的操作。

请求转发与协调：将合法的请求分发至对应组件（如创建Pod的请求转发给Controller Manager生成Pod配置，调度强求传递给Scheduler），同时同步更新etcd中的集群状态。

状态缓存：为减少etcd访问压力，API Server会缓存集群常用状态数据（如Pod列表、节点信息），提升请求相应速度。

关键特性：无状态设计，支持多实例部署实现高可用及支持水平扩展，确保集群指挥层不单点故障；唯一直接与etcd交互的组件；以Pod形式运行，运行在控制平面节点，常见管理控制器Deployment/StatefulSet。

注：什么是有状态设计？什么是无状态设计？怎么实现高可用？什么是系统服务形式和Pod形式运行？

1. 有状态设计：服务端会保存与客户端交互的历史状态（如用户购物车、游戏角色状态），后续请求处理依赖这些已存信息，扩展时需考虑状态同步，适合需连续上下文的场景（如在线游戏、实时聊天）。

2. 无状态设计：服务端不保存请求上下文，每个请求都包含处理所需的全部信息（如通过 JWT 携带用户信息），实例间无关联可轻松水平扩展，适合高弹性、高扩展需求的场景（如 RESTful API、静态资源服务）。

3. kube-apiserver 高可用的核心是依托其无状态特性（状态存于 etcd），通过 “多实例冗余 + 负载均衡” 消除单点故障：部署至少 3 个 kube-apiserver 实例并分散在不同节点，前端用负载均衡器（如云 LB、HAProxy、Nginx）作为统一入口，将集群内（如 kubelet、scheduler 通过默认 kubernetes Service 访问）和集群外请求分发到健康实例；同时需配合 etcd 集群高可用（奇数节点部署）、统一 CA 签发的证书、节点时间同步，再通过健康检查自动隔离故障实例并重启，确保 API 服务持续可用。

4. 系统服务（System Service）需在 K8s 自身调度功能（如 kube-scheduler）生效前启动，否则集群无法初始化。通常通过systemd（Linux 主流）、upstart等系统守护进程管理，运行在控制平面节点（Master Node） 和工作节点（Worker Node） 。

5. 以Pod 形式运行的组件依赖 K8s 的调度、自愈（如重启故障实例）、扩缩容能力，通常运行在控制平面节点，且大多被部署在kube-system命名空间下（K8s 系统命名空间），由Deployment、StatefulSet等控制器管理。

2. etcd：集群的 “分布式数据账本”

核心定位：基于Raft协议的分布式键值数据库，是K8S集群的“唯一数据源”，所有集群状态（节点信息、Pod配置、Service规则、密钥）均以键值对形式持久化存储在此，无任何其他组件直接存储集群核心数据。

注：Raft协议是一种用于分布式系统的强一致性共识算法，核心是通过 “领导者（Leader）- 追随者（Follower）- 候选者（Candidate）” 三种角色的轮转，确保集群中所有节点对数据变更达成一致 —— 正常情况下由 Leader 接收并同步数据到所有 Follower，若 Leader 故障，Follower 会通过选举机制产生新 Leader，同时通过日志复制和多数派投票规则，保证即使部分节点故障，集群仍能可靠运行，且避免数据不一致，常见于 etcd、Kubernetes 等分布式系统的核心数据一致性保障。

核心能力：

• 数据一致性保障：通过 Raft 协议实现多节点数据同步，确保集群中所有 etcd 实例数据一致，即使部分实例故障，也能通过主节点选举保证数据不丢失、服务不中断。

• 高并发读写优化：支持事务操作（如原子性的键值修改），同时通过分区（Partition）和索引（Index）机制，提升大规模集群下的读写性能。

• 数据安全：支持数据加密（静态加密存储、动态加密传输）和访问控制（通过证书限制仅 API Server 可读写），防止敏感数据（如密钥）泄露。

关键依赖：控制平面所有组件（API Server、Scheduler、Controller Manager）均需通过 API Server 间接读写 etcd，无组件直接与 etcd 交互，确保数据访问的统一性与安全性；以系统服务形式运行在控制平面节点。

3. Scheduler：集群的 “资源调度大脑”

• 核心定位：负责将未绑定节点的 Pod（Pending 状态）“精准分配” 到合适的工作节点，是实现集群资源高效利用、业务稳定运行的关键组件。

• 调度逻辑与能力：

  • 调度流程：分为 “过滤（Filtering）” 和 “打分（Scoring）” 两步：

    • 过滤阶段：排除不满足 Pod 资源需求的节点（如 Pod 需 2 核 CPU，节点剩余 CPU 不足则被过滤）、不满足亲和性 / 反亲和性规则的节点（如 Pod 需部署在 “标签为 env=prod” 的节点，无此标签的节点被排除）。

    • 打分阶段：对过滤后的节点按 “资源利用率、节点负载、Pod 分布均衡性” 等维度打分（如节点剩余资源越充足、负载越低，得分越高），选择得分最高的节点作为目标节点。

  • 调度策略自定义：支持通过 “调度配置文件（Scheduler Policy）” 或 “自定义调度器（Custom Scheduler）” 扩展调度逻辑，满足特殊业务需求（如将 GPU 密集型 Pod 优先调度到含 GPU 的节点）。

• 关键协作：仅负责 “决策 Pod 该调度到哪个节点”，不参与 Pod 的实际创建；调度结果（Pod 与节点的绑定关系）需通过 API Server 写入 etcd，再由目标节点的 kubelet 执行创建操作。以Pod形式运行，运行在控制平面节点，常见管理控制器Deployment。

4. Controller Manager：集群的 “状态维护管家”

• 核心定位：运行一系列 “控制循环（Controller Loop）” 的组件，核心职责是 “监控集群实际状态，对比期望状态，自动修正差异”，确保集群始终处于用户定义的期望状态。

• 核心控制循环与组件：

  • Deployment Controller：监控 Deployment 资源的期望副本数，若实际运行的 Pod 数少于期望数（如 Pod 故障删除），则自动创建新 Pod；若需版本更新，则按策略（如滚动更新）替换旧 Pod。

  • Node Controller：实时监控工作节点状态，若节点失联（如网络故障、节点宕机），则将该节点标记为 “NotReady”，并将其上的 Pod 调度到其他健康节点，实现故障转移。

  • ReplicaSet Controller：Deployment 的底层依赖，直接负责维护 Pod 副本数，确保实际 Pod 数与期望副本数一致（Deployment 通过管理 ReplicaSet 间接管理 Pod）。

  • Service Controller：监控 Service 与 Pod 的关联关系，当 Pod 创建 / 删除时，自动更新 Service 的 Endpoint 列表（记录 Pod 的 IP 和端口），确保 Service 能正确转发流量到后端 Pod。

• 关键特性：各控制循环独立运行，可通过配置关闭不需要的控制器（如测试环境可关闭 Node Controller），同时支持自定义控制器（如通过 Operator 框架扩展），满足业务特定的状态维护需求。以Pod形式运行，运行在控制平面节点，常见管理控制器Deployment。

二、工作节点（Worker Nodes）组件深度剖析：集群的 “业务执行单元”

工作节点是 K8s 集群中实际运行容器的 “载体”，通过本地组件与控制平面协同，完成 Pod 的创建、运行、网络配置与状态上报，是业务落地的核心层。

1. kubelet：节点的 “容器生命周期管家”

• 核心定位：运行在每个工作节点上的 “监工”，是控制平面与节点通信的 “唯一纽带”，负责管理节点上所有 Pod 的全生命周期（创建、启动、监控、停止、删除）。

• 核心能力与工作流程：

  • 状态同步与任务接收：通过 “List-Watch” 机制实时监听 API Server 中与本节点相关的 Pod 配置（如 Pod 的镜像、资源限制、挂载存储），一旦有新的 Pod 绑定到本节点，立即触发创建流程。

  • 容器创建与管控：调用容器运行时（如 Containerd）的 API，按 Pod 配置拉取镜像、创建容器、配置容器网络与存储（如挂载 PVC 对应的存储卷），确保容器按期望启动。

  • 健康检查与状态上报：

    • 执行 Pod 的 “存活探针（Liveness Probe）” 和 “就绪探针（Readiness Probe）”：若存活探针检测失败，kubelet 会重启容器；若就绪探针检测失败，kubelet 会将 Pod 标记为 “NotReady”，避免流量转发到未就绪的容器。

    • 实时将 Pod 的运行状态（如 Running、CrashLoopBackOff）、节点的资源使用情况（如 CPU / 内存使用率）上报给 API Server，最终同步到 etcd。

• 关键依赖：完全依赖容器运行时实现容器操作，自身不直接处理容器，仅负责 “指令下发” 与 “状态监控”，支持通过 CRI（Container Runtime Interface）适配不同容器运行时（如 Containerd、CRI-O）。以系统服务形式运行，运行在控制平面节点+工作节点。

2. kube-proxy：节点的 “网络流量管家”

• 核心定位：运行在每个工作节点上的 “网络代理”，负责维护节点的网络规则（如 iptables/IPVS 规则），实现 Service 的 “负载均衡” 与 “Pod 网络可达性”，是 K8s 网络模型的核心执行者。

• 核心能力与工作机制：

  • Service 流量转发：

    • 当集群中创建 Service 时，API Server 会将 Service 的 IP（ClusterIP）、端口与后端 Pod 的 Endpoint 列表同步给所有节点的 kube-proxy。

    • kube-proxy 根据 Service 类型（四种：ClusterIP、NodePort、LoadBalancer，externalName）在节点上配置网络规则。

  • 节点间网络通信：通过维护跨节点的网络规则，确保不同节点上的 Pod 可通过 Service 或 Pod IP 直接通信（依赖 CNI 插件配置的集群网络）。

注：Service类型：

1. ClusterIP：仅在集群内部暴露服务，分配集群唯一虚拟 IP，仅集群内 Pod 可访问，通过 iptables/ipvs 实现 Pod 间通信转发。
2. NodePort：在 ClusterIP 基础上，在每个节点开放静态端口（30000-32767），外部可通过 “节点 IP:NodePort” 访问，规则会转发到 ClusterIP。
3. LoadBalancer：结合云服务商负载均衡器，在 NodePort 基础上自动分配外部 IP，外部请求经负载均衡器转发到节点端口，适合公网访问。
4. ExternalName：通过 DNS 别名将 Service 映射到外部域名（如example.com），无需选择器，直接返回 CNAME 记录，实现集群内访问外部服务。

• 三种工作模式对比

1. Userspace 模式：流量转发逻辑在用户态（kube-proxy 进程内）实现。请求先经内核态 iptables 转发到用户态的 kube-proxy，再由其转发到目标 Pod，存在内核态与用户态的频繁切换，延迟高、吞吐量低，且 kube-proxy 进程故障会直接中断流量，可靠性差。

2. Iptables 模式：完全基于内核态 iptables 规则转发，通过 NAT 直接将流量从 Service 路由到 Pod，无需用户态参与，性能显著优于 userspace。但规则随 Service/Pod 数量增长会呈指数级膨胀，大规模集群下匹配效率下降。

3. IPVS 模式：基于内核态 IPVS 模块（专为负载均衡设计），通过哈希表快速匹配 Service 与 Pod，支持更多负载均衡算法（如轮询、最少连接），规则维护效率高，性能和扩展性优于 iptables，是大规模集群的首选。

4. userspace 被弃用的核心原因：其用户态转发机制带来的高延迟、低吞吐量无法满足集群性能需求，且可靠性依赖 kube-proxy 进程稳定性，而 iptables/IPVS 基于内核态实现，性能和稳定性优势显著，完全替代了 userspace 的使用场景，因此在 Kubernetes v1.24 中被正式移除。

3. 容器运行时（Container Runtime）：节点的 “容器执行引擎”

• 核心定位：符合 CRI（容器运行时接口）规范的 “容器操作工具”，是 kubelet 与容器之间的 “中间层”，负责实际的容器创建、启动、停止、销毁等操作，K8s 支持的主流运行时包括 Containerd、CRI-O。

• 以 Containerd 为例的核心能力：

  • 镜像管理：拉取（从 Docker Hub、Harbor 等仓库）、存储、校验容器镜像，支持镜像分层存储（节省磁盘空间）与镜像缓存（加速后续容器创建）。

  • 容器生命周期管理：创建容器命名空间（Network Namespace、Mount Namespace）、配置容器资源限制（CPU / 内存配额）、启动容器进程，同时监控容器运行状态（如进程 PID、资源使用率），并将状态反馈给 kubelet。

  • 网络与存储集成：通过 CNI 插件（如 Calico、Flannel）为容器配置网络（分配 Pod IP、设置路由），通过 CSI 插件（如 Ceph CSI、AWS EBS CSI）为容器挂载存储卷（如 PVC 对应的持久化存储）。

• 关键意义：K8s 通过 CRI 解耦了 “容器管理逻辑（kubelet）” 与 “容器执行逻辑（运行时）”，用户可根据需求替换容器运行时（如从 Docker 切换到 Containerd），无需修改 K8s 核心组件，提升了集群的灵活性。以系统服务形式运行，运行在控制平面节点+工作节点。

注：什么是CRI？实现形式是什么？

CRI 是 Container Runtime Interface（容器运行时接口） 的缩写，是 Kubernetes 定义的一套标准化接口规范，核心作用是解耦 Kubernetes 与底层容器运行时的依赖关系。

简单来说，Kubernetes 本身不直接管理容器的创建、启动、销毁等底层操作，而是通过 CRI 向 “容器运行时”（如 containerd、CRI-O 等）发送指令，由运行时负责执行具体的容器生命周期管理 ——CRI 就像 “中间翻译官”，让 Kubernetes 和不同的运行时之间能 “对话”，且无需为每种运行时单独适配。

CRI 的实现形式

CRI 基于 gRPC 协议（高效的跨进程通信协议），定义了两类核心 gRPC 服务：

• RuntimeService：负责容器生命周期管理（如创建、启动、停止、删除容器，以及容器资源限制、日志获取等）。

• ImageService：负责容器镜像管理（如下载、删除镜像，查询镜像元数据等）。

三、插件（Addons）深度剖析：集群的 “功能扩展羽翼”

• 核心定位：负责为 K8s 集群内的 Service 和 Pod 提供域名解析服务，解决 “Pod 如何通过域名访问 Service” 的问题，是集群内部通信的 “网络导航仪”。

1. CoreDNS：集群的 “内部 DNS 服务器”

• 核心能力：
  • 域名规则解析：

    • Service 域名：默认规则为 “Service 名称。命名空间.svc.cluster.local”（如 “nginx.default.svc.cluster.local”），Pod 可通过该域名直接访问对应 Service，无需记忆 Service 的 ClusterIP。

    • Pod 域名：默认规则为 “Pod IP 的反向解析（如 10-244-1-5.default.pod.cluster.local）”，支持通过 Pod 域名实现 Pod 间直接通信（需开启 Pod DNS 记录功能）。

  • 自定义 DNS 配置：支持通过 ConfigMap 配置自定义域名解析规则（如将 “xxx.com” 域名转发到集群外部的 DNS 服务器），满足跨集群或外部服务访问需求。

• 关键协作：kubelet 会在每个 Pod 的 “/etc/resolv.conf” 文件中配置 CoreDNS 的 Service IP 作为 DNS 服务器，确保 Pod 启动后默认使用 CoreDNS 进行域名解析。以Pod形式运行，通常运行在工作节点，常见管理控制器Deployment。

2. CNI 插件（如 Calico、Flannel）：集群的 “网络架构实现者”

• 核心定位：符合 CNI（容器网络接口）规范的插件，负责为 K8s 集群构建 “扁平、互通” 的容器网络，实现 “Pod 跨节点通信”“网络隔离” 等核心网络能力，是 K8s 网络模型的 “落地执行者”。

• 以 Calico 为例的核心能力：

  • Pod IP 分配：为每个 Pod 分配唯一的集群内 IP（从预设的 IP 段中分配），确保 Pod IP 不冲突。

  • 跨节点通信：通过 BGP（边界网关协议）在集群节点间同步路由规则，使不同节点上的 Pod 可通过 Pod IP 直接通信（无需 NAT 转换），通信延迟低、性能高。

  • 网络隔离：支持通过 NetworkPolicy 定义 “Pod 间的通信规则”（如仅允许 “env=prod” 命名空间的 Pod 访问 “port=8080” 的 Service），实现精细化的网络安全管控。

• 主流插件对比：

  • Flannel：轻量级插件，基于 vxlan 或 host-gw 模式实现跨节点通信，配置简单、适合小规模集群，缺点是不支持网络隔离，性能略低于 Calico。

  • Calico：高性能插件，基于 BGP 模式实现通信，支持网络隔离、流量监控，适合中大规模集群，缺点是配置相对复杂。

四、Kubernetes 核心组件全流程协作：以 “部署 Nginx 应用” 为例

结合上述组件剖析，通过 “部署 Nginx Deployment（3 个副本）” 的全流程，清晰呈现组件间的协同逻辑：

1. 发起请求：用户→API Server

• 用户执行命令 kubectl create deployment nginx --image=nginx:latest --replicas=3，kubectl 将请求封装为 REST API（HTTPS）发送至 API Server。

• API Server 验证请求合法性（如用户是否有权限创建 Deployment、参数是否正确），通过后将 Deployment 的 “期望状态”（3 个 Nginx 副本、镜像为 nginx:latest）写入 etcd。

2. 状态监控与 Pod 创建：API Server→Controller Manager→etcd

• Controller Manager 的 Deployment Controller 通过 “List-Watch” 机制监听 API Server，发现新的 Deployment 资源后，对比 “期望状态（3 个副本）” 与 “实际状态（0 个副本）”，触发副本创建逻辑。

• Deployment Controller 创建 3 个 ReplicaSet 资源（对应 3 个副本），并将 ReplicaSet 的配置通过 API Server 写入 etcd；同时，ReplicaSet Controller 监听新的 ReplicaSet，创建 3 个未绑定节点的 Pod 资源，Pod 配置（镜像、资源需求）同样写入 etcd。

3. 调度决策：API Server→Scheduler→etcd

• Scheduler 通过 “List-Watch” 监听 API Server，发现 3 个 Pending 状态的 Nginx Pod 后，启动调度流程：

  • 过滤阶段：排除集群中 CPU / 内存不足、无 “运行 nginx 权限” 的节点，假设剩余节点 A、B、C。

  • 打分阶段：对 A、B、C 按 “剩余资源、负载均衡” 打分，最终决定将 Pod1 调度到 A、Pod2 调度到 B、Pod3 调度到 C。

• Scheduler 将 “Pod 与节点的绑定关系” 通过 API Server 写入 etcd。

4. 容器启动：API Server→kubelet→容器运行时

• 节点 A、B、C 上的 kubelet 分别通过 “List-Watch” 监听 API Server，发现 “有 Pod 绑定到本地节点” 后，从 API Server 获取 Pod 的完整配置（镜像、资源限制）。

• kubelet 调用容器运行时（如 Containerd）的 CRI 接口：

  • Containerd 拉取 nginx:latest 镜像，创建 Pod 的 Network Namespace 和 Mount Namespace。

  • CNI 插件（如 Calico）为每个 Pod 分配唯一集群 IP（如 10.244.1.10、10.244.2.15、10.244.3.20），并配置跨节点路由规则。

  • Containerd 启动 Nginx 容器，kubelet 执行 “就绪探针”（检测 80 端口是否存活），确认容器就绪后，将 Pod 状态更新为 “Running” 并上报 API Server，最终同步到 etcd。

5. 网络配置与域名解析：kube-proxy→CoreDNS

• API Server 将 3 个 Nginx Pod 的 Endpoint 列表（IP+80 端口）同步给所有节点的 kube-proxy。

• kube-proxy（IPVS 模式）在每个节点上配置规则：“将访问 nginx Service 的 ClusterIP（如 10.96.0.100:80）的流量，轮询转发到 3 个 Pod 的 IP:80”。

• CoreDNS 监听新的 nginx Service，自动生成域名 “nginx.default.svc.cluster.local”，并关联 Service 的 ClusterIP；其他 Pod 可通过该域名访问 Nginx 服务，无需记忆 IP。

6. 状态维护与故障修复：Controller Manager→kubelet

• 若节点 B 的 Nginx Pod 因镜像损坏故障停止，kubelet 将 Pod 状态更新为 “CrashLoopBackOff” 并上报 API Server。

• Deployment Controller 监听 Pod 状态变化，发现 “实际副本数（2 个）< 期望副本数（3 个）”，立即创建新的 Pod4，并由 Scheduler 调度到节点 D。

• 节点 D 的 kubelet 启动 Pod4，最终集群恢复 3 个 Running 状态的 Nginx Pod，实现 “自我修复”。

注：点赞+关注+收藏，下期我们详细讲讲工作负载，不见不散。