一、概念
1、概述
一个容器平台的主要功能就是为容器分配运行时所需要的计算，存储和网络资源。容器调 度系统负责选择在最合适的主机上启动容器，并且将它们关联起来。它必须能够自动的处 理容器故障并且能够在更多的主机上自动启动更多的容器来应对更多的应用访问。 目前三大主流的容器平台 Swarm, Mesos 和 Kubernetes 具有不同的容器调度系统。
1.Swarm 的特点是直接调度 Docker 容器，并且提供和标准 Docker API 一致的 API。
2.Mesos 针对不同的运行框架采用相对独立的调度系统，其中 Marathon 框架提供了 Docker 容器的原生支持。
3.Kubernetes 则采用了 Pod 和 Label 这样的概念把容器组合成一个个的互相存在依赖关系 的逻辑单元。相关容器被组合成 Pod 后被共同部署和调度，形成服务（Service）。
这个是 Kubernetes 和 Swarm，Mesos 的主要区别。
相对来说，Kubernetes 采用这样的方式简化了集群范围内相关容器被共同调度管理的复杂 性。换一种角度来看，Kubernetes 采用这种方式能够相对容易的支持更强大，更复杂的容 器调度算法。
2、k8s 调度工作方式
Kubernetes 调度器作为集群的大脑，在如何提高集群的资源利用率、保证集群中服务的稳 定运行中也会变得越来越重要
Kubernetes 的资源分为两种属性。
1.可压缩资源（例如 CPU 循环，Disk I/O 带宽）都是可以被限制和被回收的，对于一个 Pod 来说可以降低这些资源的使用量而不去杀掉 Pod。
2.不可压缩资源（例如内存、硬盘空间）一般来说不杀掉 Pod 就没法回收。未来 Kubernetes 会加入更多资源，如网络带宽，存储 IOPS 的支持。
3、k8s 调度器
（1）kube-scheduler 是 kubernetes 系统的核心组件之一，主要负责整个集群资源的调 度功能，根据特定的调度算法和策略，将 Pod 调度到最优的工作节点上面去，从而更加合 理、更加充分的利用集群的资源，这也是选择使用 kubernetes 一个非常重要的理由。如 果一门新的技术不能帮助企业节约成本、提供效率，我相信是很难推进的。
（2）调度流程 默认情况下，kube-scheduler 提供的默认调度器能够满足我们绝大多数的要求，之前接触 的示例也基本上用的默认的策略，都可以保证我们的 Pod 可以被分配到资源充足的节点上 运行。但是在实际的线上项目中，可能我们自己会比 kubernetes 更加了解我们自己的应 用，比如我们希望一个 Pod 只能运行在特定的几个节点上，或者这几个节点只能用来运行 特定类型的应用，这就需要我们的调度器能够可控。
kube-scheduler 是 kubernetes 的调度器，它的主要作用就是根据特定的调度算法和调度 策略将 Pod 调度到合适的 Node 节点上去，是一个独立的二进制程序，启动之后会一直监 听 API Server，获取到 PodSpec.NodeName 为空的 Pod，对每个 Pod 都会创建一个 binding。
二、Pod创建流程
三、节点调度亲和性
节点亲和性规则：硬亲和性 required 、软亲和性 preferred。
硬亲和性规则不满足时，Pod 会置于 Pending 状态，软亲和性规则不满足时，会选择一个 不匹配的节点。当节点标签改变而不再符合此节点亲和性规则时，不会将 Pod 从该节点移 出，仅对新建的 Pod 对象生效
（1）节点硬亲和性
requiredDuringSchedulingIgnoredDuringExecution
方式一：Pod 使用 spec.nodeSelector (基于等值关系)
方式二：Pod 使用 spec.affinity 支持 matchExpressions 属性 (复杂标签选择机制)
（2）节点软亲和性
preferredDuringSchedulingIgnoredDuringExecution
柔性控制逻辑，当条件不满足时，能接受被编排于其他不符合条件的节点之上 权重 weight 定义优先级，1-100 值越大优先级越高
（3）总结
四、Pod 资源亲和调度
Pod 对象间亲和性，将一些 Pod 对象组织在相近的位置(同一节点、机架、区域、地区)
Pod 对象间反亲和性，将一些 Pod 在运行位置上隔开
（1）Pod 硬亲和调度
requiredDuringSchedulingIgnoredDuringExecution
Pod 亲和性描述一个 Pod 与具有某特征的现存 Pod 运行位置的依赖关系；即需要事先存在 被依赖的 Pod 对象
（2）Pod 软亲和调度
（3）Pod 反亲和调度
Pod 反亲和调度用于分散同一类应用，调度至不同的区域、机架或节点等 将 spec.affinity.podAffinity 替换为 spec.affinity.podAntiAffinity
反亲和调度也分为柔性约束和强制约束
（4）总结
五、pod污点和容忍度
污点 taints 是定义在节点上的键值型属性数据，用于让节点拒绝将 Pod 调度运行于其上，
除非 Pod 有接纳节点污点的容忍度容忍度 tolerations 是定义在 Pod 上的键值属性数据，
用于配置可容忍的污点，且调度器将 Pod 调度至其能容忍该节点污点的节点上或没有污点 的节点上
使用 PodToleratesNodeTaints 预选策略和 TaintTolerationPriority 优选函数完成该机制
nodeSelector 和 nodeaffinity：pod调度到某些节点上，pod属性，调度时候实现
Taint污点：节点不做普通分配调度，是节点属性
场景：专用节点、配置特点硬件节点、基于Taint驱逐
（1）定义污点和容忍度
污点定义于 nodes.spec.taints 容忍度定义于 pods.spec.tolerations
语法： key=value:effect
（2）effect 定义排斥等级：
NoSchedule，不能容忍，但仅影响调度过程，已调度上去的 pod 不受影响，仅对新增加的 pod 生效。（一定不被调度）
PreferNoSchedule，柔性约束，节点现存 Pod 不受影响，如果实在是没有符合的节点，也 可以调度上来（尽量不被调度）
NoExecute，不能调度，当污点变动时，Pod 对象会被驱逐
（3）在 Pod 上定义容忍度时：
等值比较 容忍度与污点在 key、value、effect 三者完全匹配
存在性判断 key、effect 完全匹配，value 使用空值
一个节点可配置多个污点，一个 Pod 也可有多个容忍度
（4）管理节点的污点
同一个键值数据，effect 不同，也属于不同的污点
给节点添加污点：
kubectl taint node [node] key=value:污点值
kubectl taint node node2 node-type=production:NoShedule #举例
查看节点污点：
kubectl get nodes -o go-template={{.spec.taints}}
或
[root@master-node opt]# kubectl describe node master-node |grep Taint
Taints: node-role.kubernetes.io/master:NoSchedule
污点值介绍：
NoSchedule，不能容忍，但仅影响调度过程，已调度上去的 pod 不受影响，仅对新增加的 pod 生效。（一定不被调度）
PreferNoSchedule，柔性约束，节点现存 Pod 不受影响，如果实在是没有符合的节点，也 可以调度上来（尽量不被调度）
NoExecute，不能调度，当污点变动时，Pod 对象会被驱逐
删除节点污点：
kubectl taint node <node-name><key>[:<effect>]-
kubectl patch nodes <node-name> -p '{"spec":{"taints":[]}}'
kubectl taint node kube-node1 node-type=production:NoSchedule
kubectl get nodes kube-node1 -o go-template={{.spec.taints}}
# 删除 key 为 node-type，effect 为 NoSchedule 的污点
kubectl taint node kube-node1 node-type:NoSchedule-
# 删除 key 为 node-type 的所有污点
kubectl taint node kube-node1 node-type-
# 删除所有污点
kubectl patch nodes kube-node1 -p '{"spec":{"taints":[]}}'
（5）污点容忍
