pod调度

简介

        用户是通过 kubectl 根据配置文件，向 APIServer 发送命令，在 Node 节点上面建立 Pod 和 Container。
APIServer 经过 API 调用，权限控制，调用资源和存储资源的过程，实际上还没有真正开始部署应用。这里    需要 Controller Manager、Scheduler 和 kubelet 的协助才能完成整个部署过程。

        在 Kubernetes 中，所有部署的信息都会写到 etcd 中保存。实际上 etcd 在存储部署信息的时候，会发送 Create 事件给 APIServer，而 APIServer 会通过监听（Watch）etcd 发过来的事件。其他组件也会监听（Watch）APIServer 发出来的事件。

工作流程

        （1）这里有三个 List-Watch，分别是 Controller Manager（运行在 Master），Scheduler（运行在 Master），kubelet（运行在 Node）。 他们在进程已启动就会监听（Watch）APIServer 发出来的事件。

        （2）用户通过 kubectl 或其他 API 客户端提交请求给 APIServer 来建立一个 Pod 对象副本。

        （3）APIServer 尝试着将 Pod 对象的相关元信息存入 etcd 中，待写入操作执行完成，APIServer 即会返回确认信息至客户端。

        （4）当 etcd 接受创建 Pod 信息以后，会发送一个 Create 事件给 APIServer。

        （5）由于 Controller Manager 一直在监听（Watch，通过https的6443端口）APIServer 中的事件。此时 APIServer 接受到了 Create 事件，又会发送给 Controller Manager。

        （6）Controller Manager 在接到 Create 事件以后，调用其中的 Replication Controller 来保证 Node 上面需要创建的副本数量。一旦副本数量少于 RC 中定义的数量，RC 会自动创建副本。总之它是保证副本数量的 Controller（PS：扩容缩容的担当）。

        （7）在 Controller Manager 创建 Pod 副本以后，APIServer 会在 etcd 中记录这个 Pod 的详细信息。例如 Pod 的副本数，Container 的内容是什么。

        （8）同样的 etcd 会将创建 Pod 的信息通过事件发送给 APIServer。

        （9）由于 Scheduler 在监听（Watch）APIServer，并且它在系统中起到了“承上启下”的作用，“承上”是指它负责接收创建的 Pod 事件，为其安排 Node；“启下”是指安置工作完成后，Node 上的 kubelet 进程会接管后继工作，负责 Pod 生命周期中的“下半生”。 换句话说，Scheduler 的作用是将待调度的 Pod 按照调度算法和策略绑定到集群中 Node 上。

        （10）Scheduler 调度完毕以后会更新 Pod 的信息，此时的信息更加丰富了。除了知道 Pod 的副本数量，副本内容。还知道部署到哪个 Node 上面了。并将上面的 Pod 信息更新至 API Server，由 APIServer 更新至 etcd 中，保存起来。

        （11）etcd 将更新成功的事件发送给 APIServer，APIServer 也开始反映此 Pod 对象的调度结果。

        （12）kubelet 是在 Node 上面运行的进程，它也通过 List-Watch 的方式监听（Watch，通过https的6443端口）APIServer 发送的 Pod 更新的事件。kubelet 会尝试在当前节点上调用 Docker 启动容器，并将 Pod 以及容器的结果状态回送至 APIServer。

        （13）APIServer 将 Pod 状态信息存入 etcd 中。在 etcd 确认写入操作成功完成后，APIServer将确认信息发送至相关的 kubelet，事件将通过它被接受。

调度过程

        Sheduler 是作为单独的程序运行的，启动之后会一直监听 APIServer，获取 spec.nodeName 为空的 pod，对每个 pod 都会创建一个 binding，表明该 pod 应该放到哪个节点上。

        调度分为几个部分：首先是过滤掉不满足条件的节点，这个过程称为预算策略（predicate）；然后对通过的节点按照优先级排序，这个是优选策略（priorities）；最后从中选择优先级最高的节点。如果中间任何一步骤有错误，就直接返回错误。

算法

        PodFitsResources：节点上剩余的资源是否大于 pod 请求的资源nodeName，检查节点名称是否和 NodeName 匹配。。
        PodFitsHost：如果 pod 指定了 NodeName，检查节点名称是否和 NodeName 匹配。
        PodFitsHostPorts：节点上已经使用的 port 是否和 pod 申请的 port 冲突。
        PodSelectorMatches：过滤掉和 pod 指定的 label 不匹配的节点。
        NoDiskConflict：已经 mount 的 volume 和 pod 指定的 volume 不冲突，除非它们都是只读。

亲和性

        节点亲和

                pod.spec.nodeAffinity
                ●preferredDuringSchedulingIgnoredDuringExecution：软策略
                ●requiredDuringSchedulingIgnoredDuringExecution：硬策略     

        pod亲和

               pod.spec.affinity.podAffinity/podAntiAffinity
                ●preferredDuringSchedulingIgnoredDuringExecution：软策略
                ●requiredDuringSchedulingIgnoredDuringExecution：硬策略         

        键值运算关系

        ●In：label 的值在某个列表中  pending   
        ●NotIn：label 的值不在某个列表中
        ●Gt：label 的值大于某个值
        ●Lt：label 的值小于某个值
        ●Exists：某个 label 存在
        ●DoesNotExist：某个 label 不存在

污点和容忍

        污点的组成格式如下：
        key=value:effect

        每个污点有一个 key 和 value 作为污点的标签，其中 value 可以为空，effect 描述污点的作用。

        当前 taint effect 支持如下三个选项：
        ●NoSchedule：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上
        ●PreferNoSchedule：表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上               ●NoExecute：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上，同时会将 Node 上已经存在的 Pod 驱逐出去

实验：

        指定调度节点：

        

        查看信息：

        

        硬策略实例：

        

软策略实例：

如果把硬策略和软策略合在一起使用，则要先满足硬策略之后才会满足软策略

Pod亲和性与反亲和性：

        创建一个标签为 app=myapp01 的 Pod

       

        使用 Pod 亲和性调度，创建多个 Pod 资源

        

        

使用 Pod 反亲和性调度

设置污点

查看污点

去除污点

容忍

先为node1设置污点

因为两个pod都有污点所以创建会失败

设置容忍

设置完成后运行成功