第八章 資源控制器

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