什麼是Replication Controller

Replication Controller 保證了在所有時間內，都有特定數量的Pod副本正在執行，如果太多了，Replication Controller就殺死幾個，如果太少了，Replication Controller會新建幾個，和直接建立的pod不同的是，Replication Controller會替換掉那些刪除的或者被終止的pod，不管刪除的原因是什麼（維護阿，更新啊，Replication Controller都不關心）。基於這個理由，我們建議即使是隻建立一個pod，我們也要使用Replication Controller。Replication Controller 就像一個程序管理器，監管著不同node上的多個pod,而不是單單監控一個node上的pod,Replication Controller 會委派本地容器來啟動一些節點上服務（Kubelet ,Docker）。

正如我們在pod的生命週期中討論的，Replication Controller只會對那些RestartPolicy = Always的Pod的生效，（RestartPolicy的預設值就是Always）,Replication Controller 不會去管理那些有不同啟動策略pod

如我們在issue #503討論的，我們希望在將來別的控制器被加入到Kubernete中來管理一些例如負載阿，測試等相關功能

Replication Controller永遠不會自己關閉，但是，我們並不希望Replication Controller成為一個長久存在的服務。服務可能會有多個Pod組成，這些Pod又被多個Replication Controller控制著，我們希望Replication Controller 會在服務的生命週期中被刪除和新建（例如在這些pod中釋出一個更新），對於服務和使用者來說，Replication Controller是通過一種無形的方式來維持著服務的狀態

Replication Controller是如何工作的

Pod template

一個Replication Controller通過模版來建立pod,這個是Replication Controller物件內建的功能，但是我們計劃要將這個功能從Replication Controller剝離開來

與其說Pod的模版是一個多有Pod副本的期望狀態，Pod的模版更像是一個餅乾的模具，一旦從模具中出來之後，餅乾就和餅乾模具美啥關係了，沒有任何關聯。模版的改變甚至是模版的更改對已經存在的pod沒有任何影響，Replication Controller建立的pod可以在之後直接的修改，這對Pod來說是非常重要的，這樣就定製了Pod中的所有容器的期望狀態。這從根本上簡化系統複雜度增加了靈活性，正如下面的這個例子

Replication Controller 建立的的Pod 是可以相互替代和語義上相同的，儘管他們的配置檔案可能會隨著是時間的變化而不一樣，這非常適合無狀態伺服器，但是Replication Controller也可以被用在保持主從的高可用，共享，work-pool類應用程式，這樣的程式應該使用的是動態分配機制，例如etcd lock module和RabbitMQ 的佇列，相對於靜態/一次性的定製的Pod的配置檔案，應該是一種反模式，任何定製化的pod,例如垂直的自動變化資源（cpu,記憶體），應該被其它的線上Controller管理，而不是Replication Controller.

Labels

由Replication Controller監控的Pod的數量是是由一個叫 label selector（標籤選擇器）決定的，label selector在Replication Controller和被控制的pod建立了一個鬆散耦合的關係,與pod相比，pod與他們的定義檔案關係緊密。我們故意的不使用固定長度的陣列來儲存被管理的pod,因為根據我們的經驗，如果那樣作了，會增加管理的複雜度，不論是系統還是客戶

replication controller 需要確認那些從特定模版創建出來的pod擁有label selector所要求的標籤，儘管，它還沒有這麼作，我們需要通過確認replication controllers的label selectors 沒有覆蓋設定來確定僅有一個Replication Controller控制所指定的Pod（這段話有點怪）

記住這個：replication controller自己也可以由標籤，would generally carry the labels their corresponding pods have in common，但是這些標籤並不影響replication controller的行為

Pod會被replication controller刪除，如果修改那些pod的標籤，這個功能可能會被應用在從服務中刪除pod來作測試，資料恢復等。Pod如果是以這種方式被刪除的話，那麼那個pod會被自動的替換（前提是宗的副本數量未修改）

類似的，刪除一個replication controller不會影響它建立的pod,如果向刪除那些它那些控制的pod，需要首先拔replcas的值設定為0（注意，使用者端工具kubectl 提供了一個命令stop,來刪除replication controller以及它控制的pod,但是，這個功能在現在的api中不存在）

Responsibilities of the replication controller（replication controller的責任）

replication controller的任務就是保證預計數量的pod並並保證其可用性，目前，只有那些被終止的Pod是從總數量中排除的，在將來，可讀性以及其它系統資訊可能會被納入統計，我們肯能會增加更多的替代策略，並且我們計劃可以執行其它外部程式可以使使用並實現複雜的替換或者策略

replication controller的任務永遠都只會是單一的。它自身不會進行是否可讀和是否可用的檢測，相比與自動進行縮放和放大，replication controller更傾向與使用外部的自動平衡工具，這些外部工具要作的僅僅是修改replicas的值來實現Pod數量的變化，我們不會增加replication controller的排程策率，也不會讓replication controller來驗證受控的Pod是否符合特定的模版，因為這些都會阻礙自動調整和其它的自動的程序。類似的，完成時限，需求依賴，配置擴充套件，等等都屬於其它的部分。

replication controller的目的是成為一個原始的積木，我們希望在replication controller上層的api或者工具來為使用者提供方便，現在kubectl支援的巨集觀操作比如run,stop,scale,rolling-update就是這個概念的例子，舉例來說，我們可以想象和“天庭”管理著replication controller，auto-scalers, services, scheduling policies, canaries, 等等

常見的使用模式

Rescheduling（重新規劃）

正如我們之前提到的，無論你是有1個或者有1000個pod需要執行，Replication Controller 會確保該數量的pod在執行，甚至在節點（node）失敗或者節點（node）終止的情況下

Scaling（縮放）

Replication Controller讓我們更容易的控制pod的副本的數量，不管我們是手動控制還是通過其它的自動管理的工具，最簡單的：修改replicas的值

Rolling updates（動態更新）

Replication Controller 可以支援動態更新，當我們更新一個服務的時候，它可以允許我們一個一個的替換pod

正如我們在#1353中解釋的，推薦的方法是建立一個新的只有1個pod副本的Replication Controller,然後新的每次+1，舊的每次-1，直到舊的Replication Controller 的值變成0，然後我們就可以刪除舊的了，這樣就可以規避省級過程中出現的未知錯誤了

理論上，動態更新控制器應考慮應用的可用性，並確保足夠的pod製成服務在任何時間都能正常提供服務

兩個 Replication Controller建立的pod至少要由一個不同的標籤，可以是映象的標籤，因為一般映象的更新都會帶來一個新的更新

kubectl是實現動態更新的客戶端

Multiple release tracks多個釋出版本追蹤

除了在程式更新過程中同時執行多個版本的程式外，在更新完成之後的一段時間內或者持續的同時執行多個版本（新舊），通過多國版本的追蹤（版本的追蹤是通過label來實現的）

舉個例子來說：一個服務可能繫結的Pod為tier in (frontend), environment in (prod)，現在我們舊假設我們由10個副本來組成這個tier,現在我們要釋出一個新的版本canary，這個時候，我們就應該設定一個Replication Controller，並且設定replcas的值為9，並且標籤為tier=frontend, environment=prod, track=stable，然後再設定另外一個Replication Controller，並且把replacas的值設定為1標籤為：tier=frontend, environment=prod, track=canary.現在這個服務就同時使用了新版和舊版兩個版本了，這個時候我們舊可以通過不同的Replication Controller進行一些測試，監控…

更多討論：QQ交流群  513817976  入群暗號: kubernetes.org.cn

更多請參考：http://kubernetes.io/docs/user-guide/replication-controller/