Kubernetes Scheduler在整个系统中起到“承上启下”的重要作用，“承上”是指它负责接收Controller Manager创建的新Pod，为其安 排一个落脚的“家”——目标Node；“启下”是指安置工作完成后，目标Node上的kubelet服务进程接管后继工作，负责Pod生命周期中的“下半生”。
1.Scheduler的作用
(1)监听API Server，获取还没有绑定(bind)到Node上的Pod。
(2)根据预选、优先、抢占策略，将Pod调度到合适的Node上。
(3)调用API Server，将调度信息写入到etcd。
2.Scheduler的原则
(1)公平。确保每个Pod都要被调度，即使因为资源不够而无法调用。
(2)资源合理分配。根据多种策略选择合适的Node，并且使资源利用率尽量高。
(3)可自定义。内部支持多种调度策略，用户可以选择亲和性、优先级、污点等控制调度结果，另外也支持自定义Scheduler的方式进行扩展。
Kubernetes Scheduler当前提供的默认调度流程分为以下两步。
(1)预选调度过程。即遍历所有目标Node，筛选出符合要求的候选节点。为此，Kubernetes内置了多种预选策略(xxx Predicates)供用户选择。
(2)确定最优节点。在第一步的基础上，采用优选策略(xxx Priority)计算出每个候选节点的积分，积分最高者胜出。
3.节点管理
在Kubernetes集群中，在每个Node上都会启动一个kubelet服务的进程。该进程用于处理Master下发到本节点的任务，管理Pod及Pod中的容器。每个kubelet进程都会在API Server上注册节点自身的信息，定期向Master汇报节点资源的使用情况，并通过cAdvisor监控容器和节点资源。
节点通过设置kubelet的启动参数“--register-node”，来决定是否向API Server注册自己。如果该参数的值为true，那么kubelet将尝试通过API Server注册自己。
4.Pod管理
kubelet通过以下几种方式获取自身Node上所要运行的Pod清单。
(1)文件。kubelet启动参数“--config”指定的配置文件目录下的文件（默认目录为“/etc/kubernetes/ manifests/”）。通过--file-check- frequency设置检查该文件目录的时间间隔，默认为20秒。
(2)HTTP端点(URL)。通过“--manifest-url”参数设置。通过--http-check-frequency设置检查该HTTP端点数据的时间间隔，默认为20秒。
(3)API Server。kubelet通过API Server监听etcd目录，同步Pod列表。
所有以非API Server方式创建的Pod都称为Static Pod。kubelet将Static Pod的状态汇报给API Server，API Server为该Static Pod创建一个Mirror Pod与其相匹配。Mirror Pod的状态将真实反映Static Pod的状态。当Static Pod被删除时，与之相对应的Mirror Pod也会被删除。
5.容器健康检查
Pod通过以下两类探针来检查容器的健康状态。
(1)一类是LivenessProbe探针。用于判断容器是否健康并反馈给kubelet。如果LivenessProbe探针探测到容器不健康，则kubelet将删除该容器，并根据容器的重启策略进行相应的处理。如果一个容器不包含LivenessProbe探针，那么kubelet认为该容器的LivenessProbe探针返回的值永远是Success。
(2)另一类是ReadinessProbe探针。用于判断容器是否启动完成，且准备接收请求。如果ReadinessProbe探针检测到容器启动失败，则Pod的状态将被修改，Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的IP地址的Endpoint条目。
6.Cadvisor资源监控
Cadvisor的特点如下。
(1)Cadvisor是一个开源的分析容器资源使用率和性能特性的代理工具，它是因容器而生的，因此自然支持Docker容器。
(2)在Kubernetes项目中，Cadvisor被集成到Kubernetes代码中，kubelet则通过Cadvisor获取其所在节点及容器的数据。
(3)Cadvisor自动查找所有在其所在Node上的容器，自动采集CPU、内存、文件系统和网络使用的统计信息。
(4)在大部分Kubernetes集群中，Cadvisor通过它所在Node的4194端口暴露一个简单的UI。
