static pod一简介

最新推荐文章于 2025-02-19 10:57:50 发布

原创最新推荐文章于 2025-02-19 10:57:50 发布 · 770 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #docker #容器

kubernetes 专栏收录该内容

10 篇文章

订阅专栏

Static Pod是直接由节点上的Kubelet管理的，无需经过Kube-apiserver。它们常用于Bootstrap集群或运行需要在每个节点上存在的服务，如kube-proxy、fluentd。尽管DaemonSet通常是更好的选择，但Static Pod在无集群环境或特定场景下仍具优势。本文将探讨Static Pod的使用和源码实现，并展示其在初始化Kubernetes集群中的应用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Static pod简介

普通pod

Pod是kubernetes中最基本的工作单元，一个Pod中可以包含一组容器。通常情况，Pod的创建流程如下图所示（以Bare Pod为例）：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Y59mwMSV-1638844346078)(F:/markdown/images/image-20211207094953637.png)]

用户首先是请求Kube-apiserver创建Pod，当Pod被系统接受后，Pod作为一个资源对象被持久化在Etcd中，状态为Pending。控制组件Kube-scheduler通过Kube-apiserver监听到这个未被指定调度节点的Pod后，将会根据一定策略，修改Pod的status字段，标记为这个Pod理应分配到某个节点。而所有节点上的Kubelet也会通过监听Kube-apiserver来发先被调度到本节点Pod，此时Kubelet才真正意义上地根据Pod定义的信息，来在自身节点上启动Pod。

Static pod

跟Kubernetes中其他普通的Pod不一样，Static pod是直接由节点上的Kubelet管理的。只要把Pod的定义声明文件放在Kubelet所在节点的指定路径下，或者某个指定的URL地址，Kubelet就会读取Pod的定义文件，并且启动这个Pod，也会按照定义的配置管理Static pod的生命周期。Static pod的启动可以不需要集群，只节点上有Kubelet和相应容器运行时即可。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fACa3I6U-1638844335676)(F:/markdown/images/image-20211207095103569.png)]

快速使用Static pod示例

Static pod的使用很简单，我们来快速试用一下吧。

Step 1：准备一台服务器作为节点；
Step 2：在节点上安装容器运行时：点我参考；
Step 3：在节点上安装Kubelet：点我参考；

Step 4：手动指定Kubelet启动参数：

kubelet --cgroup-driver=systemd --pod-manifest-path=/etc/kubernetes/manifests/ --fail-swap-on=false --pod-infra-container-image=kubernetes/pause > /tmp/kubelet.log 2>&1

Step 5：观察Pod定义的容器组已被Kubelet正确启动，纳入管理:

 cat > /etc/kubernetes/manifests/pod.yaml <<EOF{   "kind":"Pod",   "apiVersion":"v1",   "metadata":{     "name":"static-pod-demo",     "namespace":"default",     "uid":"114b565b-fbe0-4301-a7bd-89598ce86a7a"   },   "spec":{     "containers":[       {         "name":"nginx-container",         "image":"nginx:latest"       }     ],     "restartPolicy":"Always"   }}EOF

Step 6：停止Static pod，只需要把Pod.yaml文件移出/etc/kubernetes/manifests/目录即可

为什么需要Static pod

Kubernetes官方文档，在介绍Static pod时，特别做了如下的标注说明：

Note: If you are running clustered Kubernetes and are using static Pods to run a Pod on every node, you should probably be using a DaemonSet instead.

也就是说，如果你在使用Static pod来实现kubernetes集群中每个Node的上启动Pod，那么你更应该使用DaemonSet，而不是Static pod。

既然官方文档都推荐使用DaemonSet了，为什么还存在static pod这种机制？

早期的Kubernetes，为了在集群各个节点上启动例如日志采集（fluentd）、网络组件(kube-proxy)等服务，使用了Static pod的机制。后来提出了DaemonSet的概念，于是这些需要在每个节点上都启动的服务，都逐渐被DaemonSet所替代，官方文档也建议优先选用DaemonSet。

Static pod机制一直保留下来，一方面是为了兼容广大开发者采用了Static pod的使用场景；另一方面则是Static pod具有DaemonSet无法替代的特性：不需要Kubernetes集群来直接启动、管理Pod。Static pod最大的特点是无需调用Kube-apiserver即可快速启动Pod，也就是说，不需要一个完整的kubernetes集群，只要安装了kubelet、容器运行时，即可快速地让kubelet来接管你的yaml文件定义的Pod。前面章节也简单介绍了如何快速使用这一特性。Static pod优点是不需要集群，缺点也是相对应的，没有集群层面的管理、调度功能。而Static pod最经典的使用场景，就是用来Bootstrap一个Kubernetes集群。

我们接着先简单分析Static pod机制在kubernetes中的源码实现，再来分析使用Static pod来Bootstrap Kubernetes集群的过程。

tes中的源码实现，再来分析使用Static pod来Bootstrap Kubernetes集群的过程。