Kubernetes架构

Kubernetes（K8s） 是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。其架构设计体现了分层解耦和模块化协作的理念，能够灵活支撑大规模容器化应用的运维管理。
1、核心架构

Kubernetes 采用经典的主从（Master-Slave）架构，现在更普遍地称为控制平面（Control Plane） 和工作节点（Worker Node） 架构。
控制平面 (Control Plane)： 负责管理集群，做出全局决策（如调度应用），以及响应集群事件。在生产环境中，控制平面通常跨多台服务器部署，以确保高可用性和容错能力
工作节点 (Worker Nodes)： 负责运行你的容器化应用。每个集群至少需要一个工作节点来运行 Pod（应用负载的基本单元）
flowchart TD    subgraph ControlPlane[控制平面]        API[API Server]        Scheduler[Scheduler]        CCM[Cloud Controller Manager]        etcd[etcd]        CM[Controller Manager]    end    subgraph WorkerNode1[工作节点 1]        Kubelet1[Kubelet]        KubeProxy1[kube-proxy]        ContainerRuntime1[Container Runtime]        Pod1[Pod]        Pod2[Pod]    end    subgraph WorkerNode2[工作节点 2]        Kubelet2[Kubelet]        KubeProxy2[kube-proxy]        ContainerRuntime2[Container Runtime]        Pod3[Pod]    end    API --- etcd    API --- Scheduler    API --- CM    API --- CCM    API -.->|指令与控制| Kubelet1    API -.->|指令与控制| Kubelet2    Kubelet1 --> ContainerRuntime1    Kubelet1 --> KubeProxy1    Kubelet2 --> ContainerRuntime2    Kubelet2 --> KubeProxy2    ContainerRuntime1 --> Pod1    ContainerRuntime1 --> Pod2    ContainerRuntime2 --> Pod32、控制平面 (Control Plane) 组件

控制平面是集群的“大脑”，它可以在高可用（HA）模式下运行，即多个主节点同时运行，以确保集群的可靠性。
2.1 kube-apiserver

kube-apiserver 是控制平面的核心组件，也是集群所有组件的唯一入口（所有操作都需通过 API 调用完成）
功能：

• 暴露 Kubernetes API，供用户（kubectl）、控制平面其他组件和外部系统调用。
  
• 负责认证、授权、准入控制等所有安全相关的逻辑。
  
• 验证并处理所有请求，读写集群状态数据到 etcd。
  

特点：无状态设计，可通过多实例部署（如负载均衡器后端挂多个 apiserver）实现高可用。
2.2 etcd

etcd 是一个开源的分布式键值存储（基于 Raft 一致性算法），负责存储 K8s 集群的所有关键数据
功能：

• 持久化存储整个集群的所有配置数据和状态信息（例如，Pod、Service、Namespace 等所有对象的状态）。
  
• 组件（如 kube-scheduler）通过 apiserver 读取 etcd 数据
  
• 组件（如 kube-controller-manager）通过 apiserver 写入数据到 etcd
  

特点： 它是 Kubernetes 中唯一有状态的控制平面组件。其数据的安全性至关重要。etcd 需单独部署高可用集群（至少 3 节点），且需配置数据备份（避免数据丢失）。
2.3 kube-scheduler

当用户创建一个 Pod（容器的最小运行单元）时，kube-scheduler 负责为 Pod 选择一个合适的 Node 节点运行
功能：

• 监听 kube-apiserver，发现未被分配节点（nodeName 为空）的新创建的 Pod。
  
• 根据一套复杂的调度策略（如资源请求、亲和性/反亲和性、数据位置等）为 Pod 选择一个最适合的工作节点。
  
• 调度决策完成后，通过 kube-apiserver 更新 Pod 的定义，将其绑定到目标节点上。
  

2.4 kube-controller-manager

kube-controller-manager 是一个 “控制器集合”，负责维护集群的期望状态（Desired State）与实际状态（Current State）一致。它通过 “监听 - 对比 - 调谐”（Reconciliation Loop）机制工作
核心控制器

• Node Controller：监控 Node 状态，若 Node 故障（如断连），标记 Node 为 “NotReady”，并驱逐其上的 Pod；
  
• ReplicaSet Controller：维护 Deployment/ReplicaSet 的副本数，若 Pod 异常退出，自动创建新 Pod 补充；
  
• Service Controller：管理 Service 与 Pod 的关联（通过标签选择器），并维护负载均衡规则；
  
• EndpointSlice Controller：将 Service 关联的 Pod IP 整理为 EndpointSlice（避免单 Endpoint 资源过大）；
  
• Namespace Controller：管理命名空间的生命周期（创建、删除、垃圾回收）；
  
• Job Controller：管理一次性任务（Job），确保任务完成后停止 Pod；
  
• CronJob Controller：管理定时任务（CronJob），按 cron 表达式触发 Job。
  

2.5 cloud-controller-manager

cloud-controller-manager 仅在云环境（如 AWS、Azure、阿里云） 中使用，负责对接云厂商的 API，实现 “云原生” 功能，核心职责包括：

• Node Controller：从云厂商获取 Node 的外部 IP、磁盘等信息；
  
• Service Controller：创建云厂商的负载均衡器（如 AWS ELB、阿里云 SLB），并关联到 K8s Service；
  
• Volume Controller：对接云厂商的存储服务（如 AWS EBS、阿里云 EBS），创建 / 挂载持久化存储卷（PV）。
  

作用：解耦 K8s 核心逻辑与云厂商特有功能，使 K8s 可适配不同云平台。
3、工作节点 (Worker Node) 组件

Node 是集群中 “运行容器的工作节点”（可理解为物理机或虚拟机），每个 Node 上运行多个组件，负责执行控制平面下发的任务（如运行 Pod）。
3.1 kubelet

kubelet 是运行在每个 Node 上的代理进程，是 Node 与控制平面通信的核心
功能：

• 监听 kube-apiserver 发来的指令，管理本节点上 Pod 的生命周期（创建、销毁 Pod）。
  
• 通过容器运行时接口（CRI）与容器运行时交互，拉取镜像、启动和停止容器。
  
• 定期向 kube-apiserver 报告本节点的状态（Node Status）和 Pod 的状态。
  

注意：kubelet 只管理 “由 K8s 创建的容器”，不干涉节点上手动启动的容器。
3.2 kube-proxy

kube-proxy 是运行在每个 Node 上的网络代理进程，负责实现 K8s 的Service 网络模型（如负载均衡、服务发现）
功能：

• 维护网络规则：通过 apiserver 监听 Service 和 EndpointSlice 的变化，动态更新节点的 iptables/IPVS 规则；
  例：当创建一个 Service 时，kube-proxy 在所有 Node 上添加 iptables 规则，将 Service 的虚拟 IP（ClusterIP）转发到后端 Pod 的 IP；
  
• 实现负载均衡：对访问 Service 的请求，按 “轮询” 或 “会话保持” 策略转发到后端 Pod（依赖 iptables/IPVS 的负载均衡能力）；
  
• 支持网络模式：
  
  
  
  • iptables 模式：轻量，适合小规模集群；
    
  • IPVS 模式：性能更好（支持更多连接、更丰富的负载均衡算法），适合大规模集群。
    
  
  

注意：kube-proxy 仅处理 “集群内部 Service 访问” 和 “NodePort 类型 Service 的外部访问”，不负责容器间的跨节点通信（由 CNI 插件处理）。
3.3 容器运行时 (Container Runtime)

容器运行时是负责启动和管理容器的软件，是 K8s 运行 Pod 的 “底层依赖”。K8s 通过 CRI（Container Runtime Interface，容器运行时接口）与运行时交互
功能：

• 根据 kubelet 的指令，拉取镜像，创建、启动和停止容器。
  
• 必须支持 容器运行时接口（CRI），这是一个让 kubelet 能够与各种运行时通信的标准 API。
  

4、一个请求的流程

以“用户通过 kubectl 创建一个 Deployment”为例，梳理 K8s 各组件的协同流程：

• 用户发起请求：执行 kubectl create deployment nginx --image=nginx，kubectl 将请求转换为 REST API 发送给 kube-apiserver；
  
• apiserver 处理请求：
  
  
  
  • 验证请求合法性（如用户权限、Deployment 格式）；
    
  • 将 Deployment 数据写入 etcd；
    
  
  
• controller-manager 监听并调谐：
  
  
  
  • Deployment Controller 通过 apiserver 监听 etcd 中的 Deployment 变化；
    
  • 发现新的 Deployment，自动创建对应的 ReplicaSet（定义 Pod 副本数，如默认 1 个），并将 ReplicaSet 写入 etcd；
    
  • ReplicaSet Controller 监听 ReplicaSet 变化，发现新的 ReplicaSet，创建对应的 Pod（定义容器镜像、资源等），并将 Pod 写入 etcd；
    
  
  
• scheduler 调度 Pod：
  
  
  
  • kube-scheduler 监听未分配 Node 的 Pod；
    
  • 为 Pod 执行“过滤-打分”流程，选择一个合适的 Node；
    
  • 通过 apiserver 将 Pod 与 Node 绑定（更新 Pod 的 spec.nodeName），并写入 etcd；
    
  
  
• kubelet 运行 Pod：
  
  
  
  • 目标 Node 上的 kubelet 通过 apiserver 监听分配给自己的 Pod；
    
  • 调用容器运行时（如 Containerd）拉取 nginx 镜像，创建并启动容器；
    
  • 定期向 apiserver 上报 Pod 状态（如 Running）和 Node 资源使用情况；
    
  
  
• kube-proxy 配置网络：
  
  
  
  • 若用户为 Deployment 创建 Service（如 kubectl expose deployment nginx --port=80），kube-proxy 监听 Service 和 EndpointSlice 变化；
    
  • 在所有 Node 上更新 iptables/IPVS 规则，将 Service 的 ClusterIP 转发到后端 Pod 的 IP；
    
  
  
• 用户验证结果：执行 kubectl get pods，kubectl 通过 apiserver 从 etcd 读取 Pod 状态，显示 Pod 已处于 Running 状态。。
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！