正文

kubernetes架構(gòu)（kubernetes架構(gòu)圖）

發(fā)布時(shí)間：2023-04-14 05:03:15 稿源：創(chuàng)意嶺閱讀： 69

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

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

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫(xiě)出的就越詳細(xì)，有微信小程序端、在線(xiàn)網(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)撥打電話(huà)175-8598-2043，或添加微信：1454722008

本文目錄:

1、kubelet 架構(gòu)淺析
2、kubernetes控制平面組件：etcd
3、Kuboard 從微服務(wù)視角理解 Kubernetes
4、高可用kubernetes集群搭建

kubernetes架構(gòu)（kubernetes架構(gòu)圖）

一、kubelet 架構(gòu)淺析

kubelet 是運(yùn)行在每個(gè)節(jié)點(diǎn)上的主要的“節(jié)點(diǎn)代理”，每個(gè)節(jié)點(diǎn)都會(huì)啟動(dòng) kubelet進(jìn)程，用來(lái)處理 Master 節(jié)點(diǎn)下發(fā)到本節(jié)點(diǎn)的任務(wù)，按照 PodSpec 描述來(lái)管理Pod 和其中的容器（PodSpec 是用來(lái)描述一個(gè) pod 的 YAML 或者 JSON 對(duì)象）。

kubelet 通過(guò)各種機(jī)制（主要通過(guò) apiserver ）獲取一組 PodSpec 并保證在這些 PodSpec 中描述的容器健康運(yùn)行。

1、kubelet 默認(rèn)監(jiān)聽(tīng)四個(gè)端口，分別為 10250 、10255、10248、4194。

2、kubelet 主要功能：

上圖展示了 kubelet 組件中的模塊以及模塊間的劃分。

在 v1.12 中，kubelet 組件有18個(gè)主要的 manager（kubernetes/pkg/kubelet/kubelet.go）：

其中比較重要的模塊后面會(huì)進(jìn)行一一分析。

本片文章主要講解了 kubelet 在 kubernetes 系統(tǒng)中的功能，所監(jiān)聽(tīng)四個(gè)端口的主要作用，自身架構(gòu)中包含的組件以及各組件的用途。

參考：

微軟資深工程師詳解 K8S 容器運(yùn)行時(shí)

kubernetes 簡(jiǎn)介： kubelet 和 pod

Kubelet 組件解析

二、kubernetes控制平面組件：etcd

--listen-peer-urls

--listen-client-urls

--initial-advertise-peer-urls

--initial-cluster

--initial-cluster-state

--advertise-client-urls

1.code

headless svc, 像DNS RR ClusterIP:None

kubectl -n stg1 get endpoints

client 怎么訪問(wèn)：

2.配置文件

3.apply

官方的code有兩個(gè)問(wèn)題

本地訪問(wèn)

擴(kuò)容

利用反親和性分布etcd pod到不同節(jié)點(diǎn)

~ ❯❯❯ etcdctl get / --prefix

從 etcd 的架構(gòu)圖中我們可以看到，etcd 主要分為四個(gè)部分。

etcd 目前支持 V2 和 V3 兩個(gè)大版本，這兩個(gè)版本在實(shí)現(xiàn)上有比較大的不同，一方面是對(duì)外提供接口的方式，另一方面就是底層的存儲(chǔ)引擎，V2 版本的實(shí)例是一個(gè)純內(nèi)存的實(shí)現(xiàn)，所有的數(shù)據(jù)都沒(méi)有存儲(chǔ)在磁盤(pán)上，而 V3 版本的實(shí)例就支持了數(shù)據(jù)的持久化。

v3默認(rèn)boltdb

consortium etcd2+mysql

數(shù)據(jù)默認(rèn)會(huì)存放在 /var/lib/etcd/default/ 目錄。我們會(huì)發(fā)現(xiàn)數(shù)據(jù)所在的目錄，會(huì)被分為兩個(gè)文件夾中，分別是 snap 和 wal目錄。

解決三個(gè)問(wèn)題：節(jié)點(diǎn)選舉、日志復(fù)制以及安全性 。

每一個(gè) Raft 集群中都包含多個(gè)服務(wù)器，在任意時(shí)刻，每一臺(tái)服務(wù)器只可能處于 Leader 、 Follower 以及 Candidate 三種狀態(tài)；在處于正常的狀態(tài)時(shí)，集群中只會(huì)存在一個(gè) Leader 狀態(tài)，其余的服務(wù)器都是 Follower 狀態(tài)。

所有的 Follower 節(jié)點(diǎn)都是被動(dòng)的，它們不會(huì)主動(dòng)發(fā)出任何的請(qǐng)求 ，只會(huì)響應(yīng) Leader 和 Candidate 發(fā)出的請(qǐng)求。對(duì)于每一個(gè)用戶(hù)的可變操作，都會(huì)被路由給 Leader 節(jié)點(diǎn)進(jìn)行處理，除了 Leader 和 Follower 節(jié)點(diǎn)之外，Candidate 節(jié)點(diǎn)其實(shí)只是集群運(yùn)行過(guò)程中的一個(gè)臨時(shí)狀態(tài)。

每一個(gè)服務(wù)器都會(huì)存儲(chǔ)當(dāng)前集群的最新任期，它就像是一個(gè)單調(diào)遞增的邏輯時(shí)鐘，能夠同步各個(gè)節(jié)點(diǎn)之間的狀態(tài)，當(dāng)前節(jié)點(diǎn)持有的任期會(huì)隨著每一個(gè)請(qǐng)求被傳遞到其他的節(jié)點(diǎn)上。Raft 協(xié)議在每一個(gè)任期的開(kāi)始時(shí)都會(huì)從一個(gè)集群中選出一個(gè)節(jié)點(diǎn)作為集群的 Leader 節(jié)點(diǎn)，這個(gè)節(jié)點(diǎn)會(huì)負(fù)責(zé)集群中的日志的復(fù)制以及管理工作。

客戶(hù)端通過(guò) 監(jiān)聽(tīng)指定的key可以迅速感知key的變化并作出相應(yīng)處理 ，watch機(jī)制的實(shí)現(xiàn)依賴(lài)于 資源版本號(hào)revision的設(shè)計(jì) ，每一次key的更新都會(huì)使得revision原子遞增，因此根據(jù)不同的版本號(hào)revision的對(duì)比就可以感知新事件的發(fā)生。etcd watch機(jī)制有著廣泛的應(yīng)用，比如利用etcd實(shí)現(xiàn)分布式鎖； k8s中監(jiān)聽(tīng)各種資源的變化 ，從而實(shí)現(xiàn)各種controller邏輯等。

watch機(jī)制的實(shí)現(xiàn)主要可分為三個(gè)部分

client使用 watchClient 的watch接口發(fā)起watch請(qǐng)求，與server端建立一個(gè) gRPCStream 連接。

server端會(huì)為每個(gè)client生成唯一一個(gè)watch id，并記錄每個(gè)client也就是watcher監(jiān)聽(tīng)的key或者key range，通過(guò)recvLoop接收client請(qǐng)求，通過(guò)sendLoop發(fā)送請(qǐng)求，server端只負(fù)責(zé)收發(fā)請(qǐng)求和響應(yīng)。

主要的實(shí)現(xiàn)都放在了watchalbStore層，watchalbStore會(huì)監(jiān)聽(tīng)key的變化，然后通過(guò)syncWatchersLoop和syncVictimsLoop兩個(gè)處理流程將key的更新變化包裝成event，通過(guò)channel發(fā)送給gRPC server。

MVCC（Multiversion Concurrency Control）多版本并發(fā)控制機(jī)制

場(chǎng)景1:

這就是悲觀鎖

悲觀鎖：悲觀得認(rèn)為并發(fā)事務(wù)會(huì)沖突，所以要先拿鎖，拿到鎖的作修改操作

場(chǎng)景2

數(shù)據(jù)庫(kù)：寫(xiě)回磁盤(pán)，A寫(xiě)好了。哎，B和C都是version 13，我咋寫(xiě)？算了，報(bào)錯(cuò)吧。。

就是樂(lè)觀鎖，默認(rèn)不加鎖，你盡管寫(xiě)，沖突我認(rèn)慫！樂(lè)觀鎖其實(shí)不是鎖，只是相對(duì)悲觀鎖來(lái)定義，適合讀多寫(xiě)少。

樂(lè)觀鎖：樂(lè)觀得認(rèn)為數(shù)據(jù)不會(huì)沖突，但發(fā)生沖突時(shí)要能檢測(cè)到。

場(chǎng)景3

這就是MVCC，在 MVCC 數(shù)據(jù)庫(kù)中，你更新一個(gè) key-value 數(shù)據(jù)的時(shí)候，它并不會(huì)直接覆蓋原數(shù)據(jù)，而是 新增一個(gè)版本來(lái)存儲(chǔ)新的數(shù)據(jù)，每個(gè)數(shù)據(jù)都有一個(gè)版本號(hào) ，版本號(hào)是一個(gè)邏輯時(shí)鐘，不會(huì)因?yàn)榉?wù)器時(shí)間的差異而受影響。

MVCC不等于樂(lè)觀鎖！

--rev 查的是main

在底層boltdb里，實(shí)際分布是這樣的：

底層的key是revision，/奧特曼是用戶(hù)key，“他很帥”就是用戶(hù)value

刪除

之前有delete動(dòng)作，但是依然有版本記錄。為什么？

刪除這個(gè)動(dòng)作，其實(shí)etcd是在blotdb里寫(xiě)了一條，“刪除用戶(hù)/奧特曼”

此時(shí)有個(gè)問(wèn)題：用戶(hù)說(shuō)我的確刪除了啊，真的不要了！請(qǐng)把空間還給我啊！

回收 compact（壓縮）

etcdctl compact {version}

compact 需要一個(gè)版本號(hào)。這個(gè)版本號(hào)就是寫(xiě)事務(wù)遞增的那個(gè)版本號(hào)，compact 12345，就是說(shuō)把版本12345以前的 標(biāo)記刪除了的數(shù)據(jù) 釋放掉，用戶(hù)沒(méi)刪除的數(shù)據(jù)肯定不能回收。

如何壓縮：

注意修改go.mod

Watch

服務(wù)發(fā)現(xiàn)要解決的也是分布式系統(tǒng)中最常見(jiàn)的問(wèn)題之一，即在同一個(gè)分布式集群中的進(jìn)程或服務(wù)，要如何才能找到對(duì)方并建立連接。本質(zhì)上來(lái)說(shuō)，服務(wù)發(fā)現(xiàn)就是想要了解集群中是否有進(jìn)程在監(jiān)聽(tīng) udp 或 tcp 端口，并且通過(guò)名字就可以查找和連接。

需要實(shí)現(xiàn)的功能；

discover.go

eBay payment

ebay kubernetes 控制面架構(gòu)

問(wèn)題

三、Kuboard 從微服務(wù)視角理解 Kubernetes

當(dāng)我們談?wù)撐⒎?wù)的時(shí)候，總避免不了說(shuō) Spring Cloud / Dubbo，這些微服務(wù)架構(gòu)的采用，確實(shí)達(dá)到了我們對(duì)他的期許：分布式、熔斷/限流、高可用、可擴(kuò)展、分離關(guān)注、鏈路追蹤、小團(tuán)隊(duì)快速迭代。

然而，微服務(wù)架構(gòu)的引入在解決單體應(yīng)用的一些問(wèn)題的同時(shí)，也給我們帶來(lái)了新的復(fù)雜度：

作者在落地 Spring Cloud 微服務(wù)架構(gòu)的過(guò)程中，設(shè)計(jì)了如下圖所示的微服務(wù)參考架構(gòu)：

該圖的左側(cè)是 DevOps 平臺(tái)，涵蓋構(gòu)建、測(cè)試、包管理、部署及運(yùn)維、監(jiān)控及評(píng)估。右側(cè)是運(yùn)行時(shí)平臺(tái)，分成互聯(lián)網(wǎng)層、展現(xiàn)層、微服務(wù)層、數(shù)據(jù)層。

運(yùn)行時(shí)環(huán)境采納了微服務(wù)架構(gòu)后，因?yàn)榧夹g(shù)組件的多樣性、業(yè)務(wù)領(lǐng)域的多樣性，導(dǎo)致了微服務(wù)拆分之后，產(chǎn)生了數(shù)十個(gè)微服務(wù)可部署單元。這個(gè)情況給技術(shù)團(tuán)隊(duì)帶來(lái)了前所未有的挑戰(zhàn)：

在解決這些問(wèn)題的過(guò)程中，最終摸索出了一套以 Kubernetes 為關(guān)鍵環(huán)節(jié)的微服務(wù) DevOps 平臺(tái)。

如上圖所示，假設(shè)有20+ 開(kāi)發(fā)人員，

在單體應(yīng)用的時(shí)候，即使是手工打包也是能夠完成每天發(fā)布新版本的要求的。但是在微服務(wù)環(huán)境下，這個(gè)工作就必須交給 DevOps 的 Pipe Line 來(lái)完成。

DevOps 在構(gòu)建階段的主角是 GitLab、npm、maven、docker、Harbor等工具集，在部署和運(yùn)維環(huán)節(jié)的主角就是Kubernetes了。

最開(kāi)始嘗試容器化的時(shí)候，使用了 docker、docker-compose，但是docker-compose的編排能力有限，在考慮分布式方案時(shí)，從 docker swarm、kuberenetes 之中選擇了 Kubernetes，然而，Kubernetes 相較于 docker-compose，有一個(gè)很高的學(xué)習(xí)門(mén)檻，集群的安裝管理、YAML 文件的編寫(xiě)、多環(huán)境（開(kāi)發(fā)環(huán)境、測(cè)試環(huán)境、準(zhǔn)生產(chǎn)環(huán)境、生產(chǎn)環(huán)境）的配置、分布式環(huán)境下的問(wèn)題診斷和性能優(yōu)化等，一系列的問(wèn)題需要解決，團(tuán)隊(duì)中也出現(xiàn)一些抵觸情緒，對(duì)新事物持觀望的態(tài)度。

Kubernetes在諸多大廠的成功實(shí)施，仍然讓我們堅(jiān)信這條道路的正確性。為了解決 Kubernetes 學(xué)習(xí)門(mén)檻高、YAML 文件編寫(xiě)復(fù)雜等一系列現(xiàn)實(shí)中的困難，我們研發(fā)了 Kuboard ，一款 Kubernetes 的圖形化管理控制工具。

Kuboard 誕生于 Spring Cloud 微服務(wù)落地的實(shí)踐過(guò)程中，他在管理和使用 Kubernetes 的時(shí)候，也更多地是從微服務(wù)的視角來(lái)看待 Kubernetes。

具體體現(xiàn)在如下三個(gè)視角：

從管理和部署微服務(wù)的視角來(lái)看，微服務(wù)應(yīng)用是分布式應(yīng)用，應(yīng)該部署在一個(gè)分布式集群當(dāng)中，這個(gè)集群由諸多計(jì)算資源和存儲(chǔ)資源組成，微服務(wù)本身不應(yīng)該關(guān)心最終使用了哪個(gè)計(jì)算節(jié)點(diǎn)，持久化存儲(chǔ)被存放在什么位置；為了更好地利用資源，一個(gè)集群應(yīng)該被劃分成多個(gè)名稱(chēng)空間，每個(gè)名稱(chēng)空間內(nèi)可以部署一整套微服務(wù)應(yīng)用，名稱(chēng)空間之間不應(yīng)相互干擾。

如下圖所示： Kuboard 集群概覽界面

Kuboard 集群概覽視角，映射了 Kubernetes 中的如下幾個(gè)重要概念：

在集群概覽界面中，點(diǎn)擊一個(gè)名稱(chēng)空間，可以進(jìn)入 Kuboard 名稱(chēng)空間界面。一個(gè)名稱(chēng)空間內(nèi)部，是微服務(wù)部署相關(guān)的所有重要元素。與本文開(kāi)頭的微服務(wù)參考架構(gòu)相匹配， Kuboard 認(rèn)為，微服務(wù)的主要分層包括：

如下圖所示： Kuboard 名稱(chēng)空間截圖

Kuboard 名稱(chēng)空間視角，映射了 Kubernetes 中的如下幾個(gè)重要概念：

Kuboard 名稱(chēng)空間界面中，還為典型的運(yùn)維場(chǎng)景提供了便捷的操作入口，例如：

從名稱(chēng)空間界面中點(diǎn)擊一個(gè)工作負(fù)載（微服務(wù)），可進(jìn)入 Kuboard 工作負(fù)載編輯器界面。 Kuboard 當(dāng)前已經(jīng)支持的工作負(fù)載 Workload 類(lèi)型有：Deployment / StatefulSet / DaemonSet。

Kubernetes 中，與 Workload 相關(guān)的概念非常多， Kuboard 從微服務(wù)部署的實(shí)際需要出發(fā)，按照下圖所示的方式理解這些相關(guān)概念：

Kuboard 工作負(fù)載視圖中，關(guān)聯(lián)的 Kubernetes 中如下幾個(gè)重要的概念：

Kuboard 認(rèn)為，掌握這些概念并正確理解這些概念的關(guān)系之后，就可以勝任使用 Kubernetes 部署微服務(wù)的工作，為了使事情變得更簡(jiǎn)單，避免編寫(xiě)冗長(zhǎng)的 YAML 文件， Kuboard 以此概念為基礎(chǔ)，設(shè)計(jì)了 Kuboard 工作負(fù)載編輯器，如下圖所示：

如何監(jiān)控和評(píng)估微服務(wù)的運(yùn)行狀況，并根據(jù)監(jiān)控結(jié)果進(jìn)行問(wèn)題的定位和診斷？基于 Kubernetes / Spring Cloud / Java 等，開(kāi)源社區(qū)已經(jīng)提供了非常豐富的監(jiān)控組件，例如：

各種監(jiān)控系統(tǒng)各有側(cè)重，如果想要取得比較好的監(jiān)控效果，必須克服如下幾個(gè)困難：

Kuboard 認(rèn)為，應(yīng)該以微服務(wù)視角的視角快速查看到該無(wú)服務(wù)在不同層面的監(jiān)控結(jié)果。因此，在 Kuboard 的工作負(fù)載（微服務(wù)）查看界面中，可以直接點(diǎn)擊進(jìn)入不同監(jiān)控系統(tǒng)對(duì)應(yīng)的監(jiān)控結(jié)果，無(wú)需再監(jiān)控系統(tǒng)內(nèi)反復(fù)查找。如一下截圖所示：

點(diǎn)擊圖中 Nginx 監(jiān)控 、 容器組監(jiān)控 、 所在節(jié)點(diǎn)監(jiān)控 等按鈕，可以直接打開(kāi)該容器組對(duì)應(yīng)的監(jiān)控界面。因?yàn)槠南拗?，此處不再展開(kāi)描述，請(qǐng)到 www.kuboard.cn Kuboard 官網(wǎng) 提供的在線(xiàn)Demo體驗(yàn)具體的監(jiān)控效果。

Kuboard 產(chǎn)生于 Spring Cloud 微服務(wù)落地的實(shí)踐中，并在許多的實(shí)際項(xiàng)目中投入了使用，以微服務(wù)的視角理解和審視了 Kubernetes，并基于Kubernetes為用戶(hù)提供了4個(gè)微服務(wù)視圖：

目前 Kuboard 已經(jīng)可以免費(fèi)供大家使用，感性的朋友可訪問(wèn) www.kuboard.cn 獲得詳細(xì)的信息。

四、高可用kubernetes集群搭建

架構(gòu)說(shuō)明

Kubernetes集群組件:

k8s集群高可用，一般是etcd，kube-apiserver，kube-controller-manager，kube-scheduler服務(wù)組件的高可用。

規(guī)劃：

3個(gè)master節(jié)點(diǎn)，2個(gè)worker節(jié)點(diǎn)，使用keepalived+haproxy做高可用

一、前期環(huán)境準(zhǔn)備

Kubernetes 1.8開(kāi)始要求關(guān)閉系統(tǒng)的Swap，如果不關(guān)閉，默認(rèn)配置下kubelet將無(wú)法啟動(dòng)。

方法一通過(guò)kubelet的啟動(dòng)參數(shù)–fail-swap-on=false更改這個(gè)限制。

方法二關(guān)閉系統(tǒng)的Swap， swapoff -a

修改/etc/fstab文件，注釋掉SWAP的自動(dòng)掛載，使用free -m確認(rèn)swap已經(jīng)關(guān)閉。

二、docker安裝

安裝docker-ce，所有節(jié)點(diǎn)都要安裝

yum-utils 提供yum-config-manager工具，devicemapper存儲(chǔ)需要device-mapper-persistent-data和lvm2

添加yum源倉(cāng)庫(kù)

官方倉(cāng)庫(kù)

安裝docker

配置docker中國(guó)鏡像加速器，修改cgroup driver為systemd，k8s建議使用systemd，配置后重啟docker

三、安裝haproxy，keepalived

安裝haproxy和keepalived，實(shí)現(xiàn)kube-apiserver高可用

psmisc提供killall命令

配置haproxy

配置keepalived

注意：在另外兩個(gè)節(jié)點(diǎn)，設(shè)置state為BACKUP，priority設(shè)置為110,100

啟動(dòng)所有節(jié)點(diǎn)的haproxy和keepalived

查看VIP

注意，使用ifconfig命令是看不到的，必須使用ip addr命令

這時(shí)候vip在130.252.10.235上，我們關(guān)閉235上的haproxy，驗(yàn)證vip是否會(huì)漂移到其他節(jié)點(diǎn)

四、kubeadm/kubelet/kubectl安裝

master節(jié)點(diǎn)安裝：kubeadm、kubelet、kubectl

node節(jié)點(diǎn)安裝：kubeadm、kubelet

安裝

五、使用kubeadm初始化cluster

step1 準(zhǔn)備初始化配置文件

根據(jù)自己的環(huán)境修改配置.

step2 處理kubernetes依賴(lài)的鏡像

master需要的鏡像為

node節(jié)點(diǎn)需要的鏡像為

查看需要的鏡像版本

拉取鏡像

六、初始化第一個(gè)master節(jié)點(diǎn)

注意：如果你禁用了swap分區(qū)，則不需要加--ignore-preflight-errors=Swap

配置kubectl

啟用kubectl的自動(dòng)補(bǔ)全命令

七、安裝Pod網(wǎng)絡(luò)flannel

八、將其他master節(jié)點(diǎn)添加到cluster

將node1證書(shū)文件復(fù)制到其他master節(jié)點(diǎn)node2，node3

分別在master1和master2 執(zhí)行下面的命令

九、將node節(jié)點(diǎn)添加到cluster

十、檢查集群運(yùn)行健康

在master節(jié)點(diǎn)查看節(jié)點(diǎn)狀態(tài)

所有的節(jié)點(diǎn)都是NotReady，這是因?yàn)槊總€(gè)節(jié)點(diǎn)都需要啟動(dòng)若干組件，這些組件都是在pod中運(yùn)行，需要從Google下載鏡像

查看pod的狀態(tài)

查看集群信息

查看etcd集群

查看集群是否健康

查看集群的leader

注意：因?yàn)槭?個(gè)節(jié)點(diǎn)的ETCD集群，所以只能有一個(gè)宕機(jī)，如果同時(shí)又2個(gè)節(jié)點(diǎn)宕機(jī)，則會(huì)出現(xiàn)問(wèn)題Unable to connect to the server: EOF

etd集群需要大多數(shù)節(jié)點(diǎn)（仲裁）才能就集群狀態(tài)的更新達(dá)成一致，所以ETCD集群節(jié)點(diǎn)一般是奇數(shù)個(gè)，而且只有存活節(jié)點(diǎn)個(gè)數(shù)大于下線(xiàn)節(jié) 點(diǎn)個(gè)數(shù)才能正常運(yùn)行，5個(gè)節(jié)點(diǎn)的ETCD集群，允許同時(shí)2個(gè)節(jié)點(diǎn)故障。

一般建議5個(gè)節(jié)點(diǎn)，超過(guò)五個(gè)雖然容錯(cuò)性更高，但是集群寫(xiě)入性就會(huì)差。

檢查IPVS

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