一、创建一个Pod的工作流程

Pod创建流程：

1、kubectl 向 APIServer 发起一个 Pod 创建请求。

2、APIServer 接受到 Pod 创建请求后，不是直接创建 Pod，而是将 Pod 的数据写入 etcd 中，待写入操作执行完成，APIServer 将结果返回给 kubectl，此时仅仅是在 etcd 中写入数据，Pod 还没真正创建。

3、Controller-Manager 通过 APIServer 提供的 watch 实时监听 Pod 事件，发现有新的 Pod 要创建，Pod 控制器开始接管并创建 Pod（此时Pod状态属于pending中，即pod创建中或pod创建完成，但未被调度），创建完成后将结果上报给 APIServer。

4、Scheduler 通过 APIServer 提供的 watch 实时监听Pod 事件，发现有新的 Pod 被创建了并且未调度，则开始根据各种调度算法将 Pod 绑定到最合适的工作节点，Pod 绑定完成后将结果上报给 APIServer，APIServer存储绑定数据到etcd。

5、kubelet 通过 APIServer 提供的 watch 实时监听 Pod 事件，发现有新的 Pod 被调度到当前节点，开始调用 cri 接口让容器运行时启动容器。

6、kubelet 创建运行 Pod 完成后，将结果上报给 APIServer,同步到etcd中，至此结束。

注：controller-manager、kubeproxy不参与创建流程，所以上图没有体现。

如果是创建Deployment,controller-manager、kubeproxy就会实际参与了。

这里，controller-manager - 比如repliceSetController,控制副本数量；

Pod中影响调度的主要属性：

schedulerName - 调度器名称，default-scheduler默认调度器；

resources - 资源调度依据(配额)

nodeName - 调度节点名称

nodeSelector - 调度节点标签名称

affinity - 亲和性方式调度

tolerations - 允许调度到含有污点容忍的节点

二、资源限制对Pod调度的影响

如果同一节点上，有10个容器，在部署的时候，不做资源限制，当其中的一个或几个容器突然CPU或内存飙升，可能会占满服务器的资源，导致其他的容器不能再正常提供服务，所以有必要对Pod(容器)做出资源限制。

这里提示，集群中的3个节点都不满足(cpu、内存都不满足)，所以node无法分配,pod处于等待状态（pending）。

查看某个节点的可分配资源信息：

命令：kubectl describe node k8s-node1

这个节点，cpu已经分配出去350m(占总可分配的17%)，内存已经分配出去70Mi（占总可用的1%）

三、节点标签选择器nodeSelector

label指令可以给任何资源打标签：

四、节点亲和性nodeAffintiy

注：weight1-100,权重值越大，越优先使用的概率越大。

五、Taint(污点)与Tolerations(污点容忍)

当node配置有污点，而创建yaml后，node因为污点不能使用时，Pod会一直处于等待状态(Pending)，查看Pod详细信息，可以看到下面内容：

添加污点容忍：

去掉污点：

六、绕过调度器nodeName

设置nodeName,不经过调度器，所谓污点、标签之类的节点选择也就可以忽略，直接部署到对应节点。

这种方式，基本正常上用不到，除非当调度器出现故障时，希望快速将pod分配到指定node上。