题目重点：从 kubectl apply 到 API server、etcd、controller、scheduler、kubelet 的状态收敛解释组件职责。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 用对一个 Deployment 执行 `kubectl apply` 作为训练主线，帮助连起两个问法；题目未说实际要求演示 Deployment。
- 按 Kubernetes 官方通用架构解释；网络插件、CRI 实现、托管控制平面和版本差异需依具体集群核对。
解题路线
- 客户端：kubectl 从 kubeconfig/context 找 API server 与身份，转换用户意图为 API 请求；apply 是声明式提交目标对象，不是直接 SSH 到 Node 启容器。
- 控制面：API server 认证/授权、校验/准入并持久化 API 对象到 etcd；controller 观察期望与当前状态并创建/更新所需对象。etcd 是持久一致存储，不是运行 Pod 的组件。
- 调度与节点：scheduler 给未绑定的 Pod 选 Node；该节点 kubelet 根据 Pod spec 协调容器运行时、卷和健康状态，Pod 运行/就绪会回报 API。Service 流量实现受网络组件和平台配置影响，不能把 kube-proxy 当所有集群唯一 dataplane。
- 用 `kubectl get/describe/logs/rollout status` 排查：资源未创建查 API/RBAC/准入，Pending 查 scheduler 事件/资源，已调度但起不来查 kubelet、镜像/卷，Running 不 Ready 查探针/应用。
- 组件是异步协调而非一次调用链阻塞到全部成功；状态收敛有延迟和失败重试，部署滚动更新要看实际健康门槛。
手动走一遍
apply 一个 replicas=3 的 Deployment，API 接收目标；Deployment/ReplicaSet controller 建 Pod，scheduler 为未绑定 Pod 选节点，kubelet 拉起容器并报告状态。若镜像拉取失败，apply 仍可能已成功，`rollout status` 和 Pod 事件会显示后续失败。
规模与取舍
控制面对象数、watch fan-out、调度队列及节点数影响扩展能力；不能由题目推断固定 QPS/集群大小。命令响应时间与工作负载 Ready 时间是两个不同指标。
易错点与追问
容易失分的边界
- 认为 kubectl 直接写 etcd 或直接在每个 Node 启容器。
- 把 scheduler 说成持续运行 Pod 的节点代理。
- apply 返回成功就声称 Deployment 已 Ready。
- 只背组件名，无法按 Pending/ImagePullBackOff 等状态定位故障。
- 把某一发行版网络数据面当 Kubernetes 唯一实现。
继续深挖
- Deployment 的期望副本数与实际数量如何收敛？
- API server 不可用但已有 Pod 在运行，会发生什么？
- Pod Pending 与 Running NotReady 分别优先看什么？
- kubectl context 选错集群如何避免误操作？
技术参考
- Kubernetes 官方组件架构：控制面与节点组件职责。
- Kubernetes 官方 kubectl 说明：kubectl 通过 API server 工作。
- Kubernetes 官方 Controller 模式：期望状态与实际状态异步收敛。
