ReplicationController是一種k8s資源，可以確保它管pod始終保持運行狀態。如果pod因為任何原因消失(例如節點從叢集中消失或由於該pod已從節點中逐出)，ReplicationController會注意到缺少了pod並且建立新的替代。
圖4.1 展示了當一個帶有兩個pod的節點下線會發生什麼事情。由於pod A是被直接建立的，因此是非託管的pod，而pod B是由ReplicationController管理。當節點異常退出叢集後，ReplicationController會建立新的pod(pod B)來替換缺少的pod B，而pod A完全丟失 —— 因為沒有東西負責重建它。
圖4.1 節點故障時，只有ReplicationController管理的pod會被重新建立
ReplicationController會持續監控正在運行的pod清單，並保證對應”類型”的pod數目與期望相符。如果運行的pod太少，ReplicationController會根據pod樣板建立新的副本，如果正在運行的pod太多，則會刪除多餘的副本。你可能會對有多餘的副本感到奇怪，有幾個可能原因：
．有人會手動建立相同”類型”的pod ．有人更改了現有的pod的”類型” ．有人減少了所需的pod的數量，等等
這邊說pod的”類型”，其實這說法不存在，ReplicationController不是根據pod的類型來執行操作，而是根據pod是否匹配某個標籤選擇器。
ReplicationController的工作是確保pod的數量始終保持與其標籤選擇器匹配。如果不匹配，則ReplicationController根據所需，採取適當的操作來調整pod的數量來符合期望數量。如下圖：
圖4.2 一個ReplicationController的協調過程
了解ReplicationController的三個主要部分：
．label selector (標籤選擇器)：用於確定ReplicationController作用範圍中有哪些pod ．replica count (副本個數)：指定應該運行的pod數量 ．pod template (pod樣板)：用於建立新的pod副本
ReplicationController的副本數量、標籤選擇器，甚至是pod樣板都可以隨時修改，但只有副本數量的變更會影響現有的pod。
更改標籤選擇器和pod樣板對現有的pod沒有影響。更改標籤選擇器會使現有的pod脫離ReplicationController的範圍，因此控制器會停止關注它們。 在建立pod後，ReplicationController也不關心其pod的實際”內容” (容器映像、環境變數及其他)。 因此，修改樣板只影響由此ReplicationController建立的新pod。可以將它視為建立新的pod的餅乾切模刀(cookie cutter)。
．確保一個pod(或多個pod副本)持續運行 (當一個pod消失，會建立一個新的) ．叢集節點發生故障時，它將為故障節點上運行的所有受ReplicationController管理的pod在別的節點上建立替代副本 ．它能輕鬆實現pod的水平伸縮 —— 手動或自動都可以
注意 pod實例通常永遠不會重新安置到另一個節點。相反，ReplicationController會建立一個全新的pod實例，新的pod與正在替換的舊的pod無關。
建立 kubia-rc.yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: kubia
spec:
replicas: 3
# 以下紫色的部分可以省略，k8s會從template中取labels直接當作selector標籤
selector:
app: kubia
template:
metadata:
labels:
app: kubia
spec:
containers:
- name: kubia
image: abowspy/kubia
ports:
- containerPort: 8080