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 解决方式

在真实的生产环境中还存在如下所述的特殊需求：

2.4 其它

与单独的Pod实例不同，由RC、ReplicaSet、Deployment、DaemonSet等控制器创建的Pod副本实例都是归属于这些控制器的，这就产生了一个问题：控制器被删除后，归属于控制器的Pod副本该何去何从？

03 文末

本文主要讲解了Pod调度控制器分类、副本解决方案从RC到Deployment（主要是ReplicaSet）的发展以及pod调度产生问题的解决等，希望能帮助到大家，谢谢大家的阅读，本文完！