静态 Pod 由 kubelet 直接管理
使用 kubeadm 部署的控制面组件通常以静态 Pod 形式运行：kubelet 监视指定目录下的清单文件，文件内容变化就重建对应组件，整个过程不经过调度器。因此这类 Pod 不能用常规方式删除，删掉也会被立刻重建；调整组件镜像版本，本质上就是修改清单文件里的镜像标签。修改前先备份清单文件是必要的习惯，一处语法错误就可能让组件起不来。
基本信息
| 适用场景 | kubeadm 等使用静态 Pod 的部署方式 |
|---|---|
| 清单目录 | 常见为 /etc/kubernetes/manifests，由 kubelet 参数指定 |
| 管理方式 | 改文件即生效，无需 kubectl 操作 |
| 删除行为 | 常规删除无效，会被 kubelet 重建 |
| 常见组件 | apiserver、controller-manager、scheduler、etcd |
典型使用场景
- 查看控制面组件：确认它们以静态 Pod 形态运行
- 调整组件参数：通过修改清单文件里的启动参数生效
- 版本核对：镜像标签即组件版本，用于确认实际运行版本
- 演练与恢复：理解移除清单文件会让组件停机，评估风险
- 故障排查：组件起不来时先检查清单语法与参数
查看与控制（控制面节点执行）
查看与控制（控制面节点执行）
sudo ls /etc/kubernetes/manifests
kubectl -n kube-system get pods | grep -E 'kube-apiserver|etcd|kube-scheduler'
kubectl -n kube-system get pod kube-apiserver-<节点名> -o jsonpath='{.spec.containers[0].image}'
sudo cp /etc/kubernetes/manifests/kube-apiserver.yaml /root/kube-apiserver.yaml.bak # 改前备份
sudo crictl ps | grep apiserver # 节点侧确认容器实际状态操作与结果
| 操作 | 结果 | 注意 |
|---|---|---|
| 修改清单文件 | 对应组件被重建 | 改前先备份原文件 |
| 常规删除该 Pod | 会被立即重新创建 | 静态 Pod 无法用常规方式删除 |
| 移除清单文件 | 对应组件停止运行 | 属于高风险操作，需十分谨慎 |
| 修改镜像标签 | 组件升级或降级 | 注意版本兼容性 |
控制面组件的版本信息写在清单文件的镜像标签里，升级操作说到底就是改这些标签并让 kubelet 完成重建。
直接编辑生产控制面的静态 Pod 清单风险很高：一旦语法或参数出错，组件可能无法启动，而修复又依赖同一份清单，建议在维护窗口进行并保留可用的备份。