同事提出个我从未想过的问题，为什么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 的工作负载资源的示例：
DeploymentStatefulSetDaemonSet
静态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-企业级容器应用托管》-持续胡说八道
第一段：推荐阅读：【云原生新时代弄潮儿k8s凭什么在容器化方面独树一帜？】
第二段：推荐阅读：【趁着同事玩游戏偷偷认识k8s一家子补补课】
第三段：推荐阅读：【Kubernetes家族容器小管家Pod在线答疑❓】
第四段：推荐阅读：【同事提出个我从未想过的问题，为什么Kubernetes要"多此一举"推出静态Pod概念？】
第五段：推荐阅读：【探针配置失误，线上容器应用异常死锁后，kubernetes集群未及时响应自愈重启容器？】
第六段：推荐阅读：【kubernetes集群之Pod说能不能让我体面的消亡呀？】
第七段：推荐阅读：【k8s家族Pod辅助小能手Init容器认知答疑？】
第八段：待更新？推荐休闲阅读：【囧么肥事】
