Kubernetes--资源控制器

前言

Pod的分类

自助式pod

只要pod退出了，此类型的pod不会被重建，该pod没有管理者，死亡后不会被拉起。

控制器管理的pod【生产环境中大多数都是选择控制器去管理pod】

在控制器的生命周期里始终要维持pod的副本数目

区别
生命周期被管理的机制不太一致

一、什么是控制器

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

二、控制器类型

①ReplicationController 和 ReplicaSet

②Deployment

③DaemonSet

④StateFulSet

⑤Job/CronJob

⑥Horizontal Pod Autoscaling

1、ReplicationController和ReplicaSet

ReplicationController（RC）用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的 Pod 来替代；而如果异常多出来的容器也会自动回收；
在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationController 。ReplicaSet 跟ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector（标签）

2、Deployment 一般的应用程序可用

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的ReplicationController 来方便的管理应用。典型的应用场景包括；

①定义 Deployment 来创建 Pod 和 ReplicaSet
②滚动升级和回滚应用【Deployment自身具备的特点】
③扩容和缩容【RS就已经实现，Deployment通过RS管理Pod因此也支持】
④暂停和继续 Deployment【Deployment自身具备的特点】

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

滚动更新：会创建一个新副本的rs1，旧的rs的pod减少一个时，rs1会新加一个，直到全部增减完成

回滚：同理，需要恢复旧的rs时，会启动rs，再进行增减操作

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

4、Job 批处理脚本程序可用

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

5、CronJob【本质上是在特定的时间循环创建Job去实现的】批处理脚本程序可用

管理基于时间的 Job，即：

在给定时间点只运行一次
周期性地在给定时间点运行
使用前提条件：当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob）。对于先前版本的集群，版本 <1.8，启动 API Server时，通过传递选项--runtime-config=batch/v2alpha1=true可以开启 batch/v2alpha1API

典型的用法如下所示：

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

6、StatefulSet 有状态服务的应用程序可用

StatefulSet 作为 Controller 为 Pod 提供唯一的标识。它可以保证部署和 scale 的顺序
StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），但到目前为止，MySQL有状态服务部署进K8s并不稳定，其应用场景包括：

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

7、Horizontal Pod Autoscaling【自动扩展，可以理解为它并不是一个控制器，而是一个控制器的附属品，使用HPA去控制其他的控制器从而使其他的控制器具有自动扩展的功能】

应用的资源使用率通常都有高峰和低谷的时候，如何削峰填谷，提高集群的整体资源利用率，让service中的Pod个数自动调整呢？这就有赖于Horizontal Pod Autoscaling了，顾名思义，使Pod水平自动缩放

资源控制器之ReplicationController、ReplicaSet和Deployment

1、ReplicationController和ReplicaSet介绍

RC（ReplicationController）主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数。即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收
Kubernetes官方建议使用RS（Replicaset）替代RC（ReplicationController)进行部署，RS跟RC没有本质的不同，只是名字不一样，并且RS支持集合式的 selector

查看RS完整模板信息：kubectl explain rs
ReplicaSet资源文件示例

apiVersion: extensions/v1beta1
kind: ReplicaSet 
metadata:
  name: frontend 
spec:
  replicas: 3 #有3个副本
  selector: #标签选择器
    matchLabels:
      tier: frontend 
  template: #模板
    metadata:
      1abels:
        tier: frontend 
    spec:
      containers:
      - name: php-redis 
        image: gcr.io/google_samples/gb-frontend:v3 
        env:
        - name: GET_HOSTS_FROM 
          value:dns 
        ports:
        - containerPort: 80

资源控制器所创建的pod，删除后会被新建
kubectl get pod --show-labels 查看标签

2、Deployment介绍

RS 与 Deployment 的关联

Deployment通过RS去创建和管理对应的pod及不同的RS交替去完成滚动更新。　
Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController 来方便的管理应用。典型的应用场景包括：

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

2.1、部署一个简单的 Nginx 应用

apiVersion: extensions/v1beta1 
kind: Deployment 
metadata:
  name: nginx-deployment 
spec:
  replicas: 3 
  template:
    metadata:
      labels:
        app: nginx 
    spec:
      containers:   
      - name: nginx 
        image: nginx:1.7.9 
        ports:
        - containerPort: 80

2.2创建

kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record 
## --record参数可以记录命令，我们可以很方便的查看每次 revision 的变化 更新的时候可以记录状态，每一步是使用什么命令进行更新的

2.3、扩容

kubectl scale deployment nginx-deployment --replicas 10

2.4、如果集群支持horizontal pod autoscaling的话，还可以为Deployment设置自动扩展

kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

2.5、更新容器中的镜像

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

2.6、回滚

kubectl rollout undo deployment/nginx-deployment

2.7、使用edit命令编辑Deployment

kubectl edit deployment/nginx-deployment

2.8、查看rollout的状态

kubectl rollout status deployment/nginx-deployment

2.9、查看历史RS

kubectl get rs

3、Deployment 更新策略【如果我们需要更新时将会创建出两个RS，其中旧的RS一次减少25%的pod而新的RS一次创建25%的pod 】

Deployment 可以保证在升级时只有一定数量的Pod是down的。默认的，它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）
Deployment同时也可以确保只创建出超过期望数量的一定数量的Pod。默认的，它会确保最多比期望的Pod数量多一个的Pod是up的（最多1个surge）
未来的Kuberentes 版本中，将从1-1变成25%-25%

kubectl describe deployments

4、Rollover（多个rollout并行）

假如您创建了一个有5个niginx:1.7.9 replica的 Deployment，但是当还只有3个nginx:1.7.9的 replica 创建出来的时候您就开始更新含有5个nginx:1.9.1 replica 的 Deployment。在这种情况下，Deployment 会立即杀掉已创建的3个nginx:1.7.9的 Pod，并开始创建nginx:1.9.1的 Pod。它不会等到所有的5个nginx:1.7.9的Pod 都创建完成后才开始改变航道

5、回退Deployment

只要Deployment的rollout被触发，就会创建一个revision。也就是说当且仅当Deployment的Pod template(如.spec.template)被更改，例如更新template中的label和容器镜像时，就会创建出一个新的revision。其他的更新，比如扩容Deployment不会创建revision-因此我们可以很方便的手动或者自动扩容。这意味着当您回退到历史revision时，只有Deployment中的Pod template部分才会回退

#设置镜像
kubectl set image deployment/nginx-deployment nginx=nginx:1.91 
#查看当前更新状态
kubectl rollout status deployments nginx-deployment 
kubectl get pods 
#查看可回滚的历史版本
kubectl rollout history deployment/nginx-deployment 
kubectl rollout undo deployment/nginx-deployment
##可以使用--revision参数指定回退到某个历史版本 
kubectl rollout undo deployment/nginx-deployment --to-revision=2  
##暂停 deployment的更新
kubectl rollout pause deployment/nginx-deployment

您可以用kubectl rollout status 命令查看Deployment是否完成。如果 rollout成功完成，kubect1rollout status 将返回一个0值的Exit Code

kubect1 rollout status deploy/nginx
echo $?

6、清理 Policy

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

资源控制器之DaemonSet、Job和CronJob

1、DaemonSet介绍，什么是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

DaemonSet资源文件示例

apiVersion: apps/v1 
kind: DaemonSet 
metadata:
  name: deamonset-example 
  labels: 
    app: daemonset 
spec:
  selector:
    matchLabels:
      name: deamonset-example 
  template:
    metadata:
      1abels: 
        name: deamonset-example 
    spec: 
      containers:
      - name: daemonset-example 
        image: fanqisoft/myapp:v1

Job介绍，什么是Job

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

spec.template格式同Pod
RestartPolicy仅支持Never或OnFailure
单个Pod时，默认Pod成功运行后Job即结束·
spec.completions 标志Job结束需要成功运行的Pod个数，默认为1·
spec.parallelism 标志并行运行的Pod的个数，默认为1
spec.activeDeadlineseconds标志失败Pod的重试最大时间，超过这个时间不会继续重试

Job资源文件示例

apiVersion: batch/v1 
kind: Job 
metadata:
  name:pi 
spec:
  template:
    metadata:
      name:pi 
    spec:
      containers:
      - name: pi 
        image: perl 
      command: ["per1","-Mbignum=bpi","-wle","print bpi(2000)"]
      restartPolicy: Never

CronJob

CronJob管理基于时间的Job，即：

在给定时间点只运行一次
周期性地在给定时间点运行
使用条件：当前使用的Kubernetes 集群，版本>=1.8（对CronJob)
典型的用法如下所示：
在给定的时间点调度Job运行
创建周期性运行的Job，例如：数据库备份、发送邮件

CronJob Spec

spec.template格式同Pod
RestartPolicy仅支持Never或OnFailure
单个Pod时，默认Pod成功运行后Job即结束·
spec.completions标志Job结束需要成功运行的Pod个数，默认为1·
spec.parallelism 标志并行运行的Pod的个数，默认为1
spec.activeDeadlineSeconds 标志失败Pod的重试最大时间，超过这个时间不会继续重试
spec.schedule：调度，必需字段，指定任务运行周期，格式同 Cron·
spec.jobTemplate:Job模板，必需字段，指定需要运行的任务，格式同Job
spec.startingDeadlineSeconds:启动Job的期限（秒级别），该字段是可选的。如果因为任何原因而错过了被调度的时间，那么错过执行时间的Job将被认为是失败的。如果没有指定，则没有期限
spec.concurrencyPolicy:并发策略，该字段也是可选的。它指定了如何处理被 Cron Job创建的Job的并发执行。只允许指定下面策略中的一种：

Allow（默认）：允许并发运行Job

Forbid：禁止并发运行，如果前一个还没有完成，则直接跳过下一个

Replace：取消当前正在运行的Job，用一个新的来替换
注意，当前策略只能应用于同一个CronJob创建的Job。如果存在多个Cron Job，它们创建的Job之间总是允许并发运行。

spec.suspend：挂起，该字段也是可选的。如果设置为true，后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为false。
spec.successfulJobsHistoryLimit和.spec.failed]obsHistoryLimit:历史限制，是可选的字段。它们指定了可以保留多少完成和失败的Job。默认情况下，它们分别设置为3和1。设置限制的值为e，相关类型的Job完成后将不会被保留。

CronJob资源文件示例

apiVersion: batch/v1beta1 
kind: CronJob 
metadata:
  name: he11o 
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox 
            args:
            - /bin/sh 
            - -c 
            - date;echo Hello from the Kubernetes cluster 
          restartPolicy: OnFailure

Cronjob本身的一些限制
创建Job操作应该是幂等的
CronJob并不太好去判断任务是否成功，CronJob通过创建Job去完成任务，Job成功与否可以判断，但CronJob无法链接到Job去获取成功与否，Cron只会定期的去创建Job，仅此而已。

参考：
https://www.cnblogs.com/LiuQizhong/p/11551381.html

https://www.cnblogs.com/fanqisoft/p/11573458.html

https://www.cnblogs.com/fanqisoft/p/11577889.html