Kubernetes 教學系列 - Replication Controller 管理 Pods 的應用
上次介紹了Pod的介紹及建立方式，今天這篇文章介紹Replication Controller的建立方式及其功用。
Replication Controller 的功用
根據官方的解釋，Replication Controller 是用來管理特定數量的 Pod 的副本運行狀態，可以想成 Replication Controller 可以來管理一組 Pod 的生命週期，它會去監控目前的 Pod 的數量有沒有達到一定數量，如果沒有會自動啟動新的 Pod，而不需要手動的創建 Pod。
- 每個 Replication Controller 有其各自的設定檔需要撰寫
- 設定檔中可以指定有多少相同的 Pod 要同時運行在 K8S 上
- 當有一個 Pod 出現任何問題而無法成功運行的話，Replication Controller 會自動創建新的 Pod，來保證運行的數量與設定檔上指定總 Pod 數量要一致。而這樣的做法就等於是
Horizontal Pod Autoscaler，為什麼會有需求是要有多個相同的 Pod? 因為這樣的話才能服務更多的 Client 啊！！因為一個 Pod 的資源面對高流量是無法滿足的。因此這樣的方式就是屬於橫向擴展。
如何建立 Replication Controller
拿上次的 web-app 範例來示範如何寫 Replication Controller 設定檔：
1 | apiVersion: v1 |
- kind：資源需要撰寫為 ReplicationController
- spec.replicas：這個代表同時要運行 pod 的數量
- spec.selector：這裡面定義的是負責抓取當 pod 的 label 是 app: web-app-pod 才會歸類由這個 Replication Controller 所管轄的。
- spec.template：從這邊會開始定義建立 Pod 的 Template，沒錯！也就是說透過撰寫這個設定檔，我們就不需要再去撰寫 Pod 的設定檔，透過這個設定檔就可以一併建立 Replication Controller 以及符合條件的 Pod。這也就是因為為什麼
labels要定義 app: web-app-pod，因為如果與上方的selector不一致的話在建立 Replication Controller 會出現錯誤，導致建立失敗。但如果沒有指定 selector 的話，建立的時候會默認為與 Pod 的 labels 相同，所以可以建立成功。
接著就可以來建立看看：
1 | kubectl create -f rc.yaml |
使用 kubectl get rc 來取得運行中的 Replication Controller 來看是否有成功建立：
1 | NAME DESIRED CURRENT READY AGE |
- DESIRED：代表設定檔我們設定 replicas 的數目
- CURRENT：代表目前啟動 Pod 的數目
所以理論上這兩個數值是需要一致的。但但可以看到後面的 READY 目前為一，這是因為建立 Container 是需要花費一點時間的，所以在重新執行該指令就會發現 READY 變成 3 了。
這時我們取得 Pod 的資料來看是否有成功建立 3 個 Pod：
1 | kubectl get pods |
1 | NAME READY STATUS RESTARTS AGE |
這邊可以發現成功建立 3 個 Pod，並且名字是由 Replication Controller 名字為 Prefix 後面加上隨機的字母組合而成的。從這邊也可以很清楚這些 Pod 是歸某 Replication Controller 所管轄的。
測試刪除 Pod 帶來的影響
透過 kubectl delete pod 來隨機指定刪除一個 Pod，來看 Replication Controller 是否會偵測到少了一個 Pod 並且自動建立一個新 Pod 出來。
1 | kubectl delete pod web-app-replication-controller-gwghs |
接著馬上取得所有 Pods 資料：
1 | kubectl get pods |
你會發現出現以下的狀況：
1 | NAME READY STATUS RESTARTS AGE |
web-app-replication-controller-gwghs正在 Terminating，意思就是正在停止該 Pod 運作，而新的 Podweb-app-replication-controller-m5flz正在建立 Container，因此從這邊可以知道 Replication Controller 正在作用。
利用指令來擴展 replicas 的數量
可以透過 kubectl scale 來自動增加 Replication Controller 定義的 replicas 數量。
例如：
1 | kubectl scale --replicas=4 rc/web-app-replication-controller |
透過 --replicas 參數及後面指定是針對哪個現在正在運行的 Replication Controller。
1 | NAME READY STATUS RESTARTS AGE |
Pod 數目順利新增為 4 個了。
刪除 Replication Controller 帶來的影響
當如果刪除 Replication Controller 之後會一併將其管轄的 Pod 一併刪除掉。
執行指令為 kubectl delete rc web-app-replication-controller。
如果只想要刪除 Replication Controller 可以運行以下的指令：
kubectl delete rc web-app-replication-controller --cascade=false
其實就是多加一個參數，來代表是不是要連動，預設會是 true。
從 Replication Controller 中隔離 Pod
如果對一個 Pod 更改 label 的話，會促使這個 Pod 脫離原本 Replication Controller 的管控。而 Replication Controller 也會自動新增一個 Pod 來進行遞補，反之如果將原本的 Pod label 又再度改回來，那麼又會重回 Replication Controller 的管轄，而原本的 Pod 也會自動減少一個。
這樣的好處是透過改變 Pod 的 label 獨立出來進行 Debug 或是進行一些數據的恢復等操作。
如下操作：
改變 label：
1 | kubectl label web-app-replication-controller-gqdvx app=test --overwrite=true |
1 | web-app-replication-controller-92xcp 0/1 ContainerCreating 0 3s |
又改回來：
1 | kubectl label pods web-app-replication-controller-gqdvx app=web-app-pod --overwrite=true |
1 | web-app-replication-controller-92xcp 0/1 Terminating 0 40s |
Replication Controller 的優缺點
優點
- 自動管理 Pod 的新增刪除
- 提供水平擴充 Pod 的方式來增加服務量
缺點
- 滾動更新不方便，因為在實務上常常會需要 rollout 以及 rollback 的情形，如果只使用 Replication Controller 需要做很多手動的方式，比較多的方式是要透過 label 的設計來達到這樣的效果。
總結
而其實現在 K8S 官方也推薦用 Deployment 來取得 Replication Controller 的效果，事實上 Deployment 裡面運用的是 ReplicaSet，這個可以說是強化版的 Replication Controller，支持更強大的 label selector 的功能，而 Deployment 透過 Replication Set 實現更高級別的操作，來實現滾動更新的功能。
因此下篇文章會講講 ReplicationSet 與 Deployment 的使用方式。
最後最後！請聽我一言！
如果你還沒有註冊 Like Coin，你可以透過我的邀請註冊連結來免費註冊，註冊完後就可以在文章最下方幫我按下 Like 按鈕，而 Like 最多可以點五次，如此一來你不用付出任何一塊錢，就能給我寫這篇文章最大的回饋！