正文

kubernetes高可用（kubernetes高可用架構(gòu)）

發(fā)布時(shí)間：2023-04-14 02:43:36 稿源：創(chuàng)意嶺閱讀： 95

大家好！今天讓創(chuàng)意嶺的小編來(lái)大家介紹下關(guān)于kubernetes高可用的問(wèn)題，以下是小編對(duì)此問(wèn)題的歸納整理，讓我們一起來(lái)看看吧。

開(kāi)始之前先推薦一個(gè)非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計(jì)劃、工作報(bào)告、論文、代碼、作文、做題和對(duì)話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫(xiě)出的就越詳細(xì)，有微信小程序端、在線網(wǎng)頁(yè)版、PC客戶(hù)端

官網(wǎng)：https://ai.de1919.com。

創(chuàng)意嶺作為行業(yè)內(nèi)優(yōu)秀的企業(yè)，服務(wù)客戶(hù)遍布全球各地，如需了解SEO相關(guān)業(yè)務(wù)請(qǐng)撥打電話175-8598-2043，或添加微信：1454722008

本文目錄:

1、【Flink on k8s】高可用的關(guān)鍵機(jī)制及configmap數(shù)據(jù)詳解
2、kubernetes架構(gòu)-組件交互篇
3、Kubernetes存儲(chǔ)
4、Kubernetes對(duì)象之ReplicaSet

kubernetes高可用（kubernetes高可用架構(gòu)）

一、【Flink on k8s】高可用的關(guān)鍵機(jī)制及configmap數(shù)據(jù)詳解

源碼詳解：DefaultCompletedCheckpointStore.addCheckpoint/tryRemoveCompletedCheckpoint

步驟 1 ：根據(jù)checkpointID獲取checkpoint path

步驟 2 ：在s3 path寫(xiě)state數(shù)據(jù)，接著修改configmap的中checkpoint信息即flink-161511ce1fe78368bc659597e472fb7d-jobmanager-leader的checkpointID-0000000000000102688

步驟 3 ：把checkpoint信息放到隊(duì)列里面，然后根據(jù)需要保留的completecheckpoint數(shù)量（集群配置state.checkpoints.num-retained），刪除多余的completecheckpoint

設(shè)置 s3 協(xié)議的文件路徑作為狀態(tài)后端即 s3://bucket01/flink/savepoints 、 s3://bucket01/flink/checkpoints ，設(shè)置支持 s3 協(xié)議的集群即 s3.endpoint 、 s3.access-key 和 s3.secret-key 。

high-availability 設(shè)置為 org.apache.flink.kubernetes.highavailability.KubernetesHaServicesFactory ，

kubernetes.namespace 是指 kubernetes 的 namespace，kubernetes.service-account 是指 kubernetes 的serviceaccount， high-availability.storageDir 采用 s3 地址，最后 kubernetes.cluster-id 是設(shè)置了高可用 configmap 的前綴，例如 flink-dispatcher-leader、flink-161511ce1fe78368bc659597e472fb7d-jobmanager-leader 等

dispatcher 是管理作業(yè)的主節(jié)點(diǎn)，高可用數(shù)據(jù)主要有 dispatcher 主節(jié)點(diǎn)的地址 、 非完成狀態(tài)的作業(yè)狀態(tài)和流圖保存地址 ，其中流圖保存地址是 Base64 編碼的。如下所示，dispatcher 主節(jié)點(diǎn)是 akka.tcp://flink@10.244.0.246:8123/user/rpc/dispatcher_1 ，作業(yè) 161511ce1fe78368bc659597e472fb7d 的狀態(tài)是 Running ，其流圖 jobGraph-161511ce1fe78368bc659597e472fb7d 保存在 s3://bucket01/flink/ha/default/submittedJobGraph407e2d6a5be8

作業(yè)的高可用數(shù)據(jù)主要有 作業(yè)管理節(jié)點(diǎn)的地址 、 當(dāng)前作業(yè)的checkpoint 最新數(shù)據(jù)的保存地址 ，其中checkpoint 保存地址是 Base64 編碼的。如下所示，作業(yè)管理節(jié)點(diǎn)是 akka.tcp://flink@10.244.0.246:8123/user/rpc/jobmanager_2 ，該作業(yè)最新的 checkpoint 是 checkpointID-0000000000000102688 ，其保存地址是 s3://bucket01/flink/ha/default/completedCheckpointf07724c0946a

二、kubernetes架構(gòu)-組件交互篇

Kubernetes的節(jié)點(diǎn)包含兩種角色：Master節(jié)點(diǎn)和Node節(jié)點(diǎn)。Master節(jié)點(diǎn)部署apiserver 、scheduler、controller manager (replication controller、node controller等)，Node節(jié)點(diǎn)上部署kubelet和proxy。當(dāng)然可以把Master和Node節(jié)點(diǎn)部署到一起，只是生產(chǎn)環(huán)境通常不建議這樣做。

以下涉及各個(gè)組件實(shí)現(xiàn)了什么，有什么處理邏輯，部分組件涉及該組件的高可用，并以deployment創(chuàng)建為例串了下流程。整個(gè)下來(lái)，對(duì)kunernetes各個(gè)組件有一定的了解。

Apiserver 是Kubernetes最核心的組件，是整個(gè)集群API的入口，每個(gè)組件都需要和它交互。Kubernetes所有資源數(shù)據(jù)都是通過(guò)Apiserver保存到后端Etcd的，它本身還提供了對(duì)資源的緩存。因?yàn)锳piserver是無(wú)狀態(tài)的，所以在集群的高可用部署可以為多活。

Apiserver啟動(dòng) 后會(huì)將每個(gè)版本的接口注冊(cè)到一個(gè) 核心的路由分發(fā)器(Mux) 。Kubernetes API接口主要分為組、版本和資源三層。舉例：“/apis/batch/v1/jobs”接口，batch是組，v1是版本，jobs是資源。Kubernetes的核心資源都放在“/api”接口下，擴(kuò)展的接口放在“/apis”下。

Apiserver請(qǐng)求處理流程拆分如下：

1) 當(dāng)客戶(hù)端請(qǐng)求到達(dá)Apiserver后，首先經(jīng)過(guò)Authentication認(rèn)證和Authorization授權(quán)。認(rèn)證支持Basic、Token及證書(shū)認(rèn)證等。授權(quán)目前默認(rèn)使用的是RBAC。

2) 認(rèn)證成功后，請(qǐng)求到達(dá)路由分發(fā)器(Mux)，然后路由分發(fā)到指定接口。

3) 經(jīng)過(guò)路由分發(fā)后，為了兼容多個(gè)接口版本，將請(qǐng)求中不同版本的資源類(lèi)型統(tǒng)一轉(zhuǎn)化為一個(gè)內(nèi)部資源類(lèi)型。

4) 轉(zhuǎn)換為內(nèi)部模型后，進(jìn)入Admission準(zhǔn)入控制，在準(zhǔn)入控制采用插件機(jī)制，用戶(hù)可以定義自己的注入控制器驗(yàn)證，并更改資源配置。

5) 準(zhǔn)入控制通過(guò)后，進(jìn)入 Validation資源校驗(yàn) 。資源校驗(yàn)主要是驗(yàn)證參數(shù)是否合法，必傳參數(shù)是否齊備等。

6) 最后轉(zhuǎn)化到用戶(hù)最初的資源版本，并保存到 Etcd 中。

Controller manager是負(fù)責(zé)資源管理的組件，它主要負(fù)責(zé)容器的副本數(shù)管理、節(jié)點(diǎn)狀態(tài)維護(hù)、節(jié)點(diǎn)網(wǎng)段分配等，是Kubernetes負(fù)責(zé)實(shí)現(xiàn)生命式API和控制器模式的核心。

以ReplicaSet為例，Controller manager會(huì)周期地檢測(cè)理想的“目標(biāo)容器數(shù)”和真實(shí)的“當(dāng)前容器數(shù)”是否相同。如果不相等，則會(huì)將實(shí)際的容器數(shù)調(diào)整到目標(biāo)容器數(shù)。當(dāng)設(shè)置一個(gè)ReplicaSet的副本數(shù)為10的時(shí)候，如果實(shí)際的容器數(shù)小于10，則會(huì)執(zhí)行調(diào)用Apiserver創(chuàng)建Pod。如果當(dāng)前容器數(shù)大于10，則會(huì)執(zhí)行刪除Pod操作。

Scheduler負(fù)責(zé)容器調(diào)度組件。每個(gè)Pod會(huì)在一臺(tái)node節(jié)點(diǎn)上啟動(dòng)，通過(guò) Scheduler 調(diào)度組件的篩選、打分，選擇出Pod啟動(dòng)的最佳節(jié)點(diǎn)。當(dāng)Pod創(chuàng)建后，Pod的NodeName屬性為空，Scheduler會(huì)查詢(xún)所有NodeName為空的Pod，并執(zhí)行調(diào)度策略。選擇最優(yōu)的部署節(jié)點(diǎn)后，調(diào)用 Apiserver 綁定Pod對(duì)應(yīng)的主機(jī)(設(shè)置Pod NodeName屬性)。綁定成功后，對(duì)應(yīng)節(jié)點(diǎn)的 Kubelet 便可以啟動(dòng)容器。

Scheduler的調(diào)度過(guò)程分為兩個(gè)步驟：

第一步是篩選（Predicate），篩選滿足需要的節(jié)點(diǎn)。篩選的條件主要包括（1）Pod所需的資源（CPU、內(nèi)存、GPU等）；（2）端口是否沖突（針對(duì)Pod HostPort端口和主機(jī)上面已有端口，我認(rèn)為這個(gè)應(yīng)該是容器的網(wǎng)絡(luò)模式為host）；（3）nodeSelector及親和性（Pod親和性和Node親和性）；（4）如果使用本地存儲(chǔ)，那么Pod在調(diào)度時(shí)，將只會(huì)調(diào)度存儲(chǔ)綁定的節(jié)點(diǎn)；（5）節(jié)點(diǎn)的驅(qū)趕策略，節(jié)點(diǎn)可以通過(guò)taint（污點(diǎn)）設(shè)置驅(qū)趕Pod策略，對(duì)應(yīng)的Pod也可以設(shè)置Toleration（容忍）。

第二步是根據(jù)資源分配算法排序打分（Priorities），選擇得分最高的節(jié)點(diǎn)作為最終的調(diào)度節(jié)點(diǎn)，主要調(diào)度策略包括LeastRequestedPriority（最少資源請(qǐng)求）、BalancedResourceAllocation（均衡資源使用）、ImageLocalityPriority（鏡像本地優(yōu)先）和NodeAffinityPriority（主機(jī)親和算法）等。為了歸一化每種算法的權(quán)重，每種算法取值范圍都是0～10，累加所有算法的總和，取得分最大的主機(jī)作為Pod的運(yùn)行主機(jī)。

Scheduler組件本地維護(hù)了一個(gè)調(diào)度隊(duì)列和本地緩存，調(diào)度隊(duì)列暫存了需要被調(diào)度的Pod，調(diào)度的先后順序可以調(diào)整。本地緩存主要是緩存Pod和Node信息，可以避免每次調(diào)度時(shí)都從Apiserver獲取主機(jī)信息。

為了提高調(diào)度效率，Scheduler采用了樂(lè)觀鎖，即Predicate和Priorities是并行操作的，那么有可能會(huì)出現(xiàn)數(shù)據(jù)的不一致，即Pod調(diào)度時(shí)主機(jī)上面資源是符合要求的。當(dāng)容器啟動(dòng)時(shí)，由于其他容器也調(diào)度到該節(jié)點(diǎn)導(dǎo)致資源又不滿足要求了。所以在Kubelet啟動(dòng)容器之前首先執(zhí)行一遍審計(jì)（在Kubelet上重新執(zhí)行一遍Predicate）操作，確認(rèn)資源充足才會(huì)啟動(dòng)容器，否則將更新Pod狀態(tài)為Failed。

Scheduler是典型的單體調(diào)度。為了支持高可用，可以部署多個(gè)Scheduler，但只有一個(gè)Scheduler處于Active狀態(tài)，其他都為Standby狀態(tài)。當(dāng)處于Active的Scheduler宕機(jī)后，由于無(wú)法續(xù)約，會(huì)從Etcd中摘除，其他Scheduler節(jié)點(diǎn)便可以通過(guò)爭(zhēng)搶注冊(cè)Etcd的方式獲得調(diào)度權(quán)限。

Kubelet 接收 Apiserver 分配的啟動(dòng)容器的任務(wù)，然后拉起容器。當(dāng)然，如果收到銷(xiāo)毀指令，同樣會(huì)執(zhí)行刪除容器的操作。

本地鏡像也是由Kubelet負(fù)責(zé)維護(hù)，配合GC機(jī)制，刪除無(wú)用的鏡像和容器。

除此之外，Kubelet還需定時(shí)向 Apiserver 上報(bào)自己的狀態(tài)，一方面告知Apiserver自身還存活著，另一方面將本節(jié)點(diǎn)的Pod狀態(tài)、存儲(chǔ)使用等信息上報(bào)到Apiserver。

Kubelet啟動(dòng)一個(gè)主線程，用于保持和Apiserver的通信，主線程不能被阻塞，否則將無(wú)法定時(shí)完成上報(bào)，導(dǎo)致Apiserver將該節(jié)點(diǎn)設(shè)置為NotReady狀態(tài)。所以Kubelet會(huì)啟動(dòng)很多協(xié)程用于檢測(cè)節(jié)點(diǎn)狀態(tài)，回收廢舊資源，驅(qū)趕低優(yōu)先級(jí)Pod，探測(cè)Pod健康狀態(tài)等。 syncLoop 是Kubelet的核心，它通過(guò)一個(gè)死循環(huán)不斷接收來(lái)自Pod的變化信息，并通過(guò)各種Manger執(zhí)行對(duì)應(yīng)的操作，如下圖。

Kube-proxy 是代理服務(wù)，為Kubernetes的Service提供負(fù)載均衡，本質(zhì)上是iptables或ipvs實(shí)現(xiàn)的。Kubernetes將服務(wù)和Pod通過(guò)標(biāo)簽的方式關(guān)聯(lián)到一起，通過(guò)服務(wù)的標(biāo)簽篩選找到后端的Pod，但服務(wù)的后端通過(guò)Endpoint(端點(diǎn))關(guān)聯(lián)Pod，Endpoint可以理解為“Pod地址:Pod端口”的組合。

舉例：kube-proxy如何生成iptables規(guī)則的？當(dāng)創(chuàng)建一個(gè)服務(wù)后，Kubernetes默認(rèn)會(huì)為每個(gè)服務(wù)生成一個(gè)虛擬IP( VIP )。通過(guò)訪問(wèn)VIP即以負(fù)載均衡的方式訪問(wèn)后端Pod的服務(wù)。舉例一個(gè)服務(wù)：對(duì)內(nèi)提供服務(wù)的端口8080，對(duì)外提供服務(wù)的端口31341，并通過(guò)paas.io/serviceName選擇后端容器。這會(huì)在每臺(tái)機(jī)器上生產(chǎn)如下iptables規(guī)則。

1）將進(jìn)和出的流量都轉(zhuǎn)到KUBE-SERVICES鏈上。

2）目標(biāo)是VIP(10.0.0.41)或訪問(wèn)NodePort的流量都轉(zhuǎn)發(fā)到某個(gè)鏈上(KUBE-SVC-HDARFCJAQENGWQ37)。

3）KUBE-SVC-HDARFCJAQENGWQ37鏈通過(guò)iptables的隨機(jī)模塊分發(fā)流量，第一個(gè)是50%，第二個(gè)是100%。如果后端有3個(gè)Pod，那么比例將會(huì)是33%、50%、100%，以此類(lèi)推。

4）最終通過(guò)DNAT進(jìn)入容器。

通過(guò)kubectl run（eg：kubectl run nginx--image=nginx--replicas=5）命令去創(chuàng)建一個(gè)Deployment。

這個(gè)請(qǐng)求先到達(dá) Apiserver ，Apiserver負(fù)責(zé)保存到 Etcd ， Controller manager 中的Deployment控制器會(huì)監(jiān)測(cè)到有一個(gè)Deployment被創(chuàng)建，此時(shí)會(huì)創(chuàng)建相應(yīng)的ReplicaSet，ReplicaSet的控制器也會(huì)監(jiān)測(cè)到有新的ReplicaSet創(chuàng)建，會(huì)根據(jù)相應(yīng)的副本數(shù)調(diào)用Apiserver創(chuàng)建Pod。

此時(shí)Pod的主機(jī)字段是空的，因?yàn)檫€不知道將要在哪臺(tái)機(jī)器上面啟動(dòng)，然后 Scheduler 開(kāi)始介入，調(diào)度沒(méi)有分配主機(jī)的Pod，通過(guò)預(yù)先設(shè)定的調(diào)度規(guī)則，包括節(jié)點(diǎn)標(biāo)簽匹配、資源使用量等選擇出最合適的一臺(tái)機(jī)器，在通過(guò)apiserver的bind請(qǐng)求將Pod的主機(jī)字段設(shè)置完成。

Kubelet 監(jiān)測(cè)到屬于自己的節(jié)點(diǎn)有新容器創(chuàng)建的事件，于是便拉起一個(gè)容器，并上報(bào)給apiserver容器的狀態(tài)。

三、Kubernetes存儲(chǔ)

在 Docker的設(shè)計(jì) 實(shí)現(xiàn)中，容器中的數(shù)據(jù)是臨時(shí)性的，當(dāng)容器銷(xiāo)毀或重新啟動(dòng)時(shí)存儲(chǔ)在容器內(nèi)部的數(shù)據(jù)將會(huì)全部丟失，但實(shí)際上很多容器化應(yīng)用是需要持久化保存的數(shù)據(jù)，這就需要使用Docker數(shù)據(jù)卷掛載宿主機(jī)上的文件或者目錄到容器中以保證數(shù)據(jù)的持久化存儲(chǔ)。在 Kubernetes中Pod重建如同Docker銷(xiāo)毀一樣，數(shù)據(jù)就會(huì)丟失，Kubernetes也通過(guò)掛載數(shù)據(jù)卷方式為Pod數(shù)據(jù)提供持久化能力，這些數(shù)據(jù)卷以Pod為最小單位進(jìn)行存儲(chǔ)，通過(guò)共享存儲(chǔ)或分布式存儲(chǔ)在各個(gè)Pod之間實(shí)現(xiàn)共享。

Kubernetes是由Master節(jié)點(diǎn)及Node節(jié)點(diǎn)組成的，在Master節(jié)點(diǎn)中通過(guò)etcd存儲(chǔ)了Kubernetes集群的節(jié)點(diǎn)信息、Pod信息、容器信息、配置信息。Node節(jié)點(diǎn)主要對(duì)外提供容器服務(wù)，著重描述Node節(jié)點(diǎn)與存儲(chǔ)相關(guān)的內(nèi)容。

Kubernetes以Pod為單位對(duì)外提供容器服務(wù)，真正的服務(wù)是通過(guò)Service進(jìn)行訪問(wèn)的。 Kubernetes中的服務(wù)按類(lèi)型分成三種：無(wú)狀態(tài)服務(wù)（stateless）、普通有狀態(tài)服務(wù)、有狀態(tài)集群服務(wù) 。

無(wú)狀態(tài)服務(wù)：不需要持久化存儲(chǔ)的，即使Pod重建也不會(huì)受影響，只要確保服務(wù)的可靠性便可，Kubernetes通過(guò)ReplicationSet來(lái)保證某個(gè)服務(wù)的實(shí)例數(shù)量。

普通有狀態(tài)服務(wù)：這類(lèi)服務(wù)需要保留服務(wù)的狀態(tài)，通常通過(guò)Kubernetes提供的Volume及Persistent Volume、Persistent Volume Claim來(lái)保存狀態(tài)。

有狀態(tài)的集群服務(wù)：這類(lèi)服務(wù)除了保存服務(wù)狀態(tài)的同時(shí)還需要提供集群管理的功能，集群管理過(guò)程中也涉及臨時(shí)數(shù)據(jù)的保存、集群內(nèi)數(shù)據(jù)共享等。

Kubernetes中涉及存儲(chǔ)的主要使用場(chǎng)景：

1) 容器集群相關(guān)配置信息及運(yùn)行時(shí)信息保存，這類(lèi)信息存儲(chǔ)在etcd中。

2) 服務(wù)的基本配置文件及證書(shū)文件。

3) 服務(wù)的狀態(tài)存儲(chǔ)、數(shù)據(jù)存儲(chǔ)信息。

4) 集群內(nèi)不同服務(wù)交換共享的數(shù)據(jù)信息。

1) 臨時(shí)文件形式：同一個(gè)Pod內(nèi)不同容器間通過(guò)共享內(nèi)存方式訪問(wèn)，會(huì)創(chuàng)建一個(gè)空目錄，交換完信息后會(huì)刪除這個(gè)空目錄。

2) HostPath方式：同一個(gè)Node內(nèi)不同的Pod間進(jìn)行信息共享使用HostPath方式(比如時(shí)區(qū)timezone)。如果Pod配置了EmptyDir數(shù)據(jù)卷，則它在Pod的生命周期內(nèi)都會(huì)存在。當(dāng)Pod被分配到Node上的時(shí)候，會(huì)在Node上創(chuàng)建EmptyDir數(shù)據(jù)卷，并掛載到Pod的容器中。

3) PV及PVC： Kubernetes的持久化存儲(chǔ)機(jī)制的核心是PV(Persistent Volume)、PVC (Persistent Volume Claim)。PV是Volume插件，關(guān)聯(lián)到真正的后端存儲(chǔ)系統(tǒng)，PVC是從PV中申請(qǐng)資源，而不需要關(guān)心存儲(chǔ)的提供方。PVC和PV的關(guān)系就如同Pod和Node一樣，Pod是消費(fèi)Node提供的資源，PVC是消費(fèi)PV提供的存儲(chǔ)資源。PVC和PV通過(guò)匹配完成綁定關(guān)系，PVC可以被Pod里的容器掛載。

4) 網(wǎng)絡(luò)方式：不同Node節(jié)點(diǎn)之間的數(shù)據(jù)共享通過(guò)網(wǎng)絡(luò)方式使用，通常采用分布式存儲(chǔ)方式。開(kāi)源的分布式文件系統(tǒng)比較流行的選擇有GlusterFS和Ceph，還有一些其他的分布式文件系統(tǒng)(NFS)選擇。

5) 自定義插件方式：Kubernetes提供了豐富的Volume的插件來(lái)進(jìn)行存儲(chǔ)管理。如果存儲(chǔ)管理接口不夠用，用戶(hù)可以通過(guò)CSI或Flex Volume進(jìn)行擴(kuò)展。

存儲(chǔ)管理組件（存儲(chǔ)組件）主要是接收北向API收到的Rest請(qǐng)求，維護(hù)持久卷的生命周期管理。如創(chuàng)建、刪除卷，存儲(chǔ)組件負(fù)責(zé)與后端存儲(chǔ)軟件交互完成實(shí)際的創(chuàng)建、刪除卷等操作；并負(fù)責(zé)調(diào)用Kubernetes原生接口創(chuàng)建對(duì)應(yīng)的PVC和PV 。

存儲(chǔ)后端系統(tǒng)提供數(shù)據(jù)文件的實(shí)際持久化能力，不僅需要實(shí)現(xiàn)數(shù)據(jù)文件的讀寫(xiě)、副本復(fù)制等存儲(chǔ)操作，通常還需具備多節(jié)點(diǎn)高可用的能力。

當(dāng)需要為自己的微服務(wù)應(yīng)用掛載持久卷時(shí)，只需要通過(guò)存儲(chǔ)組件創(chuàng)建持久卷，存儲(chǔ)組件會(huì)在Kubernetes業(yè)務(wù)集群創(chuàng)建PVC/PV，并到后端存儲(chǔ)系統(tǒng)(如GlusterFS)上創(chuàng)建真正的物理Volume，同時(shí)維護(hù)好PVC/PV/Volume之間的一一映射對(duì)應(yīng)關(guān)系。這樣，用戶(hù)部署容器時(shí)就可以選擇掛載相應(yīng)的持久卷，部署后相應(yīng)的卷就可以掛載到對(duì)應(yīng)的容器。應(yīng)用掛載持久卷后，進(jìn)行讀寫(xiě)時(shí)就類(lèi)似于本地目錄的讀寫(xiě)操作。

在Pod進(jìn)行重建或者遷移到其他節(jié)點(diǎn)時(shí)，Pod可以自動(dòng)掛回原來(lái)對(duì)應(yīng)的持久卷，繼續(xù)使用原先的數(shù)據(jù)。多個(gè)Pod可以共享一個(gè)持久卷，從而達(dá)到容器間文件共享的目的。

摘抄自陸平的《基于Kubernetes的容器云平臺(tái)實(shí)戰(zhàn)》一書(shū)的第11章Kubernetes存儲(chǔ)

四、Kubernetes對(duì)象之ReplicaSet

說(shuō)到ReplicaSet對(duì)象，得先說(shuō)說(shuō)ReplicationController（簡(jiǎn)稱(chēng)為RC）。在舊版本的Kubernetes中，只有ReplicationController對(duì)象。它的主要作用是 確保Pod以你指定的副本數(shù)運(yùn)行 ，即如果有容器異常退出，會(huì)自動(dòng)創(chuàng)建新的 Pod 來(lái)替代；而異常多出來(lái)的容器也會(huì)自動(dòng)回收?？梢哉f(shuō)，通過(guò)ReplicationController，Kubernetes實(shí)現(xiàn)了集群的高可用性。

在新版本的 Kubernetes 中建議使用 ReplicaSet（簡(jiǎn)稱(chēng)為RS ）來(lái)取代 ReplicationController。ReplicaSet 跟 ReplicationController 沒(méi)有本質(zhì)的不同，只是名字不一樣，并且 ReplicaSet 支持集合式的 selector（ReplicationController 僅支持等式）。

ReplicationController和Pod一樣，都是Kubernetes中的對(duì)象，因此創(chuàng)建方式類(lèi)似。通過(guò)yaml或json描述文件來(lái)定義一個(gè)ReplicationController對(duì)象。一個(gè)最簡(jiǎn)單的ReplicationController的定義如下：

下面簡(jiǎn)要解釋一下上述ReplicationController描述文件中的關(guān)鍵點(diǎn)：

上面的RC通過(guò) kubectl apply 命令創(chuàng)建成功后，Kubernetes會(huì)在所有可用的Node上，新建三個(gè)Pod。每個(gè)Pod都有一個(gè)app: nginx的label，并且每個(gè)Pod中都運(yùn)行一個(gè)nginx容器。一旦其中某個(gè)Pod發(fā)生故障停止運(yùn)行了，Controller Manager都能夠及時(shí)發(fā)現(xiàn)，然后根據(jù)當(dāng)前RC定義，創(chuàng)建出一個(gè)新的Pod，從而使包含label：app: nginx的Pod的運(yùn)行副本數(shù)始終為3。

由于ReplicaSet是ReplicationController的代替物，因此用法基本相同，唯一的區(qū)別在于ReplicaSet支持集合式的selector。一個(gè)典型的RS描述文件如下：

以上RS描述文件中，selector除了可以使用matchLabels，還支持集合式的操作：

使用 kubectl delete 命令會(huì)刪除此RS以及它管理的Pod。在Kubernetes刪除RS前，會(huì)將RS的replica調(diào)整為0，等待所有的Pod被刪除后，在執(zhí)行RS對(duì)象的刪除。

如果希望僅僅刪除RS對(duì)象（保留Pod），請(qǐng)使用 kubectl delete 命令時(shí)添加 --cascade=false 選項(xiàng)。

通過(guò)修改 .spec.replicas 的值可以實(shí)時(shí)修改RS運(yùn)行的Pod數(shù)量。

RS可以通過(guò)HPA來(lái)根據(jù)一些運(yùn)行時(shí)指標(biāo)實(shí)現(xiàn)自動(dòng)伸縮，下面是一個(gè)簡(jiǎn)單的例子：

上面的描述文件會(huì)創(chuàng)建一個(gè)名為frontend-scaler的HorizontalPodAutoscaler，它會(huì)根據(jù)CPU的運(yùn)行參數(shù)來(lái)對(duì)名為frontend的RS進(jìn)行自動(dòng)伸縮。

更過(guò)關(guān)于HPA的信息請(qǐng)參考：

以上就是關(guān)于kubernetes高可用相關(guān)問(wèn)題的回答。希望能幫到你，如有更多相關(guān)問(wèn)題，您也可以聯(lián)系我們的客服進(jìn)行咨詢(xún)，客服也會(huì)為您講解更多精彩的知識(shí)和內(nèi)容。