Kubernetes集群架构由哪些核心组件组成？从控制平面到Pod网络入门解析

Kubernetes 的核心职责是管理容器化应用的编排，但真正理解它不能只停留在 kubectl 命令层面，而要先弄清楚集群内部的角色分工。通常把集群分为控制平面和工作节点两类角色。控制平面不直接运行业务容器，而是保存集群状态、接受用户请求、做出调度和控制决策；工作节点则负责启动容器、配置网络并上报运行状态。这种分层设计让集群具备统一入口和自动恢复能力。理解各组件的协作方式，是排查调度失败、服务不通、Pod 无法启动等问题的基础。

控制平面：集群的决策中枢

控制平面的首要组件是 API Server。它是整个集群的唯一操作入口，无论是用户通过 kubectl 下发指令，还是集群内部组件之间的交互，都要经过 API Server。API Server 以 RESTful 接口暴露资源操作能力，并负责认证、授权、准入控制以及资源对象的校验。也就是说，任何对 Pod、Service、Deployment 等对象的创建、更新、删除请求，第一步都是到达 API Server，再由它写入持久化存储或转发给其他组件。

etcd 则是集群的状态存储层。它是一个强一致性的键值数据库，保存了所有 Kubernetes 对象的期望状态和实际状态信息。集群能够实现故障自愈，核心原因就在于 etcd 中始终记录着用户期望的副本数、镜像版本、网络配置等内容。需要特别注意的是，etcd 通常不应该被手动直接修改，因为绕过 API Server 写入数据可能导致控制器逻辑混乱。生产环境中通常还会对 etcd 做定期备份，以便在灾难恢复时重建集群状态。

除 API Server 和 etcd 外，控制平面还包含 Scheduler 和 Controller Manager。Scheduler 负责监听未被调度的 Pod，根据资源请求、节点可用 CPU 和内存、亲和性规则、污点容忍等条件，经过过滤和打分两个阶段为 Pod 选择一个合适的工作节点。Controller Manager 则包含多个内置控制器，例如 Deployment Controller、ReplicaSet Controller、Node Controller 等。它们以控制循环的方式不断比较期望状态与实际状态，一旦发现差异就向 API Server 发出调整请求。比如某个副本宕机后，ReplicaSet Controller 会识别到实际副本数不足，马上补充一个新的 Pod。

工作节点：真正运行容器的执行层

工作节点上最重要的组件是 kubelet。kubelet 是运行在每台节点上的代理进程，它通过 API Server 获取分配给本节点的 Pod 清单，然后调用容器运行时接口创建容器，并持续监控容器状态。kubelet 还会定期向 API Server 上报节点状态和 Pod 运行情况，如果某个容器异常退出，kubelet 会根据重启策略决定是否重新拉起。可以说，控制平面只负责发出指令，真正的容器生命周期管理是由 kubelet 完成的。

另一个关键组件是 kube-proxy。它主要负责 Service 的网络代理和负载均衡实现。Kubernetes 中的 Pod IP 会随着重建而发生变化，为了给外部或集群内部提供稳定访问入口，Service 通过标签选择器关联一组 Pod。kube-proxy 则在每个节点上维护网络规则，把访问 Service 的流量转发到后端 Pod。kube-proxy 支持 iptables、IPVS 等模式，其中 IPVS 模式在大规模集群中通常具有更好的转发性能和更低的延迟。

容器运行时同样是工作节点不可缺少的部分。Kubernetes 通过 CRI 接口与容器运行时解耦，早期主要使用 Docker，现在社区更倾向于 containerd 或 CRI-O。容器运行时负责创建和运行具体的容器，包括镜像拉取、文件系统隔离、进程隔离、网络命名空间配置等。除了容器运行时，工作节点还需要 CNI 网络插件，例如 Calico、Flannel 或 Cilium，它们负责为每个 Pod 分配 IP 并打通跨节点的容器网络。

核心概念：Pod、Service与Deployment如何协作

Pod 是 Kubernetes 中最小的调度和运行单元。一个 Pod 可以包含一个或多个容器，这些容器共享网络命名空间和存储卷，因此它们之间可以通过 localhost 通信，也能共享同一个 Volume。实际项目中，通常把一个主容器和一个辅助容器放在同一个 Pod 里，例如主容器运行应用，边车容器负责日志采集或代理转发。下面是一个最小 Deployment 的 YAML 示例，它声明了 3 个 Nginx 副本。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

Deployment 是管理 Pod 副本和滚动升级的高级控制器。用户不需要直接创建 Pod，而是声明 Deployment，由 Deployment Controller 创建对应的 ReplicaSet，再由 ReplicaSet 保证 Pod 数量。滚动更新时，Deployment 会逐步创建新版本的 Pod 并淘汰旧版本，确保更新过程中始终有可用副本。回滚操作也可以通过记录的历史版本快速完成。

Service 则在 Pod 之上提供稳定访问入口。由于 Pod 重建后 IP 会变化，Service 使用标签选择器动态关联后端 Pod，并分配一个固定 ClusterIP。集群内的其他应用可以访问这个 ClusterIP，由 kube-proxy 将流量分发到健康的后端 Pod。如果希望集群外部访问，可以使用 NodePort 或 LoadBalancer 类型。下面是一个 Service 示例，它将请求转发到带有 app: nginx 标签的 Pod。

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: NodePort

此外，Namespace 用于逻辑隔离不同团队或环境的资源，ConfigMap 和 Secret 用来存放配置和敏感信息。容器中的应用可以通过环境变量或挂载文件的方式读取这些配置，从而避免把数据库密码、证书等硬编码在镜像里。理解这些对象之间的关系，是进一步学习 Helm、Operator 和 GitOps 的基础。

一次部署请求的完整链路

为了把组件串联起来，可以走一遍创建 Deployment 的完整流程。当用户执行 kubectl apply -f nginx-deployment.yaml 后，kubectl 会读取 YAML 文件并构造请求发送给 API Server。API Server 先进行认证和授权，再经过准入控制器检查，随后把对象写入 etcd。此时 Deployment 资源已经存在，但还没有真正创建 Pod。

接着 Deployment Controller 监听到新的 Deployment 对象，会创建对应的 ReplicaSet。ReplicaSet Controller 随后发现期望副本数是 3，但当前 Pod 数量是 0，于是向 API Server 提交创建 3 个 Pod 的请求。这些 Pod 刚创建时处于 Pending 状态，因为没有指定节点。Scheduler 监听到未调度的 Pod 后，根据节点资源、亲和性和污点策略选择合适的节点，将调度结果写入 Pod 的 spec.nodeName 字段。

工作节点上的 kubelet 发现自己节点上有新的 Pod 分配过来，就调用容器运行时拉取镜像并启动容器。容器启动成功后，kubelet 将 Pod 状态更新为 Running，并上报给 API Server。与此同时，kube-proxy 会为 Service 建立相应的网络规则，确保外部请求能够转发到这些 Pod。整个链路中每个组件只负责一部分工作，通过 API Server 和 etcd 完成状态同步，最终使实际状态与期望状态保持一致。理解了这条链路，后续配置资源限制、调试网络策略、排查滚动更新卡住等问题时，就能更快定位是控制平面决策错误，还是节点执行层故障。

Kubernetes集群架构核心组件容器编排修改时间：2026-09-28 06:05:23