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

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

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

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

⑩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，事件将通过它被接受。

二、scheduler的调度策略

1、简介

Scheduler 是 kubernetes 的调度器，主要的任务是把定义的 pod 分配到集群的节点上。其主要考虑的问题如下：

①公平：如何保证每个节点都能被分配资源

②资源高效利用：集群所有资源最大化被使用

③效率：调度的性能要好，能够尽快地对大批量的 pod 完成调度工作

④灵活：允许用户根据自己的需求控制调度的逻辑

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

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

2、scheduler预选策略的算法

①PodFitsResources：节点上剩余的资源是否大于 pod 请求的资源nodeName，检查节点名称是否和 NodeName 匹配。

②PodFitsHost：如果 pod 指定了 NodeName，检查节点名称是否和 NodeName 匹配。

③PodFitsHostPorts：节点上已经使用的 port 是否和 pod 申请的 port 冲突。

④PodSelectorMatches：过滤掉和 pod 指定的 label 不匹配的节点。

⑤NoDiskConflict：已经 mount 的 volume 和 pod 指定的 volume 不冲突，除非它们都是只读。

如果在 predicate 过程中没有合适的节点，pod 会一直在 pending 状态，不断重试调度，直到有节点满足条件。经过这个步骤，如果有多个节点满足条件，就继续 priorities 过程：按照优先级大小对节点排序。

3、scheduler的优选策略的算法

①LeastRequestedPriority：通过计算CPU和Memory的使用率来决定权重，使用率越低权重越高。也就是说，这个优先级指标倾向于资源使用比例更低的节点。

②BalancedResourceAllocation：节点上 CPU 和 Memory 使用率越接近，权重越高。这个一般和上面的一起使用，不单独使用。比如 node01 的 CPU 和 Memory 使用率 20:60，node02 的 CPU 和 Memory 使用率 50:50，虽然 node01 的总使用率比 node02 低，但 node02 的 CPU 和 Memory 使用率更接近，从而调度时会优选 node02。

③ImageLocalityPriority：倾向于已经有要使用镜像的节点，镜像总大小值越大，权重越高。

三、k8s中的标签管理及nodeSelector和nodeName的调度方式

1、指定调度节点

pod.spec.nodeName 将 Pod 直接调度到指定的 Node 节点上，会跳过 Scheduler 的调度策略，该匹配规则是强制匹配

 
vim myapp.yaml
apiVersion: apps/v1  
kind: Deployment  
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      nodeName: node01
      containers:
      - name: myapp
        image: soscscs/myapp:v1
        ports:
        - containerPort: 80
		
kubectl apply -f myapp.yaml
 
kubectl get pods -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
myapp-6bc58d7775-6wlpp   1/1     Running   0          14s   10.244.1.25   node01   <none>           <none>
myapp-6bc58d7775-szcvp   1/1     Running   0          14s   10.244.1.26   node01   <none>           <none>
myapp-6bc58d7775-vnxlp   1/1     Running   0          14s   10.244.1.24   node01   <none>           <none>
 
//查看详细事件（发现未经过 scheduler 调度分配）
kubectl describe pod myapp-6bc58d7775-6wlpp
......
 Type    Reason   Age   From             Message
  ----    ------   ----  ----             -------
  Normal  Pulled   95s   kubelet, node01  Container image "soscscs/myapp:v1" already present on machine
  Normal  Created  99s   kubelet, node01  Created container nginx
  Normal  Started  99s   kubelet, node01  Started container nginx