执行 kubectl run 后，Kubernetes 内部发生了什么？

关于作者

专注于 Linux 容器运维技术分享。如果想了解更多 运维相关领域 的实战技巧、最新资讯和独家资料，欢迎关注我的微信公众号 Linux容器运维。
回复关键字 “视频资料”，即可获取我们整理的 Kubernetes、Docker 容器、Python 编程、Linux 运维等教学视频合集（总计 548GB）。本资源仅面向学习交流使用，请遵守版权和使用规范，严禁商用、转售或违规传播。

---

本文深入解析 Kubernetes 中 kubectl run 命令的完整执行流程，从客户端到控制平面再到节点，带你了解容器部署的每一个细节。

命令概述

kubectl run 是 Kubernetes 集群中最常用的命令之一，用于快速创建并运行 Pod 或 Deployment 资源，是从命令行快速部署应用的核心方式。

执行该命令后，Kubernetes 内部会经过请求处理、资源验证、调度、容器运行时管理等多个核心阶段，最终完成容器的启动和运行。

核心操作流程

整体流程

当你执行 kubectl run 命令时，整个过程会经历以下步骤：

1. 客户端处理：解析命令参数，生成资源模板，构造 API 请求
2. APIServer 处理：认证授权，准入控制，资源验证，写入存储
3. 控制器管理器处理：创建 ReplicaSet 和 Pod 资源
4. 调度器处理：选择合适的节点并绑定 Pod
5. Kubelet 处理：启动容器并监控状态
6. 终端反馈：返回执行结果

流程图

分阶段详细解析

1. 客户端处理（本地）

在终端执行 kubectl run <pod-name> --image=<镜像名> [其他参数] 时，客户端会完成以下操作：

• 参数解析：解析命令行参数（如镜像名、资源限制、命令覆盖、命名空间等），校验参数合法性
• 资源模板生成：
  • Kubernetes 1.18+ 版本默认生成 Deployment 资源，包含 replicas=1、selector、template 等核心字段
  • 指定 --restart=Never 生成裸 Pod 资源，指定 --restart=OnFailure 生成 Job 资源
• API 请求构造：将模板转换为 JSON/Protobuf 格式，通过 HTTPS 发送到 Kubernetes APIServer

2. APIServer 处理（控制平面核心）

APIServer 作为所有操作的入口，接收请求后执行以下流程：

• 认证：验证请求发起者的身份（如 token、证书、ServiceAccount 等）
• 授权：通过 RBAC/ABAC 等授权策略，检查用户是否有创建资源的权限
• 准入控制：
  • 验证型准入插件（如 PodSecurityPolicy）校验资源配置是否符合集群策略
  • 突变型准入插件（如 DefaultStorageClass）自动补充默认配置
• 资源验证：校验资源字段的合法性（如镜像地址可访问、资源请求合理）
• 写入存储：将验证通过的资源对象写入 etcd，并返回 201 Created 响应

3. 控制器管理器处理（控制平面）

etcd 中新增的资源会被 kube-controller-manager 监听，触发以下逻辑：

• Deployment 控制器：检测到新的 Deployment 资源后，自动创建对应的 ReplicaSet 资源
• ReplicaSet 控制器：监听 ReplicaSet 资源，对比期望副本数和实际运行副本数，若实际为 0，则生成 Pod 资源对象

4. 调度器处理（控制平面）

新创建的 Pod 资源初始状态为 Pending，kube-scheduler 会监听此类 Pod 并执行调度：

• 节点筛选：遍历集群所有节点，筛选出满足 Pod 运行条件的节点
• 节点优先级排序：对筛选后的节点进行打分，选择得分最高的节点
• 绑定 Pod：将 Pod 的 nodeName 字段更新为目标节点名称，完成调度

5. Kubelet 处理（节点层面）

目标节点上的 kubelet 进程会持续监听属于本节点的 Pod 资源，触发容器启动流程：

• Pod 资源解析：读取 Pod 的 spec 配置（如容器镜像、挂载卷、环境变量、端口映射等）
• CRI 接口调用：通过容器运行时接口与容器运行时（如 containerd、cri-o）交互：
  • 拉取容器镜像（若本地无缓存）
  • 创建 Pod 沙箱（基于 pause 容器，为 Pod 内所有容器提供共享环境）
  • 创建并启动容器（挂载卷、注入环境变量、执行启动命令）
• 状态更新：实时监控容器状态，将 Pod 状态、容器 ID 等信息上报给 APIServer

6. 终端反馈

kubectl 客户端接收到 APIServer 的最终响应后，在终端输出执行结果，如 deployment.apps/<name> created。

此时你可通过 kubectl get pods 查看 Pod 运行状态。

关键补充说明

不同参数的流程差异

参数	资源类型	核心流程差异
--restart=Never	裸 Pod	跳过 Deployment/ReplicaSet 阶段
--restart=OnFailure	Job	由 Job 控制器管理 Pod 重启逻辑
--dry-run=client	无实际资源创建	仅本地生成 YAML，不发送 APIServer 请求

核心组件交互要点

• etcd 仅作为存储：不参与任何业务逻辑，仅保存资源的最终状态
• 控制器仅监听+调谐：通过"调谐循环"对比期望状态和实际状态，仅负责创建/删除子资源
• Kubelet 是节点唯一操作入口：所有容器的操作均由 Kubelet 通过 CRI 接口完成

常见异常情况

• 镜像拉取失败：Kubelet 阶段报错，Pod 状态为 ErrImagePull/ImagePullBackOff
• 调度失败：Scheduler 阶段无可用节点，Pod 状态为 Pending，事件中显示 FailedScheduling
• 权限不足：APIServer 授权阶段拒绝，kubectl 直接返回 Forbidden 错误
• 准入控制拦截：如 PodSecurityPolicy 不允许特权容器，APIServer 返回 Invalid 错误

总结

核心流程关键点

• kubectl run 的本质是通过 APIServer 向 etcd 写入资源对象，由 Kubernetes 控制器和节点组件完成后续的自动化调度与容器启动
• 完整流程分为 6 个核心阶段：客户端处理 → APIServer 校验存储 → 控制器创建子资源 → 调度器绑定节点 → Kubelet 启动容器 → 状态反馈
• 不同参数会改变生成的资源类型（Deployment/Pod/Job），但核心的校验、调度、容器管理逻辑保持一致

核心设计思想

Kubernetes 的核心设计原则在这个流程中得到了充分体现：

• 声明式 API：用户仅声明"要运行一个 Pod"，无需关心具体如何调度、启动，由集群自动完成
• 组件解耦：APIServer、控制器、调度器、Kubelet 各司其职，通过 etcd 共享状态，实现高可用和可扩展
• 分层校验：从客户端到 APIServer 再到节点，多阶段校验确保资源配置合法、集群状态稳定