一、静态 Pod （Static Pod）

1. 静态 Pod 介绍

静态 Pod 是由每个节点上的 kubelet 守护进程 直接管理，而 不经过 API Server 创建或控制的 Pod。这意味着静态 Pod 的生命周期不受 kube-apiserver 管控，创建或删除逻辑仅由节点本地的 kubelet 处理。
即使通过 kubectl 或 API 删除，kubelet 也会重新创建对应的静态 Pod。
静态 Pod 在 API Server 上会生成一个 “镜像 Pod”（mirror Pod），其名称为静态 Pod 名加上节点名后缀，例如 kube-apiserver-node1，可以在 kubectl get pods 中看到此镜像对象。
(static Pod 的定义及镜像 Pod 特性)

2. 创建静态 Pod 的两种方式

（1）文件系统托管（Filesystem-hosted）

将 YAML 或 JSON 格式的 manifest 文件放到 kubelet 监视的目录（默认是 /etc/kubernetes/manifests）。
kubelet 会周期性扫描该目录，发现新文件就创建新的静态 Pod，删除文件则终止对应 Pod。
目录路径可通过 kubelet 配置中的 staticPodPath，或通过 --pod-manifest-path 命令行参数设定。

（2）网页托管（Web-hosted）

将 Pod manifest 保存在可访问的 URL 上，并通过 --manifest-url=<URL> 参数配置给 kubelet。
kubelet 会定期从该 URL 拉取 manifest 文件，并根据变化创建或更新静态 Pod。

创建方式对比：

方法	说明
文件系统托管	本地目录托管，使用频繁，适合本地化部署；支持 `staticPodPath` 配置
网页托管	从远程 URL 拉取，适合集中管理；配置 `--manifest-url` 参数

3. 使用场景与实用价值

静态 Pod 一般用于 集群引导阶段（Cluster Bootstrapping），尤其是控制平面组件（如 kube-apiserver、controller-manager、scheduler、etcd）在 API Server 未启动时需要运行。kubeadm 正是利用静态 Pod 来启动这些核心组件。
静态 Pod 可在 API Server 不可用时仍由 kubelet 管理，提高系统的启动可靠性与恢复能力。
镜像 Pod 的存在使得静态 Pod 虽不受控制，但仍可通过 kubectl 命令查看状态。

4. 注意事项与限制

静态 Pod 不受控制器（如 Deployment、ReplicaSet、DaemonSet）管理，不具备自动扩展或滚动更新能力。
修改或删除静态 Pod 必须通过更新或删除节点上的 manifest 文件，不能使用 kubectl delete 或 kubectl edit。
静态 Pod 无法引用 Kubernetes API 资源（如 ConfigMap、Secret、ServiceAccount），因为它不属于控制平面对象。
一旦节点故障，静态 Pod 不会自动调度到其他节点；缺乏高可用调度机制。

总结

静态 Pod 提供一种可靠、独立于控制平面的 Pod 管理方式，非常适用于引导 Kubernetes 控制平面或运行节点特定任务。选用方式分为本地文件托管和网页托管两种，应结合部署需求选择。同时，应注意静态 Pod 的不可调度性、管理方式与 API Server 的隔离性带来的操作差异。

若你需要进一步了解 yaml 示例、静态 Pod 和 DaemonSet 区别，或实践中如何结合静态 Pod 进行控制平面恢复，我也可以继续帮你完善文档或提供示例！