Kubernetes（K8S第三部分之资源控制器）

资源控制器

什么是控制器

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

控制器类型

ReplicationController和ReplicaSet

Deployment

DaemonSet

StateFulSet

Job/CronJob

Horizontal Pod Autoscaling

ReplicationController和ReplicaSet

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

在新版本的Kubernetes中建议使用ReplicaSet来取代ReplicationController。ReplicaSet跟ReplicationController没有本质的不同。只是名字不一样。并且ReplicaSet支持集合式的selector；

标签

Deployment

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

定义Deployment来创建Pod和ReplicaSet

滚动升级和回滚应用

扩容和缩容

暂停和继续Deployment

DaemonSet

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

运行集群存储daemon，例如在每个Node上运行glusterd。ceph。

在每个Node上运行日志收集deamon，例如fluentd，logstash

在每个Node上运行监控daemon，例如Prometheus Node，Exporter，coolectd，Datadog代理。

New Relic代理。或Ganglia gmond

滚动更新。回滚操作。

Job

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

CronJob 在特定的时间循环创建Job

Cron Job管理基于时间的Job，即

在给定时间点只运行一次。

周期性地在给定时间点运行。

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

典型的用法如下图。

在给定的时间点调度Job运行

创建周期性运行的Job，例如：数据库备份，发送邮件。

StatefulSet

StatefulSet作为Controller为Pod提供唯一的标识。它可以保证部署和scale的顺序。

StatrfulSet是为了解决有状态服务的问题。（对应Deployments和ReplicaSets是为了无状态服务而设计），其应用场景包括。稳定的持久化存储。即Pod重新调度后环视能访问到相同的持久化数据。基于PVC来实现

稳定的网络标致。即Pod重新调度后其PodName和HostName不变。基于Headless Service（即没有Cluster IP 的Service）来实现

有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行。（即从0到N-1）在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现

有序收缩。有序删除，（即从N-1到0）

Horizontal Pod Autoscaling

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

RS与RC与Deployment关联

RC（ReplicationController）主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数。即如果容器异常退出。会自动创建新的Pod来代替。而如果异常多出来的容器也会自动回收。

Kubernetes官方建议使用RS（ReplicaSet）替代RC（ReplicationController）进行部署。RS跟RC没有本质的不同。只是名字不一样。并且RS支持集合式的selector。

RS与Deployment的关联

Deployment

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

1，定义Deployment来创建Pod和ReplicaSet

2，滚动升级和回滚应用

3，扩容和缩容。

4，暂停和继续Deployment

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

kubectl create -f https://kubernets.io/docs/user-guide/nginx-deployment.yaml --record

--record参数可以记录命令。我们可以很方便的查看每次revision的变化

二。扩容

kubectl scale deployment nginx-deployment --replicas 10

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

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

四。更新镜像也比较简单

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

五。回滚

kubectl rollout undo deployment/nginx-deployment

Deployment更新策略

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

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

未来的Kuberentes版本中，将从1-1变成25%-25%

$kubectl describe deployments

Rollover (多个rollout并行)

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