第 08 篇：一次 kubectl apply 的完整旅程：从命令行到容器落地的六阶段链路（底座认知 08）

一次 kubectl apply 的旅程底座认知 · 第 08 篇收尾从命令行到容器落地把前面所有组件串成一条完整链路目 录一、起点kubectl apply二、全链路分解2.1 第一阶段进入 apiserver2.2 第二阶段写入 etcd2.3 第三阶段控制器感知并创建 ReplicaSet/Pod2.4 第四阶段scheduler 选节点2.5 第五阶段kubelet 落地容器2.6 第六阶段kube-proxy 提供服务三、状态收敛闭环四、对应排障清单五、总结一、起点kubectl apply当你在终端执行 kubectl apply -f deployment.yaml 时一次贯穿整个集群的协作就此开始。本篇以创建一个 Deployment 为例走完整条链路。二、全链路分解2.1 第一阶段进入 apiserverkubectl 读取 kubeconfig 定位 apiserver把 YAML 序列化为 REST 请求发出认证携带客户端证书或 token通过 apiserver 认证关卡授权RBAC 校验当前身份是否有创建权限准入准入控制校验/修改对象然后才允许落库2.2 第二阶段写入 etcdapiserver 将 Deployment 对象持久化到 etcd并返回给 kubectl 一个成功响应。此时「期望状态」已被记录但集群还什么都没真正执行。2.3 第三阶段控制器感知并创建 ReplicaSet/Podcontroller-manager 中的 Deployment 控制器 watch 到变更创建 ReplicaSet 对象ReplicaSet 控制器又创建 Pod 对象。Pod 的 spec 被写入 etcd等待调度。2.4 第四阶段scheduler 选节点kube-scheduler 监听到新的未调度 Pod执行 Filter → Score → Bind把 Pod 绑定到选定节点绑定结果写回 etcd。2.5 第五阶段kubelet 落地容器目标节点上的 kubelet watch 到自己被分配了 Pod于是拉取镜像、创建 pause 沙箱与业务容器执行健康检查探针上报 Pod 与容器状态Pod 进入 RunningDeployment 达到期望副本数2.6 第六阶段kube-proxy 提供服务若 Pod 暴露了 Servicekube-proxy 会更新 iptables/ipvs 规则使流量能够转发到新 Pod。三、状态收敛闭环整个过程不是「一次性命令」而是「持续收敛」控制器不断把实际状态与期望状态比对并纠正。例如容器崩溃 → kubelet 重启Always 策略Pod 消失 → ReplicaSet 控制器重建节点宕机 → 调度器与控制器协作把 Pod 迁移到健康节点这正是声明式 API 的核心魅力你只需描述「要什么」系统自动维护「怎么做到」。四、对应排障清单故障点排查方向kubectl 无响应apiserver 健康、认证授权、kubeconfigPod 一直 Pending调度事件、节点资源、taintPod 创建失败/ImagePullBackOffkubelet、containerd、镜像地址与凭据容器反复重启健康检查探针、崩溃日志访问不通Service 类型、Endpoint、kube-proxy 规则五、总结至此「底座认知」九篇系列已带你走完从容器技术基石到一次请求全链路的完整闭环。此后学习调度、存储、网络、安全、发布都是在这条链路上不断深化每一环。建议实践在实验集群上用 kubectl apply 创建 Deployment结合 kubectl describe、kubectl get events、crictl ps 等命令亲自观察每个阶段的状态流转。