大纲
- K8S调度机制介绍
- K8S中的调度策略与算法
- K8S高级调度特性详解
K8S调度机制介绍
Scheduler：为Pod找到一个合适的Node
Kubernetes的Default scheduler
从外部流程看调度器
- 用户通过kubectl命名发起请求。
- apiserver通过对应的kubeconfig进行认证，认证通过后将yaml中的po信息存到etcd。
- Controller-Manager通过apiserver的watch接口发现了pod信息的更新，执行该资源所依赖的拓扑结构整合，整合后将对应的信息交给apiserver，apiserver写到etcd，此时pod已经可以被调度了。
- Scheduler同样通过apiserver的watch接口更新到pod可以被调度，通过算法给pod分配节点，并将pod和对应节点绑定的信息交给apiserver，apiserver写到etcd，然后将pod交给kubelet。
- kubelet收到pod后，调用CNI接口给pod创建pod网络，调用CRI接口去启动容器，调用CSI进行存储卷的挂载。
- 网络，容器，存储创建完成后pod创建完成，等业务进程启动后，pod运行成功。
调度器的内部流程
- 通过NodeLister获取所有节点信息；
- 整合scheduled pods和assume pods，合并到pods，作为所有已调度Pod信息；
- 从pods中整理出node-pods的对应关系表nodeNameToInfo；
- 过滤掉不合适的节点；
- 给剩下的节点依次打分；
- 在分数最高的nodes中随机选择一个节点用于绑定。这是为了避免分数最高的节点被几次调度撞车。
K8S中的调度策略与算法
K8S中的调度策略与算法
通过Predicate策略筛选符合条件的Node
典型Predicate算法
| 算法名称 | 功能 |
| GeneralPredicates | 包含3项基本检查： 节点、端口和规则 |
| NoDiskConflict | 检查Node是否可以满足Pod对硬盘的需求 |
| NoVolumeZoneConflict | 单集群跨AZ部署时，检查node所在的zone是否能满足Pod对硬盘的需求 |
| MaxEBSVolumeCount | 部署在AWS时，检查node是否挂载了太多EBS卷 |
| MaxGCEPDVolumeCount | 部署在GCE时，检查node是否挂载了太多PD卷 |
| PodToleratesNodeTaints | 检查Pod是否能够容忍node上所有的taints |
| CheckNodeMemoryPressure | 当Pod QoS为besteffort时，检查node剩余内存量， 排除内存压力过大的node |
| MatchInterPodAffinity | 检查node是否满足pod的亲和性、反亲和性需求 |
通过Priority策略给剩余的Node评分，挑选最优的节点
典型Priority算法
| 算法名称 | 功能 |
| LeastRequestedPriority | 按node计算资源(CPU/MEM)剩余量排序，挑选最空闲的node |
| BalancedResourceAllocation | 补充LeastRequestedPriority，在cpu和mem的剩余量取平衡 |
| SelectorSpreadPriority | 同一个Service/RC下的Pod尽可能的分散在集群中。 Node上运行的同个Service/RC下的 Pod数目越少，分数越高。 |
| NodeAffinityPriority | 按soft(preferred) NodeAffinity规则匹配情况排序，规则命中越多，分数越高 |
| TaintTolerationPriority | 按pod tolerations与node taints的匹配情况排序，越多的taints不匹配，分数越低 |
| InterPodAffinityPriority | 按soft(preferred) Pod Affinity/Anti-Affinity规则匹配情况排序，规则命中越多，分数越高 /低 |
K8S高级调度特性详解
K8S中的Label与Selector
Node Affinity 让Pod在一组指定的Node上运行
Pod Affinity 让Pod与指定Service的一组Pod在相同Node上运行
Pod Anti-Affinity 让同一个Service的Pod分在到不同Node上运行
Pod Anti-Affinity具有对称性
Taints-tolerations 来自Node的反亲和配置
