Kubernetes Pod调度介绍

在Kubernetes平台上，我们很少会直接创建一个Pod，在大多数情况下会通过RC，Deployment，DaemonSet，Job 等控制器完成对一组Pod 副本的创建，调度及生命周期的自动控制任务。

在最早的Kubernetes版本里是没有这么多Pod副本控制器，只有一个Pod 副本控制器RC（Replication Controller ），这个控制器是这样设计实现的：RC独立于控制的Pod，并通过Label 标签这个耦合关联关系控制目标Pod实例的创建和销毁，随着Kubernetes 的发展，RC 也出现了新的继任者—Deployment，用于更加自动地完成Pod副本的部署，版本更新，回滚等功能。

严谨地说，RC 的继任者其实并不是Deployment，而是ReplicaSet，因为ReplicaSet 进一步增强了RC 标签选择器的灵活性。之前RC 的标签选择器只能选择一个标签，而ReplicaSet拥有集合式的标签选择器，可以选择多个Pod 标签，如下所示：

	selector: 
	  matchLabels: 
	    tier: frontend
	  matchExpressions: 
	    - {key: tier,operator: In , values: [frontend]}

与RC不同，ReplicaSet 被设计成能够控制多个不同标签的Pod副本。比如：应用MyApp目前发布了v1与v2两个版本，用户希望MyApp的Pod副本数保持为3个，可以同时包含v1 和 v2 版本的Pod，就可以用ReplicaSet 来实现这种控制，写法如下：

	selector: 
	  matchLabels: 
	    tier: v2
	  matchExpressions: 
	    - {key: tier,operator: In , values: [v1,v2]}

其实，Kubernetes 的滚动升级就是巧妙运用ReplicaSet的这个特性来实现的，同时，Deployment也是通过ReplicaSet来实现Pod副本自动控制功能的。我们不应该直接使用底层的ReplicaSet来控制Pod副本，而应该通过管理ReplicaSet的Deployment对象来控制副本，这是来自官方的建议。

在大多数情况下，我们希望Deployment创建的Pod 副本被成功调度到集群中的任何一个可用节点，而不关心具体会调度到哪个节点。但是，在真实的生产环境中的确也存在一种需求：希望某种Pod 的副本全部在指定的一个或一些节点上运行，比如希望将MySql数据库调度到一个具有SSD磁盘的目标节点上，此时Pod 模版中的NodeSelector属性就开始发挥作用了，上述MySQL 定向调度案例的实现方式可分为以下两步。

（1）把具体SSD 磁盘的Node 都打上自定义标签disk=ssd。
（2）在Pod 模版中设定NodeSelector 的值为“disk:ssd”

如此一来，Kubernetes 在调度Pod 副本的时候，就会先按照Node 的标签过滤出合适的目标节点，然后选择一个最佳节点进行调度。

上述逻辑看起来既简单又完美，但在真实的生产环境中可能面临以下令人尴尬的问题。
（1）如果NodeSelector 选择的Label 不存在或者不符合条件，比如这些目标节点此时宕机或者资源不足，该怎么办？
（2）如果要选择多种合适的目标节点，比如SSD 磁盘的节点或者超高速硬盘的节点，该怎么办？ Kubernetes 引入了NodeAffinity（节点亲和性设置）来解决该需求。

在真实的生产环境还存在如下所述的特色需求。
（1）不同Pod之间的亲和性（Affinity）。比如Mysql 数据库与Redis 中间件不能被调度到同一个目标节点上，或者两种不同的Pod必须被调度到同一个Node 上，以实现本地文件共享或本地网络痛惜等特殊需求，这就是Pod Affinity 要解决的问题。
（2）有状态集群的调度。对于ZooKeeper ,Elasticsearch，MongoDB ，Kafka等有状态集群，虽然集群中的每个Worker 节点看起来都是相同的，但是每个Worker 节点都必须有明确的，不变的唯一ID（主机名或IP地址），这些节点的启动和停止次序通常有严格的顺序。此外，由于集群需要持久化保存状态数据，所以集群中的Worker 节点对应的Pod 不管在哪个Node 上恢复，都需要挂载原来的Volume ，因此这些Pod 还需要捆绑具体的PV，针对这种复杂的需求，Kubernetes 提供了StatefulSet 这种特殊的副本控制器来解决问题，在Kubernetes 1.9 版本发布后，StatefulSet 才可用于正式环境中。
（3）在每个Node 上调度并且仅仅创建一个Pod 副本。这种调度通常用于系统监控相关的Pod，比如主机上的日志采集，主机性能采集等进程需要被部署到集群中的每个节点，并且只能部署一个副本，这就是DaemonSet 这种特殊Pod 副本控制器所解决的问题。
（4）对于批处理作业，需要创建多个Pod 副本来协同工作，当这些Pod 副本都完成自己的任务时，整个批处理作业就结束了，这种Pod 运行且仅运行一次的特殊调度，用常规的RC 或者Deployment 都无法解决，所以Kubernetes 引入了新的Pod调度控制器Job 来解决问题，并继续延伸了定时作业的调度控制器CronJob。

与单独的Pod 实例不同，由RC ,ReplicaSet，Deployment，DaemonSet 等控制器创建的Pod 副本实例都是归属于这些控制器的，这就产生了一个问题：控制器被删除后，归属于控制器的Pod 副本该何去何从？ 在Kubernetes 1.9 之前，在RC 等对象被删除后，它们所创建的Pod 副本都不会被删除；在Kubernetes 1.9 以后，这些Pod 副本会被一并删除。如果不希望这样做，则可以通过kubectl 命令的 --cascade=false参数来取消这一默认特性：

kubectl delete replicaset my-repset --cascade=false