01 引言
声明：本文为《Kubernetes权威指南：从Docker到Kubernetes实践全接触（第5版）》的读书笔记
本文主要讲解kubernetes里pod调度的发展及一些基本的概念。
02 Pod调度概述
2.1 Pod调度控制器分类
在Kubernetes平台上，我们很少会直接创建一个Pod，在大多数情况下会通过如下控制器完成对一组Pod副本的创建、调度 及全生命周期的自动控制任务：
- RC
- Deployment
- DaemonSet
- Job等
2.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标签），如下所示：
2.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对象来控制副本，这是来自官方的建议。
2.3 Pod调度
在大多数情况下，我们希望Deployment创建的Pod副本被成功调度到集群中的任何一个可用节点，而不关心具体会调度到哪个节点。
2.3.1 情景
但是，在真实的生产环境中的确也存在一种需求：希望某种Pod的副本全部在指定的一个或者一些节点上运行，比如希望将MySQL数据库调度到一个具有SSD磁盘的目标节点上。
此时Pod模板中的NodeSelector属性就开始发挥作用了，上述MySQL定向调度案例的实现方式可分为以下两步：
- 把具有SSD磁盘的Node都打上自定义标签disk=ssd
- 在Pod模板中设定NodeSelector的值为“disk：ssd”
如此一来，Kubernetes在调度Pod副本的时候，就会先按照Node的标签过滤出合适的目标节点，然后选择一个最佳节点进行调度。
2.3.2 存在的问题
上述逻辑看起来既简单又完美，但在真实的生产环境中可能面临以下令人尴尬的问题：
- 如果
NodeSelector选择的Label不存在或者不符合条件（比如：这些目标节点此时宕机或者资源不足，该怎么办？） - 如果要选择多种合适的目标节点，比如
SSD磁盘的节点或者超高速硬盘的节点，该怎么办？
备注：Kubernetes引入了NodeAffinity（节点亲和性设置）来解决该需求。
2.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 |
2.4 其它
与单独的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）来取消这一默认特性 |
03 文末
本文主要讲解了Pod调度控制器分类、副本解决方案从RC到Deployment（主要是ReplicaSet）的发展以及pod调度产生问题的解决等，希望能帮助到大家，谢谢大家的阅读，本文完！
