?

目錄

1、關于Pod控制器

1.1Pod控制器概述

1.2 控制器與Pod對象

1.3 ReplicaSet控制器

1.3.1? ReplicaSet概述

1.3.2? 創建ReplicaSet

1.3.3 ReplicaSet管控下的Pod對象

1.3.4? 更新ReplicaSet控制器

1.3.5?? 刪除ReplicaSet控制器資源

---

?

1、關于Pod控制器

我們可以把API Server類比成一個存儲對象的數據庫系統，它向客戶端提供了API，并負責存儲由用戶創建的各種資源對象，至于各對象的當前狀態如何才能符合用戶期望的狀態，則需要交由另一類稱為控制器的組件來負責完成。Kubernetes提供了眾多的控制器來管理各種類型的資源，如Node Lifecycle Controller、Namespace Controller、Service Controller和Deployment Controller等，它們的功用幾乎可以做到見名知義。創建完成后，每一個控制器對象都可以通過內部的和解循環 （reconciliation loop），不間斷地監控著由其負責的所有資源并確保其處于或不斷地逼近用戶定義的目標狀態。

盡管能夠由kubelet為其提供自愈能力，但在節點宕機時，自主式Pod對象的重建式自愈機制則需要由Pod控制器對象負責提供，并且由它來負責實現生命周期中的各類自動管理行為，如創建及刪除等。

1.1Pod控制器概述

Master的各組件中，API Server僅負責將資源存儲于etcd中，并將其變動通知給各相關的客戶端程序，如kubelet、kube-scheduler、kube-proxy和kube-controller-manager等，kube-scheduler監控到處于未綁定狀態的Pod對象出現時遂啟動調度器為其挑選適配的工作節點，然而， Kubernetes的核心功能之一還在于要確保各資源對象的當前狀態 （status）以匹配用戶期望的狀態（spec），使當前狀態不斷地向期望狀態“和解”（reconciliation）來完成容器應用管理，而這些則是kube-controller-manager的任務。kube-controller-manager是一個獨立的單體守護進程，然而它包含了眾多功能不同的控制器類型分別用于各類和解任務，如圖5-1所示。

提示 Kubernetes可用的控制器有attachdetach、bootstrapsigner、clusterrole-aggregation、cronjob、csrapproving、 csrcleaner、csrsigning、daemonset、deployment、disruption、endpoint、 garbagecollector、horizontalpodautoscaling、job、namespace、node、 persistentvolume-binder、persistentvolume-expander、podgc、pvc-protection、replicaset、replication- controller、resourcequota、route、service、serviceaccount、serviceaccount-token、statefulset、tokencleaner和ttl等數十種。

創建為具體的控制器對象之后，每個控制器均通過API Server提供的接口持續監控相關資源對象的當前狀態，并在因故障、更新或其他原因導致系統狀態發生變化時，嘗試讓資源的當前狀態向期望狀態遷移和逼近。簡單來說，每個控制器對象運行一個和解循環負責狀態和解，并將目標資源對象的當前狀態寫入到其status字段中。控制器的“和解”循環如圖5-2所示。

List-Watch是Kubernetes實現的核心機制之一，在資源對象的狀態發生變動時，由API Server負責寫入etcd并通過水平觸發（level-triggered）機制主動通知給相關的客戶端程序以確保其不會錯過任何一個事件。控制器通過API Server的watch接口實時監控目標資源對象的變動并執行和解操作，但并不會與其他控制器進行任何交互，甚至彼此之間根本就意識不到對方的存在。

工作負載（workload）一類的控制器資源類型包括ReplicationController、ReplicaSet、Deployment、DaemonSet、 StatefulSet、Job和CronJob等，它們分別代表了一種類型的Pod控制器資源，后面的篇幅主要介紹各控制器的特性及其應用，不過StatefulSet控制器依賴于存儲卷資源，因此它將單獨在存儲卷之后的章節中給予介紹。

?

1.2 控制器與Pod對象

Pod控制器資源通過持續性地監控集群中運行著的Pod資源對象來確保受其管控的資源嚴格符合用戶期望的狀態，例如資源副本的數量要精確符合期望等。通常，一個Pod控制器資源至少應該包含三個基本的組成部分。

• 標簽選擇器：匹配并關聯Pod資源對象，并據此完成受其管控的Pod資源計數。
• 期望的副本數：期望在集群中精確運行著的Pod資源的對象數量。
• Pod模板：用于新建Pod資源對象的Pod模板資源。

注意：DaemonSet用于確保集群中的每個工作節點或符合條件的每個節點上都運行著一個Pod副本，而不是某個精確的數量值，因此不具有上面組成部分中的第二項。

例如，一個如圖5-3所示的Deployment控制器資源使用的標簽選擇器為“role=be-eshop”，它期望相關的Pod資源副本數量精確為3個，少于此數量的缺失部分將由控制器通過Pod模板予以創建，而多出的副本也將由控制器負責終止及刪除。

1.3 ReplicaSet控制器

1.3.1? ReplicaSet概述

ReplicaSet（簡稱RS）是Pod控制器類型的一種實現，用于確保由其管控的Pod對象副本數在任一時刻都能精確滿足期望的數量。如圖5-4所示，ReplicaSet控制器資源啟動后會查找集群中匹配其標簽選擇器的Pod資源對象，當前活動對象的數量與期望的數量不吻合時，多則刪除，少則通過Pod模板創建以補足，等Pod資源副本數量符合期望值后即進入下一輪和解循環。

ReplicaSet的副本數量、標簽選擇器甚至是Pod模板都可以隨時按需進行修改，不過僅改動期望的副本數量會對現存的Pod副本產生直接影響。修改標簽選擇器可能會使得現有的Pod副本的標簽變得不再匹配，此時ReplicaSet控制器要做的不過是不再計入它們而已。另外，在創建完成后，ReplicaSet也不會再關注Pod對象中的實際內容，因此Pod模板的改動也只會對后來新建的Pod副本產生影響。

相比較于手動創建和管理Pod資源來說，ReplicaSet能夠實現以下功能。

• 確保Pod資源對象的數量精確反映期望值：ReplicaSet需要確保由其控制運行的Pod副本數量精確吻合配置中定義的期望值，否則就會自動補足所缺或終止所余。
• 確保Pod健康運行：探測到由其管控的Pod對象因其所在的工作節點故障而不可用時，自動請求由調度器于其他工作節點創建缺失的Pod副本
• 彈性伸縮：業務規模因各種原因時常存在明顯波動，在波峰或波谷期間，可以通過ReplicaSet控制器動態調整相關Pod資源對象的數量。 此外，在必要時還可以通過HPA（HroizontalPodAutoscaler）控制器實現Pod資源規模的自動伸縮。

1.3.2? 創建ReplicaSet

類似于Pod資源，創建ReplicaSet控制器對象同樣可以使用YAML或JSON格式的清單文件定義其配置，而后使用相關的創建命令來完成資源創建。它也由kind、apiVersion、metadata、spec和status這5個一級字段組成，其中status為只讀字段，因此需要在清單文件中配置的僅為前4個字段。它的spec字段一般嵌套使用以下幾個屬性字段。

• replicas<integer>：期望的
• selector<Object>：當前控制器匹配Pod對象副本的標簽選擇器，支持matchLabels和matchExpressions兩種匹配機制。
• template<Object>：用于補足Pod副本數量時使用的Pod模板資源。
• minReadySecond<integer>s：新建的Pod對象，在啟動后的多長時間內如果其容器未發生崩潰等異常情況即被視為“就緒”；默認為0秒，表示一旦就緒性探測成功，即被視作可用。

[root@master ~]# vim replicaSet.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
? name: rs-example
spec:
? replicas: 2
? selector:
???? matchLabels:
?????? app: rs-demo
? template:
??? metadata:
????? labels:
??????? app: rs-demo
??? spec:
????? containers:
????? - name: myapp
??????? image: ikubernetes/myapp:v1
??????? ports:
??????? - name: http
????????? containerPort: 80

[root@master ~]# kubectl apply -f replicaSet.yaml
replicaset.apps/rs-example created

?

集群中當前沒有標簽為“app：rs-demo”的Pod資源存在，因此rs-example需要按照replicas字段的定義創建它們，名稱以其所屬的控制器名稱為前綴。這兩個Pod資源一開始都處于ContainerCreating狀態，即處于 容器創建過程中，待創建過程完成后，其狀態即轉為Running，Pod也將 轉變為“READY”： [root@master ~]# kubectl get pods -l app=rs-demo NAME?????????????? READY?? STATUS??? RESTARTS?? AGE
rs-example-ms4ps?? 1/1???? Running?? 0????????? 113s
rs-example-t6w67?? 1/1???? Running?? 0????????? 113s 接下來可以使用“kubectl get replicaset”命令查看ReplicaSet控制器資源的相關狀態。下面的命令結果顯示出它已經根據清單中配置的Pod模板創建了2個Pod資源，這時它們已創建完成：

[root@master ~]# kubectl get replicaset rs-example -o wide
NAME???????? DESIRED?? CURRENT?? READY?? AGE???? CONTAINERS?? IMAGES???????????????? SELECTOR
rs-example?? 2???????? 2???????? 2?????? 4m59s?? myapp??????? ikubernetes/myapp:v1?? app=rs-demo

• DESIRED：期望有幾個pod
• CURRENT：當前一共有幾個pod
• READY：有幾個pod已經就緒了
• AGE：什么時間創建的

經由控制器創建與用戶自主創建的Pod對象的功能并無二致，但其自動和解的功能在很大程度上能為用戶省去不少的管理精力，這也是使得Kubernetes系統之上的應用程序變得擁有自愈能力的主要保障。

?

1.3.3 ReplicaSet管控下的Pod對象

上面創建的rc-example通過標簽選擇器將擁有“app=rs-demo”標簽的Pod資源收歸于麾下，并確保其數量精確符合所期望的數目，使用標簽選擇器顯示出的Pod資源列表也能驗證這一點。然而，實際中存著不少可能導致Pod對象數目與期望值不符合的可能性，如Pod對象的意外刪除、Pod對象標簽的變動（已有的Pod資源變得不匹配控制器的標簽選擇器，或者外部的Pod資源標簽變得匹配到了控制器的標簽選擇器）、控制器的標簽選擇器變動，甚至是工作節點故障等。ReplicaSet 控制器的和解循環過程能夠實時監控到這類異常，并及時啟動和解操作。

1.缺少Pod副本

任何原因導致的相關Pod對象丟失，都會由ReplicaSet控制器自動補足。例如，手動刪除上面列出的一個Pod對象，命令如下：

[root@master ~]# kubectl delete pods rs-example-ms4ps
pod "rs-example-ms4ps" deleted

再次列出相關Pod對象的信息，可以看到被刪除的rs-example-t6w67進入了終止過程，而新的Pod對象rs-example-zcjmj?正在被rs-example創建 器創建：

[root@master ~]# kubectl get pods -l app=rs-demo -o wide
NAME?????????????? READY?? STATUS??????? RESTARTS?? AGE?? IP??????????? NODE??? NOMINATED NODE?? READINESS GATES
rs-example-cwxgh?? 1/1???? Running?????? 0????????? 3s??? 10.244.1.11?? node1?? <none>?????????? <none>
rs-example-t6w67?? 0/1???? Terminating?? 0????????? 14m?? 10.244.1.10?? node1?? <none>?????????? <none>
rs-example-zcjmj?? 1/1???? Running?????? 0????????? 3m??? 10.244.2.11?? node2?? <none>?????????? <none>??

?另外，強行修改隸屬于控制器rs-example的某Pod資源（匹配于標簽控制器）的標簽，會導致它不再被控制器作為副本計數，這也將觸發控制器的Pod對象副本缺失補足機制。例如，將rs-example-p66nv的標簽app的值置空：

[root@master ~]# kubectl label pods rs-example-cwxgh app=? --overwrite
pod/rs-example-cwxgh labeled 列出rs-example相關Pod對象的信息，發現rs-example-cwxgh已經消失不見，并且正在創建新的對象副本

[root@master ~]# kubectl get pods -l app=rs-demo
NAME?????????????? READY?? STATUS??? RESTARTS?? AGE
rs-example-q494g?? 1/1???? Running?? 0????????? 38s
rs-example-zcjmj?? 1/1???? Running?? 0????????? 7m16s

由此可見，修改Pod資源的標簽即可將其從控制器的管控之下移出，當然，修改后的標簽如果又能被其他控制器資源的標簽選擇器所命 中，則此時它又成了隸屬于另一控制器的副本。如果修改其標簽后的Pod對象不再隸屬于任何控制器，那么它就將成為自主式Pod，與此前手動直接創建的Pod對象的特性相同，即誤刪除或所在的工作節點故障都會造成其永久性的消失。

2.多出Pod副本

一旦被標簽選擇器匹配到的Pod資源數量因任何原因超出期望值，多余的部分都將被控制器自動刪除。例如，為mypod手動為其添 加“app：rs-demo”標簽：

[root@master ~]# kubectl label pods mypod app=rs-demo
pod/mypod labeled

列出rs-example相關Pod對象的信息，發現rs-example-q494g已經消失不見，已創建新的對象副本mypod?

[root@master ~]# kubectl get pods -l app=rs-demo
NAME?????????????? READY?? STATUS??? RESTARTS?? AGE
mypod????????????? 1/1???? Running?? 0????????? 6d23h
rs-example-zcjmj?? 1/1???? Running?? 0????????? 16m

這就意味著，任何自主式的或本隸屬于其他控制器的Pod資源其標簽變動的結果一旦匹配到了其他的副本數足額的控制器，就會導致這類 Pod資源被刪除。

3.查看Pod資源變動的相關事件

“kubectl describe replicasets”命令可打印出ReplicaSet控制器的詳細狀態，從下面命令結果中Events一段也可以看出，rs-example執行了Pod 資源的創建和刪除操作，為的就是確保其數量的精確性。

[root@master ~]# kubectl describe replicasets/rs-example
Name:???????? rs-example
Namespace:??? default
Selector:???? app=rs-demo
Labels:?????? <none>
Annotations:? <none>
Replicas:???? 2 current / 2 desired
Pods Status:? 2 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
? Labels:? app=rs-demo
? Containers:
?? myapp:
??? Image:??????? ikubernetes/myapp:v1
??? Port:???????? 80/TCP
??? Host Port:??? 0/TCP
??? Environment:? <none>
??? Mounts:?????? <none>
? Volumes:??????? <none>
Events:
? Type??? Reason??????????? Age??? From?????????????????? Message
? ----??? ------??????????? ----?? ----?????????????????? -------
? Normal? SuccessfulCreate? 32m??? replicaset-controller? Created pod: rs-example-ms4ps
? Normal? SuccessfulCreate? 32m??? replicaset-controller? Created pod: rs-example-t6w67
? Normal? SuccessfulCreate? 20m??? replicaset-controller? Created pod: rs-example-zcjmj
? Normal? SuccessfulCreate? 17m??? replicaset-controller? Created pod: rs-example-cwxgh
? Normal? SuccessfulCreate? 14m??? replicaset-controller? Created pod: rs-example-q494g
? Normal? SuccessfulDelete? 4m48s? replicaset-controller? Deleted pod: rs-example-q494g

事實上，ReplicaSet控制器能對Pod對象數目的異常及時做出響應，是因為它向API Server注冊監聽（watch）了相關資源及其列表的變動信息，于是API Server會在變動發生時立即通知給相關的監聽客戶端。而因節點自身故障而導致的Pod對象丟失，ReplicaSet控制器一樣會使用補足資源的方式進行處理。
?

1.3.4? 更新ReplicaSet控制器

ReplicaSet控制器的核心組成部分是標簽選擇器、副本數量及Pod模板，但更新操作一般是圍繞replicas和template兩個字段值進行的，畢竟改變標簽選擇器的需求幾乎不存在。改動Pod模板的定義對已經創建完成的活動對象無效，但在用戶逐個手動關閉其舊版本的Pod資源后就能 以新代舊，實現控制器下應用版本的滾動升級。另外，修改副本的數量也就意味著應用規模的擴展（提升期望的副本數量）或收縮（降低期望的副本數量）。這兩種操作也是系統運維人員日常維護工作的重要組成部分。

1.更改Pod模板：升級應用

ReplicaSet控制器的Pod模板可隨時按需修改，但它僅影響這之后由其新建的Pod對象，對已有的副本不會產生作用。大多數情況下，用戶需要改變的通常是模板中的容器鏡像文件及其相關的配置以實現應用的 版本升級。下面的示例清單文件片斷（replicaSet-v2.yaml）中的內容與 之前版本（replicaSet.yaml）的唯一不同之處也僅在于鏡像文件的改動：

?

[root@master ~]# vim replicaSet-v2.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
? name: rs-example
spec:
? replicas: 2
? selector:
???? matchLabels:
?????? app: rs-demo
? template:
??? metadata:
????? labels:
??????? app: rs-demo
??? spec:
????? containers:
????? - name: myapp
??????? image: ikubernetes/myapp:v2
??????? ports:
??????? - name: http
????????? containerPort: 80

對新版本的清單文件執行“kubectl apply”或“kubectl replace”命令即可完成rs-example控制器資源的修改操作：

[root@master ~]# kubectl apply -f replicaSet-v2.yaml
replicaset.apps/rs-example configured

不過，控制器rs-example管控的現存Pod對象使用的仍然是原來版本中定義的鏡像：

[root@master ~]# kubectl get pods -l app=rs-demo -o? custom-columns=Name:metadata.name,Image:spec.containers[0].image
Name?????????????? Image
mypod????????????? ikubernetes/myapp:v1
rs-example-zcjmj?? ikubernetes/myapp:v1

此時，手動刪除控制器現有的Pod對象（或修改與其匹配的控制器標簽選擇器的標簽），并由控制器基于新的Pod模板自動創建出足額的Pod副本，即可完成一次應用的升級。新舊更替的過程支持如下兩類操作方式。

• 一次性刪除控制器相關的所有Pod副本或更改相關的標簽：劇烈更替，可能會導致Pod中的應用短時間不可訪問（如圖所示）；生產實踐中，此種做法不可取。

• 分批次刪除舊有的Pod副本或更改其標簽（待控制器補足后再刪除另一批）：滾動更替，更替期間新舊版本共存（如圖所示）。

例如，這里采用第一種方式進行操作，一次性刪除rs-example相關的所有Pod副本：

[root@master ~]# kubectl delete pods -l app=rs-demo
pod "mypod" deleted
pod "rs-example-zcjmj" deleted

再次列出rc-example控制器相關的Pod及其容器鏡像版本時可以發現，使用新版本鏡像的Pod已經創建完成：

[root@master ~]# kubectl get pods -l app=rs-demo -o? custom-columns=Name:metadata.name,Image:spec.containers[0].image
Name?????????????? Image
rs-example-jdp8k?? ikubernetes/myapp:v2
rs-example-zrm66?? ikubernetes/myapp:v2

必要時，用戶還可以將Pod模板改回舊的版本進行應用的“降級”或“回滾”，它的操作過程與上述過程基本類似。事實上，修改Pod模板時，不僅僅能替換鏡像文件的版本，甚至還可以將其替換成其他正在運行著的、完全不同應用的鏡像，只不過此類需求并不多見。若同時改動的還有Pod模板中的其他字段，那么在新舊更替的過程中，它們也將隨之被應用。 以上操作只為說明應用部署的方式，實際使用時還需要更為完善的機制。即便是僅執行了一到多次刪除操作，手動執行更替操作也并非一項輕松的任務，幸運的是，更高級別的Pod控制器Deployment能夠自動實現更完善的滾動更新和回滾，并為用戶提供自定義更新策略的接口。 而且，經過精心組織的更新操作還可以實現諸如藍綠部署（Blue/Green Deployment）、金絲雀部署（Canary Deployment）和灰度部署等，這些 內容將在后面章節中詳細展開說明。

2.擴容和縮容

改動ReplicaSet控制器對象配置中期望的Pod副本數量（replicas字段）會由控制器實時做出響應，從而實現應用規模的水平伸縮。replicas的修改及應用方式同Pod模板，不過，kubectl還提供了一個專用的子命令scale用于實現應用規模的伸縮，它支持從資源清單文件中獲取新的目 標副本數量，也可以直接在命令行通過“--replicas”選項進行讀取，例如 將rs-example控制器的Pod副本數量提升至5個： [root@master ~]# kubectl scale replicasets rs-example --replicas=5
replicaset.apps/rs-example scaled 由下面顯示的rs-example資源的狀態可以看出，將其Pod資源副本數量擴展至5個的操作已經成功完成：

[root@master ~]# kubectl get replicasets rs-example
NAME???????? DESIRED?? CURRENT?? READY?? AGE
rs-example?? 5???????? 5???????? 5?????? 88m

收縮規模的方式與擴展相同，只需要明確指定目標副本數量即可。 例如： [root@master ~]# kubectl scale replicasets rs-example --replicas=3
replicaset.apps/rs-example scaled 另外，kubectl scale命令還支持在現有Pod副本數量符合指定的值時才執行擴展操作，這僅需要為命令使用“--current-replicas”選項即可。例如，下面的命令表示如果rs-example目前的Pod副本數量為2，就將其擴展至4個：

[root@master ~]# kubectl scale replicasets rs-example --current-replicas=2 --replicas=4
error: Expected replicas to be 2, was 3

但由于rs-example控制器現存的副本數量是3個，因此上面的擴展操作未執行并返回了錯誤提示。 注意 如果ReplicaSet控制器管控的是有狀態的應用，例如主從架構的Redis集群，那么上述這些升級、降級、擴展和收縮的操作都需要精心編排和參與才能進行，不過，這也在一定程度上降低了Kubernetes容器編排的價值和意義。好在，它提供了StatefulSet資源來應對這種需求，因此ReplicaSet通常僅用于管理無狀態的應用，如HTTP服務程序等。

1.3.5?? 刪除ReplicaSet控制器資源

使用kubectl delete命令刪除ReplicaSet對象時默認會一并刪除其管控的各Pod對象。有時，考慮到這些Pod資源未必由其創建，或者即便由其創建卻也并非其自身的組成部分，故而可以為命令使用“-- cascade=false”選項，取消級聯，刪除相關的Pod對象，這在Pod資源后續可能會再次用到時尤有用。例如，刪除rs控制器rs-example： [root@master ~]# kubectl delete replicasets rs-example --cascade=false
replicaset.apps "rs-example" deleted 刪除操作完成后，此前由rs-example控制器管控的各Pod對象仍處于活動狀態，但它們變成了自主式Pod資源，用戶需要自行組織和維護好它們。 盡管ReplicaSet控制器功能強大，但在實踐中，它卻并非是用戶直接使用的控制器，而是要由比其更高一級抽象的Deployment控制器對象來調用

總結

以上是生活随笔為你收集整理的Pod控制器（一）ReplicaSet的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。