静态 Pod 其实很好理解：它就是"这台节点自己养的 Pod"。我们平时用 kubectl apply 创建的 Pod，是先写进 API Server，再由调度器挑节点、控制器去拉起；那静态 Pod 走的路完全不一样------它直接由 kubelet 在本机创建和保活，不需要调度器帮你选位置，也不靠 API Server 来下发创建指令。那它是怎么创建出来的？很简单，把 Pod 的 YAML 丢进 kubelet 监听的目录里（最常见就是 /etc/kubernetes/manifests），kubelet 看到文件就立刻在这台机器上把 Pod 拉起来；文件还在，它就一直盯着，挂了就重启；文件删掉了，Pod 也就跟着消失。你会发现，这更像是"守护进程 + 配置文件"的玩法，而不是"集群统一调度"的玩法。
你可能会问：既然不归 API Server 管，那我用 kubectl get pod 为什么还能看到它？这是因为 kubelet 会给静态 Pod 在 API Server 里同步一个"镜像 Pod"（mirror pod），让集群能观测到它的状态，但这个镜像只是"展示用"。换句话说，你在集群里删除这个镜像 Pod，并不会真正干掉静态 Pod；真正能决定它生死的，还是节点上的那份 YAML。顺带还有个明显特征：静态 Pod 的名字通常会带上节点名做后缀，一眼就能看出来它是绑死在某台机器上的。
那静态 Pod 适合用来跑什么？答案也很直观：必须固定在指定节点启动的关键组件。比如控制面那几位------kube-apiserver、kube-controller-manager、kube-scheduler，很多时候就是用静态 Pod 方式在控制节点上直接拉起来的。毕竟这种东西你敢让它"漂"吗？它要是被调度到别的节点上，或者因为调度失败起不来，那整个集群还怎么玩。静态 Pod 的价值就在这：不花里胡哨，但足够可靠，节点在，它就得在。