k8s教程（11）-pod调度概述

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定向调度案例的实现方式可分为以下两步：

1. 把具有SSD磁盘的Node都打上自定义标签disk=ssd
2. 在Pod模板中设定NodeSelector的值为“disk：ssd”

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

2.3.2 存在的问题

上述逻辑看起来既简单又完美，但在真实的生产环境中可能面临以下令人尴尬的问题：

1. 如果NodeSelector选择的Label不存在或者不符合条件（比如：这些目标节点此时宕机或者资源不足，该怎么办？）
2. 如果要选择多种合适的目标节点，比如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调度产生问题的解决等，希望能帮助到大家，谢谢大家的阅读，本文完！