2025-3-08 k8s创建pod流程图详解

sequenceDiagram
    participant User as 用户
    participant Kubectl as Kubectl
    participant API as API Server
    participant CM as Controller Manager
    participant Etcd as etcd
    participant Scheduler as 调度器
    participant Kubelet as Kubelet
    participant CRI as 容器运行时
    participant CNI as 容器网络接口
    participant CSI as 容器存储接口

    User ->> Kubectl: 提交 Pod/Deployment 定义
    Kubectl ->> API: 发送创建请求
    API ->> Etcd: 存储资源信息
    
    alt 如果是高级资源(Deployment/ReplicaSet等)
        API ->> CM: 通知新资源创建
        CM ->> API: 创建对应的附属资源(如ReplicaSet/Pod)
        API ->> Etcd: 存储附属资源信息
    end
    
    API ->> Scheduler: 通知新建的未调度Pod
    Scheduler ->> API: 获取未调度的Pod信息
    Scheduler ->> Scheduler: 评估资源并分配节点
    Scheduler ->> API: 更新Pod的节点分配信息
    API ->> Etcd: 存储更新的Pod信息
    
    API ->> Kubelet: 通知分配到该节点的Pod
    Kubelet ->> API: 获取Pod信息
    Kubelet ->> CRI: 拉取并启动容器镜像
    Kubelet ->> CNI: 配置容器网络
    Kubelet ->> CSI: 挂载存储卷
    
    Kubelet ->> API: 更新Pod状态
    API ->> Etcd: 存储更新的Pod状态
    API ->> CM: 通知Pod状态变化
    CM ->> CM: 处理相关控制循环
    
    CM ->> API: 更新相关资源状态(如Deployment状态)
    API ->> Etcd: 存储更新的资源状态

Kubernetes Pod 创建流程时序图详解 #

基于我们之前讨论的 Kubernetes 时序图,以下是每个交互过程的详细解释:

1. 用户 → Kubectl: 提交 Pod/Deployment 定义 #

  • 含义:用户通过命令行工具(kubectl create/apply)或YAML文件提交资源定义
  • 具体操作:如kubectl apply -f deployment.yaml
  • 数据流:YAML/JSON格式的资源定义文件

2. Kubectl → API Server: 发送创建请求 #

  • 含义:kubectl将用户请求转换为REST API调用
  • 具体操作:格式化、验证资源定义并发送HTTP请求
  • 处理细节:包括认证令牌添加、API版本处理

3. API Server → etcd: 存储资源信息 #

  • 含义:API Server将资源定义持久化存储
  • 具体操作:API Server验证请求后写入etcd数据库
  • 存储内容:完整的资源规范(spec)和初始状态(status)

4. 条件分支: 高级资源处理 #

  • 含义:系统根据资源类型执行不同处理流程
  • 判断条件:资源是否为高级控制器(Deployment/StatefulSet等)

5. API Server → Controller Manager: 通知新资源创建 #

  • 含义:API Server通知控制器有新资源需要处理
  • 具体操作:通过watch机制发送资源创建事件
  • 接收方:对应的控制器(如DeploymentController)

6. Controller Manager → API Server: 创建附属资源 #

  • 含义:控制器创建层级关系中的子资源
  • 具体操作:Deployment创建ReplicaSet,ReplicaSet创建Pod
  • 处理逻辑:控制器实现了资源的"期望状态"逻辑

7. API Server → etcd: 存储附属资源信息 #

  • 含义:API Server将新创建的子资源信息写入数据库
  • 具体操作:保存ReplicaSet和Pod的定义
  • 关系维护:存储资源间的所有者引用(OwnerReferences)

8. API Server → Scheduler: 通知新建的未调度Pod #

  • 含义:API Server告知调度器有新Pod需要调度
  • 具体操作:通过watch API发送Pod创建事件
  • 标识特征:Pod的spec.nodeName为空

9. Scheduler → API Server: 获取未调度的Pod信息 #

  • 含义:调度器获取完整的Pod定义及相关信息
  • 具体操作:查询Pod详情和当前集群节点状态
  • 数据内容:Pod资源需求、亲和性规则、污点容忍等

10. Scheduler内部: 评估资源并分配节点 #

  • 含义:调度器执行调度算法选择最佳节点
  • 具体操作:过滤(Predicates)和打分(Priorities)
  • 决策因素:节点资源、亲和性、分布策略等

11. Scheduler → API Server: 更新Pod的节点分配信息 #

  • 含义:调度器提交Pod调度决策
  • 具体操作:更新Pod的spec.nodeName字段
  • 更新方式:通过PATCH操作修改Pod定义

12. API Server → etcd: 存储更新的Pod信息 #

  • 含义:将调度决策持久化到数据库
  • 具体操作:更新etcd中的Pod记录
  • 变更内容:主要是nodeName字段的添加

13. API Server → Kubelet: 通知分配到该节点的Pod #

  • 含义:目标节点的Kubelet收到新Pod分配通知
  • 具体操作:通过node上的Kubelet watch API接收事件
  • 判断条件:Pod的spec.nodeName匹配本节点

14. Kubelet → API Server: 获取Pod信息 #

  • 含义:Kubelet获取完整的Pod配置
  • 具体操作:查询Pod的详细定义
  • 数据内容:容器镜像、环境变量、卷配置等

15. Kubelet → CRI: 拉取并启动容器镜像 #

  • 含义:Kubelet请求容器运行时创建容器
  • 具体操作:通过CRI接口调用Docker/containerd等
  • 执行内容:镜像拉取、容器创建和启动

16. Kubelet → CNI: 配置容器网络 #

  • 含义:为Pod配置网络连接
  • 具体操作:调用CNI插件(如Calico、Flannel)
  • 配置内容:IP分配、路由规则、网络命名空间

17. Kubelet → CSI: 挂载存储卷 #

  • 含义:为Pod挂载所需的存储卷
  • 具体操作:调用CSI驱动挂载PV
  • 执行内容:卷准备、挂载点创建、文件系统挂载

18. Kubelet → API Server: 更新Pod状态 #

  • 含义:报告Pod当前运行状态
  • 具体操作:更新Pod的status字段
  • 状态内容:Pod阶段(phase)、容器状态、IP地址等

19. API Server → etcd: 存储更新的Pod状态 #

  • 含义:持久化Pod的最新状态
  • 具体操作:更新etcd中的Pod status记录
  • 更新频率:Kubelet定期发送状态更新

20. API Server → Controller Manager: 通知Pod状态变化 #

  • 含义:控制器收到Pod状态变更事件
  • 具体操作:通过watch机制接收状态更新
  • 接收方:多个控制器(Deployment、ReplicaSet等)

21. Controller Manager内部: 处理相关控制循环 #

  • 含义:控制器执行协调逻辑
  • 具体操作:比较资源当前状态与期望状态
  • 处理内容:副本数调整、状态计算、异常处理

22. Controller Manager → API Server: 更新资源状态 #

  • 含义:控制器更新高级资源的状态
  • 具体操作:更新Deployment/ReplicaSet的status
  • 状态内容:可用副本数、更新状态、条件等

23. API Server → etcd: 存储更新的资源状态 #

  • 含义:持久化高级资源的最新状态
  • 具体操作:更新etcd中的资源records
  • 完成循环:至此完成一个完整的控制循环

这些步骤展示了Kubernetes声明式API和控制器模式的核心工作原理,体现了系统的松耦合架构和自动化协调能力。

主要参与者包括:

  • 用户
  • Kubectl
  • API Server
  • Controller Manager
  • etcd
  • Scheduler (可能不太相关,因为删除不需要调度)
  • Kubelet
  • 容器运行时 (CRI)
  • 容器网络接口 (CNI)
  • 容器存储接口 (CSI)

删除流程的主要步骤:

  1. 用户通过 kubectl 发起删除请求
  2. API Server 接收请求并更新 etcd 中的资源状态(添加删除时间戳)
  3. 如果是高级资源,Controller Manager 会处理附属资源的级联删除
  4. Kubelet 观察到删除请求,开始终止容器
  5. 各种钩子和优雅终止期处理
  6. 清理网络和存储资源
  7. 完成删除后更新状态

让我创建这个序列图:

Kubernetes Pod/Deployment 删除流程图 #

下面是 Kubernetes 中删除 Pod 或 Deployment 的完整流程序列图:

sequenceDiagram
    participant User as 用户
    participant Kubectl as Kubectl
    participant API as API Server
    participant CM as Controller Manager
    participant Etcd as etcd
    participant Kubelet as Kubelet
    participant CRI as 容器运行时
    participant CNI as 容器网络接口
    participant CSI as 容器存储接口

    User ->> Kubectl: 发起删除请求 (kubectl delete)
    Kubectl ->> API: 发送删除API请求
    
    API ->> API: 添加删除时间戳(deletionTimestamp)
    API ->> API: 设置finalizers(如有)
    API ->> Etcd: 更新资源状态为"正在删除"
    
    alt 如果是Deployment等高级资源
        API ->> CM: 通知资源正在删除
        CM ->> CM: 检查删除策略(级联/非级联)
        
        alt 级联删除(默认)
            CM ->> API: 删除所属的子资源(如ReplicaSet)
            API ->> Etcd: 更新子资源为"正在删除"
            
            CM ->> API: 删除所属的Pod
            API ->> Etcd: 更新Pod为"正在删除"
        end
    end
    
    API ->> Kubelet: 通知节点上的Pod被标记删除
    
    Kubelet ->> Kubelet: 执行Pod终止流程
    Kubelet ->> Kubelet: 执行preStop钩子(如有)
    
    Kubelet ->> CRI: 发送终止信号(SIGTERM)
    Note over CRI: 等待优雅终止期(默认30秒)
    
    alt 容器未在终止期内退出
        Kubelet ->> CRI: 发送强制终止信号(SIGKILL)
    end
    
    Kubelet ->> CRI: 删除容器
    Kubelet ->> CNI: 清理网络资源
    Kubelet ->> CSI: 卸载并清理存储卷
    
    Kubelet ->> API: 移除Pod finalizers(如有)
    Kubelet ->> API: 报告Pod已终止
    
    API ->> Etcd: 从etcd中物理删除Pod数据
    
    alt 如果是高级资源
        CM ->> API: 检查所有子资源是否已删除
        CM ->> API: 移除资源finalizers
        API ->> Etcd: 从etcd中物理删除资源数据
    end
    
    API ->> Kubectl: 返回删除完成状态
    Kubectl ->> User: 显示资源已被删除

我将按照时序图中的顺序来分析:

  1. 用户 → Kubectl: 发起删除请求
  2. Kubectl → API Server: 发送删除API请求
  3. API Server内部处理: 添加deletionTimestamp和finalizers
  4. API Server → etcd: 更新资源状态为"正在删除"
  5. 高级资源(如Deployment)的处理分支
  6. Controller Manager处理级联删除
  7. API Server → Kubelet: 通知Pod删除
  8. Kubelet执行Pod终止流程
  9. Kubelet → CRI: 容器终止流程
  10. Kubelet → CNI和CSI: 网络和存储资源清理
  11. Kubelet → API Server: 完成Pod终止
  12. API Server → etcd: 物理删除资源
  13. 高级资源的finalizers处理
  14. 删除完成的通知返回

Kubernetes Pod/Deployment 删除流程详解 #

下面是我生成的删除 Pod/Deployment 流程图中每个步骤的详细解释:

1. 用户 → Kubectl: 发起删除请求 (kubectl delete) #

  • 含义:用户通过命令行发起资源删除操作
  • 具体操作:如kubectl delete pod my-podkubectl delete deployment my-app
  • 选项:可以包含--grace-period--force--cascade等参数调整删除行为

2. Kubectl → API Server: 发送删除API请求 #

  • 含义:kubectl将用户删除命令转化为API调用
  • 具体操作:发送DELETE请求到API Server对应端点
  • API路径:例如/api/v1/namespaces/{namespace}/pods/{name}
  • 参数传递:将删除选项作为查询参数传递

3. API Server → API Server: 添加删除时间戳(deletionTimestamp) #

  • 含义:API Server将资源标记为正在删除,而非立即物理删除
  • 具体操作:在资源元数据中添加metadata.deletionTimestamp字段
  • 作用:让系统知道该资源已请求删除,但清理工作尚未完成

4. API Server → API Server: 设置finalizers(如有) #

  • 含义:保留或添加finalizers,防止资源被过早删除
  • 具体操作:确保metadata.finalizers数组包含所需的finalizer标记
  • 作用:确保所有必要的清理工作完成后才真正删除资源

5. API Server → etcd: 更新资源状态为"正在删除" #

  • 含义:将修改后的资源(带删除时间戳)持久化
  • 具体操作:更新etcd中对应键值
  • 状态变化:资源仍然存在,但带有删除标记

6. API Server → Controller Manager: 通知资源正在删除 #

  • 含义:删除事件通过watch机制传递给控制器
  • 具体操作:Controller Manager接收到资源更新事件
  • 处理方式:相关控制器(如DeploymentController)开始处理删除逻辑

7. Controller Manager → Controller Manager: 检查删除策略 #

  • 含义:确定如何处理资源层级关系
  • 具体操作:检查DeleteOptions.PropagationPolicy
  • 策略类型
    • Foreground:先删除子资源,再删除父资源
    • Background:异步删除子资源(默认)
    • Orphan:不删除子资源,只删除父资源

8. Controller Manager → API Server: 删除所属的子资源 #

  • 含义:级联删除子资源(如ReplicaSet和Pod)
  • 具体操作:发送DELETE请求给这些子资源
  • 处理顺序:通常是从最高层向下删除(Deployment→ReplicaSet→Pod)

9. API Server → Kubelet: 通知节点上的Pod被标记删除 #

  • 含义:Pod所在节点的Kubelet收到Pod删除事件
  • 具体操作:通过watch机制接收Pod更新(包含deletionTimestamp)
  • 触发时机:当Pod被标记删除时

10. Kubelet → Kubelet: 执行Pod终止流程 #

  • 含义:Kubelet开始协调Pod删除过程
  • 具体操作:按顺序执行终止任务,确保有序清理

11. Kubelet → Kubelet: 执行preStop钩子(如有) #

  • 含义:在发送终止信号前执行Pod中定义的preStop钩子
  • 具体操作:运行容器中配置的preStop命令或HTTP请求
  • 目的:允许应用程序优雅关闭(如关闭连接、保存状态)

12. Kubelet → CRI: 发送终止信号(SIGTERM) #

  • 含义:请求容器内进程优雅终止
  • 具体操作:通过CRI向容器发送SIGTERM信号
  • 期望行为:应用程序捕获信号并执行清理操作后退出

13. 等待优雅终止期 #

  • 含义:给容器内进程时间来处理SIGTERM信号
  • 具体操作:等待默认30秒(或自定义时间)
  • 可配置:通过Pod spec的terminationGracePeriodSeconds设置

14. Kubelet → CRI: 发送强制终止信号(SIGKILL) #

  • 含义:如果容器未在优雅终止期内退出,强制终止
  • 具体操作:发送SIGKILL信号,不可被捕获或忽略
  • 结果:立即终止容器进程,不执行任何清理

15. Kubelet → CRI: 删除容器 #

  • 含义:移除容器实例
  • 具体操作:通过CRI接口调用运行时删除容器
  • 清理内容:容器文件系统、元数据等

16. Kubelet → CNI: 清理网络资源 #

  • 含义:释放Pod的网络资源
  • 具体操作:调用CNI插件的DEL命令
  • 清理内容:IP地址、路由、网络命名空间等

17. Kubelet → CSI: 卸载并清理存储卷 #

  • 含义:解除卷挂载并清理本地卷资源
  • 具体操作:卸载文件系统,调用CSI接口
  • 注意:持久卷本身不会被删除,只解除与Pod的关联

18. Kubelet → API Server: 移除Pod finalizers #

  • 含义:标记Pod资源可以被物理删除
  • 具体操作:更新Pod移除kubernetes.io/pvc-protection等finalizers
  • 结果:移除阻止Pod物理删除的保护机制

19. Kubelet → API Server: 报告Pod已终止 #

  • 含义:通知API Server Pod已完全终止
  • 具体操作:更新Pod状态为Terminated
  • 作用:触发后续清理流程

20. API Server → etcd: 从etcd中物理删除Pod数据 #

  • 含义:当所有finalizers被移除后,真正删除资源数据
  • 具体操作:从etcd中删除对应键值
  • 结果:Pod资源彻底从系统中移除

21. Controller Manager → API Server: 检查所有子资源是否已删除 #

  • 含义:对于高级资源,确认所有子资源已经清理完毕
  • 具体操作:检查是否存在ownerReferences指向该资源的对象
  • 作用:确保不留下任何"孤儿"资源

22. Controller Manager → API Server: 移除资源finalizers #

  • 含义:标记高级资源(如Deployment)可以被物理删除
  • 具体操作:移除资源上的所有finalizers
  • 结果:允许资源最终被物理删除

23. API Server → etcd: 从etcd中物理删除资源数据 #

  • 含义:彻底删除高级资源的所有数据
  • 具体操作:从etcd中删除对应键值
  • 结果:资源完全从系统中移除

24. API Server → Kubectl: 返回删除完成状态 #

  • 含义:向客户端通知删除操作已完成
  • 具体操作:返回成功状态码和响应
  • 内容:可能包含删除资源的最终状态

25. Kubectl → User: 显示资源已被删除 #

  • 含义:向用户显示操作结果
  • 具体操作:通常显示"xxx deleted"消息
  • 额外信息:可能包含删除的资源名称和类型

这个删除流程展示了Kubernetes如何通过一系列协调步骤,确保资源被安全、有序地清理,同时保持系统的一致性和可靠性。

删除流程关键点解释 #

  1. 删除请求初始化

    • 用户发起 kubectl delete 命令
    • API Server 不会立即物理删除资源,而是先标记删除
  2. 级联删除处理

    • 资源会根据 propagationPolicy 决定删除行为
    • Foreground: 先删除子资源,再删除父资源
    • Background: 异步删除子资源(默认行为)
    • Orphan: 只删除父资源,保留子资源
  3. Finalizers 和保护机制

    • Finalizers 阻止资源被立即删除,确保清理工作完成
    • 例如 kubernetes.io/pv-protection 保护正在使用的卷
  4. Pod 终止流程

    • 执行 preStop 钩子
    • 发送 SIGTERM 并等待优雅终止期
    • 如必要,发送 SIGKILL 强制终止
    • 清理网络和存储资源
  5. 删除确认

    • 所有 finalizers 清除后,资源才会从 etcd 中物理删除
    • 控制器确认所有依赖资源已清理

这个流程展示了 Kubernetes 在资源删除过程中如何确保有序、可控和完整的清理,防止出现孤立资源和资源泄漏。