第八章 资源控制器

1、什么是控制器

Kubernetes 中内建了不少 controller（控制器），这些至关于一个状态机，用来控制 Pod 的具体状态和行为

2、控制器类型

①　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

滚动更新：会建立一个新副本的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

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

4、CronJobCron Job

管理基于时间的 Job，即：

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

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

典型的用法以下所示：

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

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

5、StatefulSet

StatefulSet 做为 Controller 为 Pod 提供惟一的标识。它能够保证部署和 scale 的顺序

StatefulSet是为了解决有状态服务的问题（对应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）

6、Horizontal Pod Autoscaling(HPA )

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

2、控制器实例

1、RS 与 RC 与 Deployment 关联RC （ReplicationController ）

主要的做用就是用来确保容器应用的副本数始终保持在用户定义的副本数。即若是有容器异常退出，会自动建立新的Pod来替代；而若是异常多出来的容器也会自动回收

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

查看RS完整模板信息：kubectl explain rs

RS建立模板

apiVersion: extensions/v1beta1 kind: ReplicaSet metadata:   name: frontend spec:   replicas: 3   selector:     matchLabels:       tier: frontend   template:     metadata:       labels:         tier: frontend     spec:       containers:       - name: myapp         image: hub.lqz.com/library/nginx:latest         env:         - name: GET_HOSTS_FROM           value: dns         ports:         - containerPort: 80

 

资源控制器所建立的pod，删除后会被新建

kubectl get pod --show-labels  查看标签

2、RS 与 Deployment 的关联

 

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

①　定义Deployment来建立Pod和ReplicaSet

②　滚动升级和回滚

③　应用扩容和缩容

④　暂停和继续Deployment

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

1、建立

kubectl apply -f deployment.yaml --record

 

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://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record## --record参数能够记录命令，咱们能够很方便的查看每次 revision 的变化

2、扩容

kubectl scale deployment nginx-deployment --replicas 10

3、若是集群支持 horizontal pod autoscaling 的话，还能够为Deployment设置自动扩展

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

4、更新镜像也比较简单

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

 

5、回滚

kubectl rollout undo deployment/nginx-deployment

6、更新 Deployment

6.1假如咱们如今想要让 nginx pod 使用nginx:1.9.1的镜像来代替原来的nginx:1.7.9的镜像

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1deployment "nginx-deployment" image updated

6.2可使用edit命令来编辑 Deployment

$ kubectl edit deployment/nginx-deploymentdeployment "nginx-deployment" edited

6.3查看 rollout 的状态

$ kubectl rollout status deployment/nginx-deployment   Waiting for rollout to finish: 2 out of 3 new replicas have been updated...deployment "nginx-deployment" successfully rolled out

6.4查看历史 RS

 

 6.5 Deployment 更新策略

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

6.6Rollover（多个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 都建立完成后才开始改变航道

6.7回退 Deployment

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

kubectl rollout undo deployment/nginx-deployment --to-revision=2  ## 可使用 --revision参数指定某个历史版本

kubectl rollout pause deployment/nginx-deployment   ## 暂停 deployment 的更新

您能够用kubectl rollout status命令查看 Deployment 是否完成。若是 rollout 成功完成，kubectl rolloutstatus将返回一个0值的 Exit Code

6.8清理 Policy

您能够经过设置.spec.revisonHistoryLimit项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留全部的 revision；若是将该项设置为0，Deployment 就不容许回退了

 

连接：https://www.bilibili.com/video/av66617940/?p=24