01 概述
1.1 Pod调度控制器分类
在Kubernetes平台上，我们很少会直接创建一个Pod，在大多数情况下会通过如下控制器完成对一组Pod副本的创建、调度 及全生命周期的自动控制任务：
- RC
- Deployment
- DaemonSet
- Job等
1.2 RC到Deployment的发展
在最早的Kubernetes，版本里是没有这么多Pod副本控制器的，只有一个Pod副本控制器RC（Replication Controller），这个控制器是这样设计实现的：
RC独立于所控制的Pod，并通过Label标签这个松耦合关联关系控制目标Pod实例的创建和销毁。
随着Kubernetes的发展，RC也出现了新的继任者-Deployment，用于更加自动地完成Pod副本的部署、版本更新、回滚等功能。
严谨地说，RC的继任者其实并不是Deployment，而是ReplicaSet，因为
ReplicaSet进一步增强了RC标签选择器的灵活性（之前RC的标签选择器只能选择一个标签而ReplicaSet拥有集合式的标签选择器，可以选择多个Pod标签），如下所示：
1.2.1 ReplicaSet
与RC不同，ReplicaSet被设计成能控制多个不同标签的Pod副本
举例： 应用MyApp目前发布了v1与v2两个版本，用户希望MyApp的Pod副本数保持为3个，可以同时包含v1和v2版本的Pod，就可以用ReplicaSet来实现这种控制，写法如下：
其实，Kubernetes的滚动升级就是巧妙运用ReplicaSet的这个特性来实现的， 同时，Deployment也是通过ReplicaSet来实现Pod副本自动控制功能的。
我们不应该直接使用底层的ReplicaSet来控制Pod副本，而应该通过管理ReplicaSet的Deployment对象来控制副本，这是来自官方的建议。
1.3 Pod调度
在大多数情况下，我们希望Deployment创建的Pod副本被成功调度到集群中的任何一个可用节点，而不关心具体会调度到哪个节点。
1.3.1 情景
但是，在真实的生产环境中的确也存在一种需求：希望某种Pod的副本全部在指定的一个或者一些节点上运行，比如希望将MySQL数据库调度到一个具有SSD磁盘的目标节点上。
此时Pod模板中的NodeSelector属性就开始发挥作用了，上述MySQL定向调度案例的实现方式可分为以下两步：
- 把具有SSD磁盘的Node都打上自定义标签disk=ssd
- 在Pod模板中设定NodeSelector的值为“disk：ssd”
如此一来，Kubernetes在调度Pod副本的时候，就会先按照Node的标签过滤出合适的目标节点，然后选择一个最佳节点进行调度。
1.3.2 存在的问题
上述逻辑看起来既简单又完美，但在真实的生产环境中可能面临以下令人尴尬的问题：
- 如果
NodeSelector选择的Label不存在或者不符合条件（比如：这些目标节点此时宕机或者资源不足，该怎么办？） - 如果要选择多种合适的目标节点，比如
SSD磁盘的节点或者超高速硬盘的节点，该怎么办？
备注：Kubernetes引入了NodeAffinity（节点亲和性设置）来解决该需求。
1.3.3 解决方式
在真实的生产环境中还存在如下所述的特殊需求：
| 需求 | 举例描述 | 解决方式 |
不同Pod之间的亲和性(Affinity) |
比如MySQL数据库与Redis中间件 不能被调度到同一个目标节点上，或者两种不同的Pod必须被调度到同一个Node 上，以实现本地文件共享或本地网络通信等特殊需求 | PodAffinity来解决该问题 |
| 有状态集群的调度 | 对于ZooKeeper、Elasticsearch、MongoDB、Kafka等有状态集群，虽然集群中的每个Worker节点看起来都是相同的，但每个Worker节点都必须有明确的、不变的唯一ID（主机名或IP地址)，这些节点的启动和停止次序通常有严格的顺序。此外，由于集群需要持久化保存状态数据所以集群中的Worker节点对应的Pod不管在哪个Node上恢复，都需要挂载原来的Volume，因此这些Pod还需要捆绑具体的PV | 针对这种复杂的需求，Kubernetes 提供了StatefulSet这种特殊的副本控制器来解决问题，在Kubernetes1.9版本发布后，StatefulSet才可用于正式生产环境中 |
| 在每个Node上调度并且仅仅创建一个Pod副本 | 这种调度通常用于系统监控相关的Pod，比如主机上的日志采集、主机性能采集等进程需要被部署到集群中的每个节点，并且只能部署一个副本 | DaemonSet来解决这种特殊Pod副本控制器 |
| 对于批处理作业，需要创建多个Pod副本来协同工作，当这些Pod副本都完成自己的任务时，整个批处理作业就结束了 | 这种Pod运行且仅运行一次的特殊调度，用常规的RC或者Deployment都无法解决 | 引入了新的Pod调度控制器Job来解决问题，并继续延伸了定时作业的调度控制器CronJob |
与单独的Pod实例不同，由RC、ReplicaSet、Deployment、DaemonSet等控制器创建的Pod副本实例都是归属于这些控制器的，这就产生了一个问题：控制器被删除后，归属于控制器的Pod副本该何去何从？
| kubernetes版本 | 操作 |
| 1.9之前 | 在RC等对象被删除后，它们所创建的Pod副本都不会被删除 |
| 1.9以后 | 这些Pod副本会被一并删除。如果不希望这样做，则可以通过kubectl命令的- cascade=false参数（例如：kubectl delete replicaset my-repset --cascade=false）来取消这一默认特性 |
02 全自动调度
2.1 功能
Deployment或RC的主要功能之一就是自动部署一个容器应用的多份副本，以及持续监控副本的数量，在集群内始终维持用户指定的副本数量，。
2.2 举例
举例：使用配置文件可以创建一个ReplicaSet，这个ReplicaSet会创建3个Nginx应用的Pod：
使用create命令创建之后，查看Deployment的状态：
kubectl get deployments
该状态说明
Deployment已创建好所有3个副本,并且所有副本都是最新的可用的。
通过运行kubectl get rs和kubectl get pods可以查看已创建的ReplicaSet (RS)和Pod的信息。
从调度策略上来说，这3个Nginx Pod由系统全自动完成调度。它们各自最终运行在哪个节点上，完全由Master的Scheduler经过一系列算法计算得出，用户无法干预调度过程和结果。
03 定向调度
3.1 Step1- 给Node打上标签
如果要实现定向调度，首先的第一步就是要为Node节点搭上标签（Label），可以使用kubectl label命令：
kubectl label nodes <node-name><label-key>=<label-value> • 1
例如这里为k8s-node-1节点打上一个zone=north标签，表明它是“北方”的一个节点：
3.2 Step2- Pod指定NodeSelector
然后，在Pod的定义中加上nodeSelector的设置，以redis-master- controller.yaml为例:
3.3 Step3- 验证
运行kubectl create -f命令创建Pod，scheduler就会将该Pod调度到拥有 “zone=north” 标签的Node上。
使用kubectl get pods-o wide命令可以验证Pod所在的Node：
需要注意的是，如果我们指定了Pod的nodeSelector条件，且在集群中不存在包含相应标签的Node，则即使在集群中还有其他可供使用的Node，这个Pod也无法被成功调度。
3.4 预定义的标签
除了用户可以自行给Node添加标签，Kubernetes也会给Node预定义一些标签，包括：
- kubernetes.io/hostname；
- beta.kubernetes.io/os（从1.14版本开始更新为稳定版，到1.18版本删除)；
- beta.kubernetes.io/arch（从1.14版本开始更新为稳定版，到1.18版本删除)；
- kubernetes.io/os（从1.14版本开始启用)；
- kubernetes.io/arch(从1.14版本开始启用)。
04 node亲和性调度
4.1 亲和性调度分类
目前有两种节点亲和性表达：
| 表达式 | 含义 |
RequiredDuringSchedulingIgnoredDuringExecution |
必须满足指定的规则才可以调度Pod到Node上（功能与nodeSelector很像，但是使用的是不同的语法)，相当于限制 |
PreferredDuringSchedulingIgnoredDuringExecution |
强调优先满足指定规则，调度器会尝试调度Pod到Node上，但并不强求，相当于软限制 |
多个优先级规则还可以设置权重(weight)值，以定义执行的先后顺序。
IgnoredDuringExecution的意思是：如果一个Pod所在的节点在Pod运行期间 标签发生了变更，不再符合该Pod的节点亲和性需求，则系统将忽略Node上Label 的变化，该Pod能继续在该节点上运行。
4.2 举例
有如下要求：
- requiredDuringSchedulingIgnoredDuringExecution:要求只运行在amd64的节点上(beta.kubernetes.io/arch In amd64)；
- preferredDuringSchedulingIgnoredDuringExecution:要求尽量运行在磁盘类型为ssd(disk-type In ssd)的节点上；
则资源文件的定义如下：
apiVersion:vl kind:Pod metadata: name:with-node-affinity spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms - matchExpressions: - key:beta.kubernetes.io/arch operator:In values: - amd64 preferredDuringSchedulingIgnoredDuringExecution: - weight:1 preference: matchExpressions: - key:disk-type operator:In values: - ssd containers: - name:with-node-affinity image:gcr.io/google containers/pause:2.0
从上面的配置中可以看到In操作符，NodeAffinity语法支持的操作符包括In、NotIn、Exists、DoesNotExist、Gt、Lt。虽然没有节点排斥功能,但是用NotIn 和DoesNotExist就可以实现排斥的功能了。
4.3 注意事项
- 如果同时定义了
nodeSelector和nodeAffinity，那么必须两个条件都得到满足，Pod才能最终运行在指定的Node上； - 如果
nodeAffinity指定了多个nodeSelectorTerms，那么其中一个能匹配成功即可； - 如果在
nodeSelectorTerms中有多个matchExpressions，则一个节点必须满足所有matchExpressions才能运行该Pod。
