K8S的资源控制器

向右看齐 2023-01-10 14:47 167阅读 0赞

## 一、什么是控制器 ##

Kubernetes中内建了很多controller（控制器），这些相当于一个状态机，用来控制Pod的具体状态和行为

## 二、控制器类型 ##

*  ReplicationController 和 ReplicaSet
 *  Deployment
 *  DaemonSet
 *  StateFulSet
 *  Job/CronJob
 *  Horizontal Pod Autoscaling

### 2.1 ReplicationController 和 ReplicaSet ###

ReplicationController（RC）用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而且由于异常多出来的容器也会自动回收；

在新版本的Kubernetes中建议使用ReplicaSet（RS，*命令式定义方法*）来取代ReplicationController。RS与RC没有本质的不同，但是RS支持集合式的selector；

### 2.2 Deployment ###

Deployment为Pod和RS提供了一个声明式定义（declarative）方法，用来替代以前的RC来方便的管理应用。Deployment并不会直接创建Pod，它是通过控制RS来创建Pod的。

#### 2.2.1 典型的应用场景包括： ####

*  定义 Deployment 来创建Pod和ReplicaSet
 *  滚动升级和回滚应用
 *  扩容和缩容
 *  暂停和继续 Deployment

#### 2.2.2 更新策略 ####

Deployment可以保证在升级时只有一定数量的Pod是down的。默认的，它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）

Deployment同时也可以确保只创建出超过期望数量的一定数量的Pod。默认的，它会确保最多比期望的Pod数量多一个的Pod是up状态的（最多超出1个）

未来的K8S版本中，将1-1（更新1个，删除1个）变成25%-25%（更新25%的Pod，删除25%的Pod）

#### 2.2.3 Rollover（多个rollout并行） ####

假设创建了1个有5个nginx:1.7.9 replica的Deployment，但是当只有3个nginx:1.7.9的replica被创建出来的时候，我们就决定开始将nginx的版本更新为1.9.1。在这种情况下，Deployment会立即杀掉已创建的3个nginx:1.7.9的Pod，并开始创建nginx:1.9.1的Pod。它不会等到所有的5个nginx:1.7.9的Pod都创建完成后才开始更新。

#### 2.2.4 回退 Deployment ####

//1. 查看回滚状态
    kubectl rollout status deployment名称（例如：deployment/nginx-deployment）
    //2.查看历史版本
    kubectl rollout history deployment名称（例如：deployment/nginx-deployment）
    //3.回退到指定版本，假设当前版本是3，想要回退到版本1
    kubectl rollout undo deployment名称 --to-revision=1
    //4.暂停操作
    kubectl rollout pause deployment名称
    //5.可以使用 ‘kubectl rollout status’命令查看Deployment是否完成。如果rollout成功完成，‘kubectl rollout status’将返回一个0值的Exit Code
    // 可以使用 ‘echo $?’ 代替 ‘kubectl rollout status’ 命令查看Deployment是否完成
    echo $?

#### 2.2.5 清理策略 ####

可以通过设置`spec.revisionHistoryLimit`项来指定deployment最多保留多少revision历史记录。默认的会保留所有的revision；如果将该项设置为0，Deployment就不会允许回退啦。

**扩展：**

*  命令式编程：它侧重于如何实现程序，就像我们刚接触编程的时候那样，我们需要把程序的实现过程按照逻辑结果一步步写下来
 *  声明式编程：它侧重于定义想要什么，然后告诉计算机/引擎，让它帮助你实现

### 2.3 DaemonSet ###

DaemonSet（守护进程相关）确保全部（或者一些）**Node**上运行**一个Pod**的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。

使用 DaemonSet 的一些典型用法：

*  运行集群存储daemon，例如在每个Node上运行 glusterd、ceph
 *  在每一个Node上运行日志收集daemon，例如fluentd、logstash
 *  在每一个Node上运行监控daemon，例如Prometheus Node Exporter、collectd、Datadog代理、New Relic代理 或者 Ganglia gmond

### 2.4 Job ###

Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束

### 2.5 CronJob ###

CronJob管理基于时间的Job

*  在给定时间点只运行一次
 *  周期性地在给定时间点运行

**使用前提条件：**  
当前使用的Kubernetes集群版本 >= 1.8（对CronJob）。对于先前版本的集群，版本 < 1.8，启动API Server时，通过传递选项`--runtime-config=batch/v2alpha1=true`可以开启 batch/v2alpha1 API\*\*

**典型用法如下所示：**

*  在给定的时间点调度Job运行
 *  创建周期性运行的Job，例如：数据库备份、发送邮件

### 2.6 StatefulSet ###

StatefulSet 作为 Controller 为 Pod提供唯一的标识。它可以保证部署和scale的顺序  
StatefulSet是为了解决有状态服务的问题（对应 Deployment 和 ReplicaSet是为无状态服务而设计），其应用场景包括：

*  稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据。基于PVC来实现
 *  稳定的网络标志，即Pod重新调度后其podname和hostname不变。基于Headless Service（即没有Cluster IP的Service）来实现
 *  有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有的Pod必须都是Running和Ready状态），基于init containers来实现
 *  有序收缩，有序删除（即从N-1 到 0）

### 2.7 Horizontal Pod Autoscaling ###

Horizontal Pod Autoscaling（HPA，Pod水平自动缩放）其实不属于真正的控制器，它是通过**控制其他控制器**实现自己的目标。应用的资源使用率通常都有高峰和低谷的时候，如何削峰填谷，提高集群的整体资源利用率，让service中的Pod个数自动调整，这种场景下就需要使用HPA了。