在K8S中,什么是静态Pod?
好的,这是一个非常重要的 Kubernetes 概念,特别是在搭建和控制平面组件管理方面。
什么是静态 Pod?
静态 Pod(Static Pod)是由特定节点上的 kubelet
守护进程直接管理的 Pod,它并不通过 Kubernetes API Server 进行管理。
换句话说,静态 Pod 的定义文件(YAML/JSON)直接存放在某个节点的工作目录上,由该节点上的 kubelet
定期扫描并创建/维护。API Server 对此并不知情,它只是“事后”从一个特殊的镜像那里得知了这些 Pod 的存在。
核心工作原理
-
指定清单目录:你需要配置节点的
kubelet
,告诉它一个本地目录(称为 静态 Pod 清单目录),例如/etc/kubernetes/manifests
。这个配置通常在kubelet
的启动参数--pod-manifest-path
中指定。 -
kubelet 监控目录:
kubelet
会持续监控这个指定的目录。 -
文件操作即指令:
- 创建/修改 YAML 文件:当你将一份 Pod 的 YAML 文件(例如
my-static-pod.yaml
)放入这个目录后,kubelet
会立即读取这个文件。 - 创建 Pod:
kubelet
直接使用本地的容器运行时(如 containerd, docker)根据 YAML 文件的定义来创建和运行 Pod。 - 删除 YAML 文件:如果你从目录中删除了这个 YAML 文件,
kubelet
会立即终止并删除对应的 Pod。
- 创建/修改 YAML 文件:当你将一份 Pod 的 YAML 文件(例如
-
API Server 的“镜像”:虽然静态 Pod 是
kubelet
直接创建的,但该节点的kubelet
会自动为每个静态 Pod 在 API Server 中创建一个对应的“镜像 Pod”(Mirror Pod)。- 这个“镜像 Pod”是只读的。
- 你可以通过
kubectl get pods
看到它,它的名字会以<static-pod-name>-<node-name>
的形式出现。 - 你不能通过
kubectl delete
或kubectl edit
来管理这个 Pod,这些操作会在 API Server 层面被拒绝。你必须去节点上操作对应的 YAML 文件。
静态 Pod 的主要特点
特性 | 说明 |
---|---|
管理方式 | 由节点上的 kubelet 直接管理,不经过 API Server、Scheduler、Controller Manager 等控制平面组件。 |
依赖关系 | 依赖节点上的 kubelet 服务。如果 kubelet 停止,静态 Pod 也会停止。 |
高可用性 | 即使集群控制平面(API Server 等)完全宕机,静态 Pod 依然可以正常运行,因为它们不依赖于控制平面。 |
调度 | 总是被调度到它所在的那个节点上,因为没有调度器参与。 |
操作方式 | 必须通过登录到节点主机,直接增、删、改清单目录中的文件来管理。无法用 kubectl 命令直接操作。 |
最常见的使用场景:托管 Kubernetes 控制平面组件
这是静态 Pod 最经典和最重要的用途。当你使用 kubeadm
这类工具搭建 Kubernetes 集群时,kubeadm
会在主节点(Master Node) 上执行以下操作:
- 生成
kube-apiserver
、kube-controller-manager
、kube-scheduler
、etcd
等组件的 Pod 清单文件(YAML)。 - 将这些 YAML 文件放到主节点
kubelet
的静态 Pod 清单目录中(通常是/etc/kubernetes/manifests
)。 - 主节点上的
kubelet
会监控此目录并立即创建这些 Pod。
这样做的好处非常明显:
- 自举(Bootstrap):控制平面组件(如 API Server)本身是 Kubernetes 集群的一部分,但集群还没起来,无法用 Kubernetes 来管理它们。静态 Pod 通过操作系统层面的
kubelet
解决了这个“先有鸡还是先有蛋”的问题。 - 高可用:即使控制平面瘫痪,只要节点和
kubelet
正常,kubelet
就能确保控制平面组件(如 API Server)的 Pod 重新启动,从而尝试恢复控制平面。
静态 Pod vs. 普通 Pod(由 Deployment 等控制器管理)
特性 | 静态 Pod | 普通 Pod |
---|---|---|
管理者 | 节点 kubelet |
控制器(Deployment, StatefulSet 等)通过 API Server |
创建方式 | 将文件放入指定目录 | kubectl apply , 通过 API Server |
调度 | 固定在本节点 | 由 Scheduler 调度到任意合适节点 |
高可用 | 依赖单个节点的 kubelet |
由控制器跨节点保证 |
操作接口 | 节点命令行 (ssh , vim ) |
kubectl |
主要用途 | 节点级别的系统守护进程,特别是集群控制平面 | 普通的集群工作负载和应用 |
如何识别一个 Pod 是否是静态 Pod?
使用 kubectl get pods -o wide
,查看 Pod 的 OWNER REFERENCES
字段。静态 Pod 对应的镜像 Pod 的 Owner 会是 Node
(对应的节点),而不是 ReplicaSet
或 DaemonSet
等控制器。
或者,使用 kubectl describe pod <pod-name>
,在输出中寻找 Controlled By: Node/<node-name>
。
总结
静态 Pod 是 Kubernetes 中一种特殊的管理模式,它绕过了集群的核心控制回路,由节点级的 kubelet
直接负责。 它的核心价值在于:
- 搭建和恢复控制平面:这是其最关键的用途。
- 运行节点专用的系统级守护进程:当某些守护进程必须且只能运行在特定节点上时,可以考虑使用静态 Pod。
对于大多数日常应用部署,你应该始终使用标准的 Pod 控制器(如 Deployment、DaemonSet),而不是静态 Pod。