一、什么是控制器
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
滾動更新：會創建一個新副本的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水平自動縮放
二、控制器實例
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
三、部署一個簡單的 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 就不允許回退了