1.了解ReplicationController
ReplicationController是一種kubernetes資源，可確定它的pod始終保持運作狀态。 如果pod因任何原因消失（例如節點從叢集中消失或由于該pod己從節點中逐出），則ReplicationController會注意到缺少了pod并建立替代pod。
圖4.1顯示了當一個節點下線且帶有兩個pod時會發生什麼。Pod A是被直接建立的，是以是非托管的pod，而podB由ReplicationController管理。節點異常退出後，ReplicationController會建立一個新的pod(pod B2)來替換缺少的podB,而podA完全丢失——沒有東西負責重建它。
圖中的ReplicationController隻管理一個pod，但一般而言，ReplicationController旨在建立和管理—個pod的多個副本（replicas)。這就是ReplicationController名字的由來。
1.1 ReplicationController的操作
ReplicationController會持續監控正在運作的pod清單，并保證相應“類型”的pod的數目與期望相符。如正在運作的pod太少，它會根據pod模闆建立新的副本。如正在運作的pod太多，它将删除多餘的副本。你可能會對有多餘的副本感到奇怪。這可能有幾個原因：
- 有人會手動建立相同類型的pod。
- 有人更改現有的pod的“類型”。
- 有人減少了所需的pod的數量，等等。
這裡第二個有人更改現有的pod的“類型”是不存在的。ReplicationController不是根據pod類型來執行操作的，而是根據pod是否比對某個标簽選擇器。
介紹控制器的協調流程
ReplicationController的工作是確定pod的數量始終與其标簽選擇器比對。如果不比對，則ReplicationController将根據所需，采取适當的操作來協調pod的數量。圖4.2顯示了ReplicationController的操作。
了解ReplicationController的三部分
—個ReplicationController有三個主要部分（如圖4.3所示）:
- Label selector (标簽選擇器），用于确定ReplicationController作用域中有哪些pod
- replica count(副本個數），指定應運作的pod數量
- pod template(pod模闆），用于建立新的pod副本
ReplicationController的副本個數、标簽選擇器，甚至是pod模闆都可以随時修改，但隻有副本數目的變更會影響現有的pod。
更改控制器的标簽選擇器或pod模闆的效果
更改标簽選擇器和pod模闆對現有pod沒有影響。更改标簽選擇器會使現有的pod脫離ReplicationController的範圍，是以控制器會停止關注它們。在建立pod後，ReplicationController也不關心其pod的實際“内容”（容器鏡像、環境變量及其他）。是以，該模闆僅影響由此ReplicationController建立的新pod。可以将其視為建立新pod 的曲奇切模（cookiecutter)。
使用ReplicationController的好處
像Kubernetes中的許多事物一樣，ReplicationController盡管是一個令人難以置信的簡單概念，卻提供或啟用了以下強大功能：
- 確定一個pod (或多個pod副本）持續運作，方法是在現有pod丢失時啟動一個新pod。
- 叢集節點發生故障時，它将為故障節點上運作的所有pod (即受 ReplicationController控制的節點上的那些pod)建立替代副本。
- 它能輕松實作pod的水準伸縮---手動和自動都可以。
注意: pod執行個體永遠不會重新安置到另一個節點。相反，ReplicationController會建立一個全新的pod執行個體, 它與正在替換的執行個體無關。
1.2 建立一個ReplicationController
現在了解一下如何建立一個ReplicationController,然後看看它如何pod運作。就像pod和其他Kubernetes資源，可以通過上傳JSON或YAML描述檔案到Kubernetes API伺服器來建立ReplicationController。
現在建立一個ReplicationController建立名為kubia-rc.yaml的YAML檔案，如下面的代碼清單所示。
#代碼4.4 ReplicationController的YAML定義: kubia-rc.yaml
apiVersion: v1
kind: ReplicationController #這裡定義ReplicationController（RC）
metadata:
name: kubia #ReplicationController的名字
spec:
replicas: 3 #pod執行個體的目标數目
selector: #pod選擇器決定了RC的操作對象
app: kubia
template: #下面都是建立pod所用的pod模版
metadata:
labels:
app: kubia
spec:
containers:
- name: kubia
image: luksa/kubia
ports:
- containerPort: 8080 上傳檔案到API伺服器時，Kubernetes會建立一個名為kubia的新ReplicationController,它確定符合标簽選擇器app=kubia的pod執行個體始終是三個。當沒有足夠的pod時，根據提供的pod模闆建立新的pod。
模闆中的pod标簽顯然必須和ReplicationController的标簽選擇器比對，否則控制器将無休止地建立新的容器。因為啟動新pod不會使實際的副本數量接近期望的副本數量。為了防止出現這種情況，API服務會校驗ReplicationController的定義，不會接收錯誤配置。
根本不指定選擇器也是一種選擇。在這種情況下，它會自動根據pod模闆中的标簽自動配置。
提示: 定義ReplicationController時不要指定pod選擇器，讓Kubernetes從pod模 闆中提取它。這樣YAML更簡短。
1.3 使用ReplicationController
由于沒有任何pod有app=kubia标簽，ReplicationController會根據pod模闆啟動二個新的pod。列出pod以檢視ReplicationController是否完成了它應該做的事情:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
kubia-53thy 0/1 ContainerCreating 0 2s
kubia-k0xz6 0/1 ContainerCreating 0 2s
kubia-q3vkg 0/1 ContainerCreating 0 它确實建立了三個pod。現在ReplicationController正在管理這三個pod。接下來， 将通過稍稍破壞它們來觀察ReplicationController如何響應。
檢視ReplicationController對已删除的pod的響應
首先，手動删除其中一個pod,以檢視ReplicationController如何立即啟動新容器，進而将比對容器的數量恢複為三：
$ kubectl delete pod kubia-53thy
pod "kubla-53thy" 重新列出pod會顯示四個，因為你删除的pod己終止，并且己建立一個新的pod:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
kubia-53thy 1/1 Terminating 0 3m
kubia-oini2 0/1 ContainerCreating 0 2s
kubia-k0xz6 1/1 Running 0 3m
kubia-q3vkg 1/1 Running 0 ReplicationController再次完成了它的工作。這是非常有用的。
擷取有關ReplicationController的資訊
通過kubectl get指令顯示的關于ReplicationController的資訊:
$ kubectl get rc #rc是ReplicationController的縮寫
NAME DESIRED CURRENT READY AGE
kubia 3 3 2 3m 看到三列顯示了所需的pod數量，實際的pod數量，以及其中有多少pod 己準備就緒可以通過kubectl describe指令看到ReplicationController的附加資訊。
$ kubectl describe rc kubia
Name: kubia
Namespace: default
Selector: app=kubia
Labels: app=kubia
Annotations: <none>
Replicas: 3 current / 3 desired
Pods Status: 4 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=kubia
Containers: ...
Volumes: <none>
Events:
From Type Reason Message
---- ------- ------ -------
replication-controller Normal SuccessfulCreate Created pod: kubia-53thy
replication-controller Normal SuccessfulCreate Created pod: kubia-k0xz6
replication-controller Normal SuccessfulCreate Created pod: kubia-q3vkg
replication-controller Normal SuccessfulCreate Created pod: kubia-oini2 目前的副本數與所需的數量相符，因為控制器己經建立了一個新的pod。它顯示了四個正在運作的pod，因為被終止的pod仍在運作中，盡管它并未計入目前的副本個數中。底部的事件清單顯示了ReplicationCaitroller的行為——它到目前為止建立了四個pod。
控制器如何建立新的pod
控制器通過建立一個新的替代pod來響應pod的删除操作（見圖4.4)。從技術上講，它并沒有對删除本身做出反應，而是針對由此産生的狀态----pod數量不足。
雖然ReplicationCaitroller會立即收到删除pod的通知（API伺服器允許用戶端監聽資源和資源清單的更改），但這不是它建立替代pod的原因。該通知會觸發控制器檢查實際的pod數量并采取适當的措施。
應對節點故障
看着ReplicationController對手動删除pod做出響應沒什麼意思，是以看一個更好的示例。如果用Google Kubernetes Engine來運作這些示例，那麼己經有一個三節點Kubernetes叢集。将從網絡中斷開其中一個節點來模拟節點故障。
注意：如果使用Minikube，則無法做這個練習，因為隻有一個節點同時充當主節點和工作節點。
如果節點在沒有Kubernetes的場景中發生故障，運維人員需要手動将節點上運作的應用程式遷移到其他機器。而現在Kubernetes會自動執行此操作。在ReplicationController檢測到它的pod己關閉後不久，它将啟動新的pod以替換它們。
在實踐中看看這個行為。需要使用gcloud compute ssh指令ssh 進入其中一個節點，然後使用sudo ifconfig eth0 down關閉其網絡接口，如下面的代碼清單所示。
$ gcloud compute ssh gke-kubia-default-pool-b46381f1-zwko
Enter passphrase for key '/home/luksa/.ssh/google_compute_engine':
Welcome to Kubernetes v1.6.4!
...
luksa@gke-kubia-default-pool-b46381f1-zwko ~ $ sudo ifconfig eth0 down 當你關閉網絡接口時，ssh會話将停止響應，是以需要打開另一個終端或強行退出ssh會話。在新終端中，可以列出節點以檢視Kubernetes是否檢測到節點下線。這需要一分鐘左右的時間。然後，該節點的狀态顯示為NotReady:
$ kubectl get node
NAME STATUS AGE
gke-kubia-default-pool-b46381f1-opc5 Ready 5h
gke-kubia-default-pool-b46381f1-s8gj Ready 5h
gke-kubia-default-pool-b46381f1-zwko NotReady 5h #節點與網絡斷開 如果你現在列出pod,那麼仍然會看到三個與之前相同的pod,因為 Kubernetes在重新排程pod之前會等待一段時間（如果節點因臨時網絡故障或Kubelet重新啟動而無法通路）。如果節點在幾分鐘内無法通路，則排程到該節點的pod的狀态将變為Unknown。此時，ReplicationController将立即啟動一個新的pod。可以通過再次列出pod來看到這一點:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
kubia-oini2 1/1 Running 0 10m
kubia-k0xz6 1/1 Running 0 10m
kubia-q3vkg 1/1 Unknown 0 10m #此pod狀态未知，因為其節點無法通路
kubia-dmdck 1/1 Running 0 注意pod的存活時間，你會發現kubia-dmdck pod是新的。你再次擁有三個運作的pod執行個體，這意味着ReplicationController再次開始它的工作，将系統的實際狀态置于所需狀态。
如果一個節點不可用（發生故障或無法通路），會發生同樣的情況。立即進行人為幹預就沒有必要了。系統會自我修複。要恢複節點，需要使用以下指令重置它：
$ gcloud compute instances reset gke-kubia-default-pool-b46381f1-zwko 當節點再次啟動時，其狀态應該傳回到Ready,并且狀态為Unknown的pod将被删除。
1.4 将pod移入或移出ReplicationController的作用域
由ReplicationController建立的pod并不是綁定到ReplicationController。在任何時刻，ReplicationController管理與标簽選擇器比對的pod。通過更改pod的标簽，可以将它從ReplicationController的作用域中添加或删除。它甚至可以從一個ReplicationController移動到另一個。
提示: 盡管一個pod沒有綁定到一個ReplicationController,但該pod在metadata.ownerReferences字段中引用它，可以輕松使用它來找到一個pod屬于哪個ReplicationController。
如果你更改了一個pod的标簽，使它不再與ReplicationController的标簽選擇器相比對，那麼該pod就變得和其他手動建立的pod—樣了。它不再被任何東西管理。如果運作該節點的pod異常終止，它顯然不會被重新排程。但請記住，當你更改pod的标簽時，ReplicationController發現一個pod丢失了，并啟動一個新的pod替換它。
ReplicationController管理具有app=kubia标簽的pod,是以需要删除這個标簽或修改其值以将該pod移出ReplicationController的管理範圍。添加另一個标簽并沒有用，因為ReplicationController不關心該pod是否有任何附加标簽，它隻關心該pod是否具有标簽選擇器中引用的所有标簽。
給ReplicationController管理的pod加标簽
需要确認的是，如果你向ReplicationController管理的pod添加其他标簽，它并不關心：
$ kubectl label pod kubia-dmdck type=special
pod "kubia-dmdck" labeled
$ kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
kubia-oini2 1/1 Running 0 11m app=kubia
kubia-k0xz6 1/1 Running 0 11m app=kubia
kubia-dmdck 1/1 Running 0 給其中一個pod添加了type=special标簽，再次列出所有pod會顯示和以前一樣的三個pod。因為從ReplicationController角度而言，沒發生任何更改。
更改已托管的pod的标簽
現在，更改app=kubia标簽。這将使該pod不再與ReplicationController的标簽選擇器相比對，隻剩下兩個比對的pod。是以，ReplicationController會啟動一個新的pod，将數目恢複為三：
$ kubectl label pod kubia-dmdck app=foo --overwrite
pod "kubia-dmdck" --overwrite參數是必要的，否則kubectl将隻列印出警告，并不會更改标簽。這樣是為了防止你想要添加新标簽時無意中更改現有标簽的值。再次列出所有pod時會顯示四個pod:
$ kubectl get pods -L app
NAME READY STATUS RESTARTS AGE APP
kubia-2qneh 0/1 ContainerCreating 0 2s kubia #建立的pod，用于替換RC範圍中殺出的pod
kubia-oini2 1/1 Running 0 20m kubia
kubia-k0xz6 1/1 Running 0 20m kubia
kubia-dmdck 1/1 Running 0 10m foo #不在由RC管理的pod 現在有四個pod:—個不是ReplicationController管理的，其他三個是。 其中包括建立的pod。
圖4.5說明當更改pod的标簽，使得它們不再與ReplicationController的pod選擇器比對時，發生的事情。可以看到三個pod和ReplicationController。在将pod的标簽從app=kubia更改為app=foo之後，ReplicationController就不管這個pod了。由于控制器的副本個數設定為3,并且隻有兩個pod與标簽選擇器比對，是以ReplicationController啟動kubia_2qneh pod，使總數回到了三。kubia-dmdck pod現在是完全獨立的，并且會一直運作直到手動删除它（現在可以這樣做，因為不再需要它）。
從控制器删除pod
當你想操作特定的pod時，從ReplicationController管理範圍中移除pod的操作 很管用。例如，你可能有一個bug導緻你的pod在特定時間或特定事件後開始出問題。如果你知道某個pod發生了故障，就可以将它從Replication-Controller的管理範圍中移除，讓控制器将它替換為新pod，接着這個pod就任你處置了。完成後删除該pod即可。
更改ReplicationController的标簽選擇器
如果不是更改某個pod的标簽而是修改了ReplicationController的标簽選擇器，你認為會發生什麼？
它會讓所有的pod脫離ReplicationController的管理，導緻它建立三個新的pod.
1.5 修改pod模闆
ReplicationController的pod模闆可以随時修改。更改pod模闆就像用一個曲奇刀替換另一個。它隻會影響你之後切出的曲奇，并且不會影響你已經剪切的曲奇（見圖4.6)。要修改舊的pod,你需要删除它們，并讓ReplicationController根據新模闆将其替換為新的pod。
可以試編輯ReplicationController并向pod模闆添加标簽。使用以下指令編輯ReplicationController:
$ kubectl edit rc kubia 這将在你的預設文本編輯器中打開ReplicationController YAML配置。找到 pod 模闆部分并向中繼資料添加一個新的标簽。儲存更改并退出編輯器後，kubectl将更新ReplicationController并列印以下消息:
replicationcontroller "kubia" 現在可以再次列出pod及其标簽，并确認它們未發生變化。但是如果你删除了這個pod并等待其替代pod建立，你會看到新的标簽。
像這樣編輯一個ReplicationController,來更改容器模闆中的容器圖像，删除現有的容器，并讓它們替換為新模闆中的新容器，可以用于更新pod。
1.6 水準縮放pod
可以看到ReplicationController如何確定持續運作的pod執行個體數量保持不變。 因為改變副本的所需數量非常簡單，是以這也意味着水準縮放pod很簡單。
放大或者縮pod的數量規模就和在ReplicationController資源中更改Replicas字段的值一樣簡單。更改之後，ReplicationController将會看到存在太多的pod并删除其中的一部分（縮容時），或者看到它們數目太少并建立pod(擴容時）。
Replicationcontroller擴容
ReplicationController—直保持三個pod執行個體在運作的狀态。現在要把這個數字提高到10。
$ kubectl scale rc kubia --replicas=10 現在用另一種做法
通過編輯定義來縮放ReplicationController
不使用kubectl scale指令，而是通過以聲明的形式編輯ReplicationConfroller的定義對其進行縮放:
$ kubectl edit rc kubia 當文本編輯器打開時，找到spec.replicas字段并将其值更改為10,如下面的代碼清單所示。
apiVersion： v1
kind: ReplicatinController
metadata:
...
spec:
replicas: 3 #改成10
seelctor:
app: kubia 儲存該檔案并關閉編輯器，ReplicationController會更新并立即将pod數量增加到10:
$ kubectl get rc
NAME DESIRED CURRENT READY AGE
kubia 10 10 4 21m 用kubectl scale指令縮容
現在将副本數目減小到3。可以使用kubectl scale指令：
$ kubectl scale rc kubia --replicas=3 所有這些指令都會修改ReplicationController定義的spec.replicas字段， 就像通過kubectl edit進行更改一樣。
伸縮叢集的聲明式方法
在Kubernetes中水準伸縮pod是陳述式的：“我想要運作x個執行個體。”你不是告訴Kubernetes做什麼或如何去做，隻是指定了期望的狀态。
這種聲明式的方法使得與Kubernetes叢集的互動變得容易。設想一下，如果你必須手動确定目前運作的執行個體數量，然後明确告訴Kubernetes需要再多運作多少個執行個體的話，工作更多且更容易出錯，改變一個簡單的數字要容易得多。
1.7 删除一個 ReplicationController
當你通過kubectl delete删除ReplicationController時，pod也會被删除。但是由于由ReplicationController建立的pod不是ReplicationController的組成部分，隻是由其進行管理，是以可以隻删除ReplicationController并保持pod運作，如圖4.7所示。
當你最初擁有一組由ReplicationController管理的pod,然後決定用ReplicaSet(你 接下來會知道）替換ReplicationController時，這就很有用。可以在不影響pod的情況下執行此操作，并在替換管理它們的ReplicationController時保持pod不中斷運作。
當使用kubectl delete删除ReplicationController時，可以通過給指令增加--cascade=false選項來保持pod的運作。馬上試試看：
$ kubectl delete rc kubia --cascade=false
replicationcontroller "kubia" 己經删除了 ReplicationController，是以這些pod獨立了，它們不再被管理。 但是始終可以使用适當的标簽選擇器建立新的ReplicationController，并再次将它們管理起來。
2.使用ReplicaSet而不是ReplicationController
最初,ReplicationController是用于複制和在異常時重新排程節點的唯一Kubernetes元件,後來又引入了一個名為ReplicaSet的類似資源。它是新一代的 ReplicationController，并且将其完全替換掉（ReplicationController 最終将被棄用）。
本可以通過建立一個ReplicaSet而不是一個ReplicationController來幵始本章， 但是筆者覺得從Kubernetes最初提供的元件幵始是個好主意。另外，你仍然可以看到使用中的ReplicationController，是以你最好知道它們。也就是說從現在起，你應該始終建立ReplicaSet而不是ReplicationController。它們幾乎完全相同，是以你不會碰到任何麻煩。
你通常不會直接建立它們，而是在建立更高層級的Deployment資源時自動建立它們。無論如何，你應該了解ReplicaSet,是以來看看它們與ReplicationController的差別。
2.1 比較 ReplicaSet和Replicationcontroller
ReplicaSet的行為與ReplicationController完全相同，但pod選擇器的表達能力更強。雖然ReplicationController的标簽選擇器隻允許包含某個标簽的比對pod，但ReplicaSet的選擇器還允許比對缺少某個标簽的pod，或包含特定标簽名的pod，不管其值如何。
另外，舉個例子，單個ReplicationController無法将pod與标簽env=production和env=devel同時比對。它隻能比對帶有env=devel标簽的pod或帶有env=production标簽的pod。但是一個ReplicaSet可以比對兩組pod并将它們視為一個大組。
同樣，無論ReplicationController的值如何，ReplicationController都無法僅基于 标簽名的存在來比對pod，而ReplicaSet則可以。例如，ReplicaSet可比對所有包含名為env的标簽的pod,無論ReplicaSet的實際值是什麼（可以了解為env=*)。
2.2 定義ReplicaSet
現在要建立一個ReplicaSet，并看看先前由ReplicationController建立稍後又被抛棄的無主pod，現在如何被ReplicaSet管理。首先，建立一個名為kubia-replicaset.yaml的新檔案将你的ReplicationController改寫為ReplicaSet，其中包含以下代碼清單中的内容。
#代碼4.8 ReplicaSet的YAML定義: kubia-replicaset.yaml
apiVersion: apps/v1beta2 #不是v1版本的一部分，但屬于apps API組的v1beta2版本
kind: ReplicaSet
metadata:
name: kubia
spec:
replicas: 3
selector:
matchLabels: #這裡使用了更簡單matchLabels選擇器，這非常類似于RC的選擇器
app: kubia
template: #該模版與RC中的相同
metadata:
labels:
app: kubia
spec:
containers:
- name: kubia
image: luksa/kubia 首先要注意的是ReplicaSet不是v1 API的一部分，是以需要確定在建立資源時指定正确的apiVersion。你正在建立一個類型為ReplicaSet的資源，它的内容與你之前建立的ReplicationControlier的内容大緻相同。
唯一的差別在選擇器中。不必在selector屬性中直接列出pod需要的标簽,而是在selector.matchLabels下指定它們。這是在RejlicaSet中定義标簽選擇器的更簡單（也更不具表達力）的方式。之後，你會看到表達力更強的選項。
因為你仍然有三個pod比對從最初運作的app=kubia選擇器，是以建立此ReplicaSet不會觸發建立任何新的pod。ReplicaSet将把它現有的三個pod歸為自己的管轄範圍。
2.3 建立和檢查ReplicaSet
使用kubectl create指令根據YAML檔案建立ReplicaSet。之後，可以使用kubectl get和kubectl describe來檢查ReplicaSet:
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
kubia 3 3 3 3s $ kubectl describe rs
Name: kubia
Namespace: default
Selector: app=kubia
Labels: app=kubia
Annotations: <none>
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=kubia
Containers: ...
Volumes: <none>
Events: <none> 如你所見，ReplicaSet與ReplicationController沒有任何差別。顯示有二個與選擇器比對的副本。如果列出所有pod,你會發現它們仍然是你以前的三個pod。ReplicaSet沒有建立任何新的pod。
2.4 使用ReplicaSet的更富表達力的标簽選擇器
ReplicaSet相對于ReplicationController的主要改進是它更具表達力的标簽選擇器。之前我們故意在第一個ReplicaSet示例中，用較簡單的matchLabels選擇器來确認ReplicaSet與ReplicationController沒有差別。現在,将用更強大的 matchExpressions屬性來重寫選擇器，如下面的代碼清單所示。
#代碼4.9 一個matchExpressions選擇器: kubia-replicaset-matchexpressions.yaml
apiVersion: apps/v1beta2
kind: ReplicaSet
metadata:
name: kubia
spec:
replicas: 3
selector:
matchExpressions:
- key: app #此選擇器要求改pod包含名為“app”的标簽
operator: In #标簽的值必須是“kubia”
values:
- kubia
template:
metadata:
labels:
app: kubia
spec:
containers:
- name: kubia
image: luksa/kubia 可以給選擇器添加額外的表達式。如示例，每個表達式都必須包含一個key、 一個operator (運算符），并且可能還有一個values的清單（取決于運算符）。你會看到四個有效的運算符：
- In: Label的值必須與其中一個指定的values比對。
- Notin: Label的值與任何指定的values不比對。
- Exists: pod必須包含一個指定名稱的标簽（值不重要）。使用此運算符時，不應指定values字段。
- DoesNotExist: pod不得包含有指定名稱的标簽。values屬性不得指定。
如果你指定了多個表達式，則所有這些表達式都必須為true才能使選擇器與pod比對。如果同時指定matchLabels和matchExpressions,則所有标簽都必須比對，并且所有表達式必須計算為true以使該pod與選擇器比對。
2.5 ReplicaSet小結
這是對ReplicaSet的快速介紹，将其作為ReplicationController的替代。請記住，始終使用它而不是ReplicationController，但仍可以在其他人的部署中找到ReplicationController。
現在，删除ReplicaSet以清理叢集。可以像删除ReplicationController—樣删除ReplicaSet:
$ kubectl delete rs kubia
replicaset "kubia" 删除ReplicaSet會删除所有的pod。這種情況下是需要列出pod來确認的。
3.總結
1.不應該直接建立pod,因為如果它們被錯誤地删除，它們正在運作的節點異常, 或者它們從節點中被逐出時，它們将不會被重新建立。
2.ReplicationController始終保持所需數量的pod副本正在運作。
3.pod不屬于ReplicationController，如有必要可以在它們之間移動。
4.ReplicationController将從pod模闆建立新的pod。更改模闆對現有的pod沒有影響。
5.ReplicationController應該替換為ReplicaSet和Deployment,它們提供相同的能力，但具有額外的強大功能。
作者：小家電維修
轉世燕還故榻,為你銜來二月的花。