同事提出个我从未想过的问题，为什么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？
【同事提出个我从未想过的问题，为什么Kubernetes要"多此一举"推出静态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 来管理各个独立的控制面组件。例如：