kuberneres 原理

Kubernetes（简称K8s）的核心原理，可概括为：以声明式API+控制循环为核心范式，通过控制平面+工作节点的分布式架构，将容器组织为Pod并实现自愈、扩缩容、滚动更新等自动化能力，最终达成“描述期望，系统自动实现”的容器编排目标。以下从核心思想、架构、关键组件、工作机制到典型流程，分层详解。

一、核心设计理念：声明式 vs 命令式

K8s区别于传统运维工具的根本，在于声明式API与控制循环的组合设计：

  • 声明式API：用户只需描述期望状态（如“运行3个Nginx副本”），无需编写实现步骤；系统自动计算并执行所需操作
  • 控制循环（调谐循环/Reconciliation Loop）：各控制器持续执行“观察→比较→执行”循环，不断消除实际状态与期望状态的差异
  • 最终一致性：允许中间状态存在，持续驱动集群向目标收敛，而非追求瞬时一致
  • 自愈能力：通过健康检查（存活探针/就绪探针）、节点故障迁移、容器重启等机制，保障服务可用性

二、集群架构：控制平面+工作节点

K8s集群采用主从（Master-Worker）架构，由控制平面（决策层）和工作节点（执行层）组成，所有组件通过kube-apiserver通信。

2.1 控制平面（Control Plane）：集群的“大脑”

负责集群状态维护、调度决策、控制器管理，核心组件：

  1. kube-apiserver：集群唯一入口，提供RESTful API，负责认证授权、请求验证、状态读写协调。所有组件（控制器、调度器、kubelet等）均通过它与etcd交互，是集群的“通信中枢”
  2. etcd：分布式键值存储，保存集群所有持久化状态与配置数据（Pod定义、Service、节点信息等）。基于Raft协议保证强一致性与高可用，支持Watch机制以推送状态变更
  3. kube-controller-manager：管理各类控制器的集合，每个控制器负责一类资源的状态调谐，如：
    • ReplicaSet控制器：维持Pod副本数
    • Deployment控制器：管理版本、滚动更新、回滚
    • Node控制器：节点健康监测与故障处理
    • Endpoint控制器：维护Service与Pod的映射关系
  4. kube-scheduler：Pod调度器，负责将Pending状态的Pod分配到合适节点，核心流程分两步：
    • 过滤（Predicates）：剔除不满足Pod需求的节点（如资源不足、亲和性冲突）
    • 打分（Priorities）：对符合条件的节点评分，选择最优节点；支持自定义策略

2.2 工作节点（Worker Node）：集群的“手脚”

运行用户负载（Pod），核心组件：

  1. kubelet：节点上的“管家”，负责Pod生命周期管理。监听apiserver获取本节点Pod任务，通过CRI（容器运行时接口） 调用containerd/cri-o等运行时创建容器；执行健康检查、资源监控与状态上报
  2. kube-proxy：节点网络代理，实现Service的负载均衡与服务发现。监听Service与Endpoint变化，维护iptables/IPVS规则，将发往ClusterIP的流量转发至后端Pod
  3. 容器运行时：负责容器的实际创建、运行、销毁，如Docker、containerd、CRI-O等，通过CRI与kubelet解耦
  4. Pod：K8s的最小调度单元，包含一个或多个紧密协作的容器，共享网络（同一IP+端口空间）、存储卷与主机名；Pod内容器通过localhost通信

三、核心概念：理解K8s抽象层

3.1 Pod：最小调度单元

  • 本质：容器的“逻辑主机”，封装一个或多个协同容器
  • 特性：共享网络/存储；原子调度（同Pod的容器始终在同一节点）；生命周期短暂（被调度后不可迁移，重建会换IP）
  • 重启策略：Always（默认，容器退出即重启）、OnFailure（失败退出时重启）、Never（不自动重启）

3.2 控制器：Pod的“管理者”

K8s通过控制器模式实现Pod的自动化管理：

  • ReplicaSet：保证指定数量的Pod副本始终运行
  • Deployment：管理ReplicaSet，支持滚动更新、版本回滚、扩缩容，是最常用的无状态应用管理方式
  • StatefulSet：管理有状态应用，保证Pod名称、网络标识、存储的稳定性
  • DaemonSet：确保每个节点运行一个Pod副本（如日志采集、监控代理）
  • Job/CronJob：管理一次性/周期性任务

3.3 Service：Pod的“稳定访问层”

Pod是动态的（IP变化、扩缩容），Service提供固定入口，解决服务发现与负载均衡：

  • ClusterIP：默认类型，仅集群内部访问的虚拟IP
  • NodePort：在每个节点暴露端口，外部通过节点IP:NodePort访问
  • LoadBalancer：对接云厂商负载均衡器，自动分配外部IP
  • 核心机制：标签选择器匹配Pod；EndpointSlice记录健康Pod的IP:Port；kube-proxy维护转发规则（iptables/IPVS）；CoreDNS提供服务名→ClusterIP解析

3.4 其他关键抽象

  • Namespace：资源隔离，划分多租户空间（默认default）
  • Volume：Pod存储抽象，支持本地存储、分布式存储（如PV/PVC）
  • ConfigMap/Secret：配置与敏感信息管理，解耦镜像与环境配置

四、核心工作机制：从声明到实现

4.1 声明式API与资源生命周期

用户提交YAML/JSON的资源定义（如Deployment）→ apiserver验证并写入etcd → 控制器watch到变化，触发控制循环 → 调度器为Pod选择节点 → kubelet创建容器 → 持续监控状态，直至符合期望

4.2 调度流程：Pod如何找到“家”

  1. 入队：未调度的Pod进入调度队列
  2. 过滤（Predicates）：排除不满足条件的节点（如资源不足、节点污点、亲和性冲突）
  3. 打分（Priorities）：对候选节点按资源均衡、亲和性、负载等维度评分
  4. 绑定：调度器将Pod绑定到最优节点（更新Pod的spec.nodeName）
  5. 执行：目标节点kubelet监听到Pod，调用CRI拉取镜像并启动容器

4.3 控制循环实例：Deployment扩缩容

  1. 用户修改Deployment的replicas: 3→2→提交到apiserver→写入etcd
  2. Deployment控制器watch到期望副本数减少→计算差异（需删1个Pod）
  3. 向apiserver发送删除指令→删除对应Pod
  4. ReplicaSet控制器同步更新，确保副本数最终=2

4.4 网络模型：扁平化与互通

K8s网络模型的核心要求：

  • 每个Pod拥有独立IP
  • 所有Pod可直接通信（无需NAT）
  • 节点与Pod可直接通信（无需NAT）
    实现依赖CNI（容器网络接口） 插件（如Calico、Flannel），负责Pod网络创建、IP分配、跨节点路由。

五、典型场景流程：滚动更新的内部协作

以Deployment滚动更新为例，看组件如何联动：

  1. 用户更新Deployment的镜像版本 → apiserver写入etcd
  2. Deployment控制器创建新ReplicaSet，逐步增加新Pod、减少旧Pod
  3. 调度器为新Pod选择节点
  4. 目标节点kubelet拉取镜像，创建并启动新Pod
  5. Endpoint控制器更新Service对应的EndpointSlice，加入新Pod、移除旧Pod
  6. 所有节点的kube-proxy监听到Endpoint变化，更新iptables/IPVS规则
  7. 流量逐步切到新Pod；旧Pod被优雅终止（等待连接完成）

六、总结

K8s的本质，是一套分布式系统的自动化操作系统：通过抽象底层基础设施，以声明式方式定义应用状态，用控制循环持续驱动系统自愈、扩缩容、更新，最终让运维从“手动操作”走向“策略定义”，实现云原生应用的高效管理。

需要我补充一份面试高频原理题（含自愈机制、调度过滤/打分、Service实现、滚动更新策略、etcd一致性等）及答案吗？

posted @ 2026-02-09 12:34  wuyingchun1987  阅读(1)  评论(0)    收藏  举报