有一种Pod它不由ApiService管理。运行在固定的Node上，由kubelet创建。我们把它叫做Static Pod（静态Pod）

简单清晰、手把手带你搭建k8s学习环境

默认情况下，Pod的调度完全由Master节点的Scheduler组件经过一系列的算法计算得出的，这个过程是不能人工干预的。但是实际情况中我们的业务非常复杂，可能需要自己控制Pod到达某个节点，于是k8s也给我们提供了一些更加细粒度的调度策略设置。如NodeSelector,NodeAffinity,PodAffinity,污点和容忍等。

前面我们一直介绍的是直接创建Pod，但是在生产环境中基本很少让K8s直接创建Pod，因为这种方式创建出来的Pod删除就没有了，也不会重建。我们希望Pod资源出现故障的时候能够尝试着重启或者创建出新的Pod，扩缩容能够更加方便，更新升级能够更加合理，这个时候就需要用到Pod的控制器来实现

前面我们讲了Node的亲和性调度，但那只是对于Pod与Node之间关系能够更加容易的表达，但是实际的生产环境中对于Pod的调度还有一些特殊的需求，比如Pod之间存在相互依赖关系，调用频繁，对于这一类的Pod我们希望它们尽量部署在同一个机房，甚至同一个节点上，相反，两个毫无关系的Pod并且有可能存在一些竞争，会影响到该节点上其它的Pod，我们希望这些Pod尽量远离，所以K8s 1.4之后就引入了Po

Pod的探测用于检测容器中的应用实例是否可以正常的工作。如果不能正常工作应该去重启，或者不将流量引入该实例。K8s给我们提供了三种探测方式

前面介绍了定向调度，虽然很方便，但是也存在一些问题，不够灵活并且是硬限制，如果Node节点不存在，那么该Pod就运行不了，所以使用场景还是有所限制。

在1.8版本之前，当集群资源不足时又有新的Pod创建请求，那么这个Pod会一直处于Pending状态，就算是这个Pod非常的重要，非部署不可，那也没办法，你只能删除一些Pod释放一些资源才能被调度成功。为了解决该问题，在1.8版本就引入了优先级抢占调度策略，如果新调度的优先级非常高，那么集群会尝试释放优先级低的Pod以保证新的Pod可以正常调度，这种方式称为抢占式调度，1.11版本升级为Beta版

ConfigMap也是k8s中的一大资源对象，它以键值对的方式预先定义好配置存储，在Pod中就可以使用ConfigMap获取配置到环境变量中，当然它也可以是一个配置文件，通过挂载的方式动态挂载到Pod目录中，实现配置与容器的分离

前面介绍了节点亲和性调度，它可以使得我们的Pod调度到指定的Node节点上，而污点（Taints）与之相反，它可以让Node拒绝Pod的运行，甚至驱逐已经在该Node上运行的Pod