同事提出个我从未想过的问题，为什么Kubernetes要"多此一举"推出静态Pod概念？

同事提出个我从未想过的问题，为什么Kubernetes要"多此一举"推出静态Pod概念？

我们知道k8s中Pod可以说是一个合格的容器小管家，Pod 被设计成支持多个容器可以一起进行调度，容器之间可以共享资源和依赖、彼此通信、协调何时以及何种方式运行或终止自身。

不知道小伙伴有没有注意到我们小管家的孪生兄弟静态Pod?

为什么k8s会推出静态Pod概念？

囧么肥事胡说八道开课啦

静态 Pod 有什么特殊的地方呢？

正常情况下Pod是在Master上统一管理，指定，分配。所谓静态Pod就是不接受Master的管理，在指定的node上当 kubelet 启动时，会自动启动所有定义的静态Pod。

静态 Pod 直接由特定节点上的 kubelet 进程来管理，不通过 master 节点上的 apiserver 。⽆法与我们常⽤的控制器 Deployment 或者 DaemonSet 进⾏关联，kubelet 直接监控每个Pod，并在故障失效时进行重启自愈。

静态 Pod 始终绑定在某⼀个 kubelet ，并且始终运⾏在同⼀个节点上。

既然发现API不能管理，为什么能“看见”运行的静态Pod？

kubelet会为每个它管理的静态Pod，调用api-server在 Kubernetes 的 apiserver 上创建⼀个镜像 Pod（Mirror Pod）。因此我们可以在 apiserver 中查询到该 Pod，也能通过kubectl等方式进行访问，但是不能通过 apiserver 进⾏控制（例如不能删除）。

普通Pod失败自愈和静态Pod有什么区别？

常规Pod用工作负载资源来创建和管理多个 Pod。 资源的控制器能够处理副本的管理、上线，并在 Pod 失效时提供自愈能力。

本身节点可以尝试重启或者完全替换操作，kubernetes默认的自愈机制是当Pod退出时对Pod进行重启。

如果重启失败，可以重新拉取Pod，实现替身替换：

例如，如果一个节点失败，控制器注意到该节点上的 Pod 已经停止工作， 就可以创建替换性的 替身Pod。调度器会将替身 Pod 调度到一个健康的节点执行。

下面是一些管理一个或者多个 Pod 的工作负载资源的示例：

• Deployment
• StatefulSet
• DaemonSet

静态Pod是指定在特定的节点上运行的Pod，完全交给kubelet进行监督自愈，重启也会在同一个指定的节点上进行重启。静态 Pod 始终绑定在某⼀个 kubelet ，并且始终运⾏在同⼀个节点上。

如果kubectl停止或者删除静态Pod会怎样？

如果尝试删除或者停止，静态Pod会进入Pending状态，并且很快会被kubelet重启。

那如果我非要删除它呢？

kubelet 启动时，由 –Pod-manifest-path= or –manifest-url= 参数指定的⽬录下定义的所有 Pod 都会自动创建。

删除只需要在配置目录下删除对应的 yaml 配置文件。

运行中的 kubelet 会定期扫描配置的目录，并且根据文件中出现或者消失的 Pod配置文件来创建或者删除 Pod。

静态Pod有什么作用？有哪些内置静态Pod？

静态 Pod 通常绑定到某个节点上的 kubelet。 其主要用途是运行自托管的控制面。

因为使用静态Pod可以有效预防通过kubectl、或管理工具操作的误删除，可以利用它来部署一些核心组件应用，保障应用服务总是运行稳定数量和提供稳定服务。

在自托管场景中，使用 kubelet 来管理各个独立的控制面组件。例如：

• 调度组件kube-scheduler
• 秘书组件kube-apiserver
• 核心大脑组件 kube-controller-manager
• 数据仓组件 etcd

---

Kubernetes 推荐学习书

Kubernetes权威指南PDF
链接:https://pan.baidu.com/s/11huL... 提取码:sa88

k8s系列所有问题更新记录：GitHub