營(yíng)口汽車網(wǎng)站建設(shè),建筑網(wǎng)站大全玻璃,網(wǎng)站優(yōu)化外鏈怎么做,網(wǎng)站制作的公司k8s 架構(gòu)K8s 屬于經(jīng)典的主從模型#xff08;Master-Slave 架構(gòu)#xff09;#xff0c;由 Master 和 Node 節(jié)點(diǎn)構(gòu)成#xff1a;Master 節(jié)點(diǎn)#xff1a;負(fù)責(zé)集群的管理#xff0c;協(xié)調(diào)集群中的所有活動(dòng)。例如應(yīng)用的運(yùn)行、修改、更新等。Node 節(jié)點(diǎn)#xff1a;為 Kubernetes…k8s 架構(gòu)K8s 屬于經(jīng)典的主從模型Master-Slave 架構(gòu)由 Master 和 Node 節(jié)點(diǎn)構(gòu)成Master 節(jié)點(diǎn)負(fù)責(zé)集群的管理協(xié)調(diào)集群中的所有活動(dòng)。例如應(yīng)用的運(yùn)行、修改、更新等。Node 節(jié)點(diǎn)為 Kubernetes 集群中的工作節(jié)點(diǎn)可以是 VM 虛擬機(jī)、物理機(jī)。每個(gè) node 上有一個(gè) Kubelet負(fù)責(zé)每個(gè)節(jié)點(diǎn)的運(yùn)行狀態(tài)以及與 master 節(jié)點(diǎn)通信執(zhí)行 master 節(jié)點(diǎn)的指令同時(shí) Node 節(jié)點(diǎn)上至少還需要運(yùn)行 container runtime比如 docker這樣才能夠運(yùn)行相關(guān)鏡像。簡(jiǎn)單的示意圖架構(gòu)圖如下所示image完整的架構(gòu)圖如下所示其中 Node 中的 pod 可以理解為運(yùn)行應(yīng)用程序的容器例如運(yùn)行java的一個(gè)微服務(wù)jar包至于其他的組件將在后面進(jìn)行詳細(xì)介紹。image2. Master 節(jié)點(diǎn)Master節(jié)點(diǎn)是整個(gè)k8s的大腦imageMaster 節(jié)點(diǎn)也被稱之為控制平面組件也就是上圖中紅色框中的區(qū)域。Master 節(jié)點(diǎn)一般來說由如下構(gòu)成kube-apiserver提供 RESTful API供用戶、kubectl、其他組件和外部系統(tǒng)調(diào)用。無(wú)狀態(tài)可水平擴(kuò)展通常部署多個(gè)實(shí)例實(shí)現(xiàn)高可用。etcd分布式鍵值數(shù)據(jù)庫(kù)存儲(chǔ)集群的所有配置數(shù)據(jù)和狀態(tài)信息如節(jié)點(diǎn)、Pod、Service 等對(duì)象的狀態(tài)配置文件。所有組件通過 apiserver 讀寫 etcd不直接訪問。一般來說是部署多個(gè)節(jié)點(diǎn)使用 Raft 協(xié)議保證一致性。kube-scheduler負(fù)責(zé) Pod 的調(diào)度決定將新創(chuàng)建的 Pod 分配到哪個(gè) Node 上運(yùn)行。kube-controller-manager圖中 c-m運(yùn)行控制器進(jìn)程確保集群的實(shí)際狀態(tài)與期望狀態(tài)一致。這句話聽起來似乎有點(diǎn)抽象但是實(shí)際上我們可以把它理解為一個(gè)管家它不斷檢查集群的“實(shí)際狀態(tài)”并努力讓它與用戶定義的“期望狀態(tài)”保持一致。 例如說我希望我的集群中有 3 個(gè) nginx pod 在運(yùn)行通過相關(guān)配置文件進(jìn)行定義突然有一個(gè) pod 掛了gg 了那么 c-m 就會(huì)重新拉起來一個(gè) pod執(zhí)行順序如下c-m 從 apiserver 讀取“期望狀態(tài)”比如 replicas: 3從 apiserver 讀取“當(dāng)前實(shí)際狀態(tài)”比如現(xiàn)在只有 2 個(gè) Pod 在運(yùn)行如果不一致 → 執(zhí)行操作比如創(chuàng)建 1 個(gè)新 Pod寫回 apiserver更新狀態(tài)休息一會(huì)兒然后重復(fù)步驟 15cloud-controller-manager圖中 c-c-m是 Kubernetes 與底層云平臺(tái)如 AWS、Azure、阿里云等之間的“翻譯官”和“對(duì)接員”專門處理那些需要和云廠商 API 交互的功能。3. Node 節(jié)點(diǎn)Master 節(jié)點(diǎn)我們已經(jīng)理解了那么什么是 Node 節(jié)點(diǎn)呢。Node 節(jié)點(diǎn)也稱之為 Worker 節(jié)點(diǎn)就是真正“運(yùn)行應(yīng)用”的 worker。在現(xiàn)實(shí)世界Node 節(jié)點(diǎn)可以是一臺(tái)物理服務(wù)器一臺(tái) VM 虛擬機(jī)一個(gè) Node 節(jié)點(diǎn)嚴(yán)格對(duì)應(yīng)一臺(tái)“計(jì)算實(shí)例”但是注意Node 節(jié)點(diǎn)不是容器Node 是運(yùn)行容器的宿主機(jī)。下圖中紅色框框里面的內(nèi)容便是 Node 節(jié)點(diǎn)。imageNode 節(jié)點(diǎn)主要包含如下組件kubelet負(fù)責(zé)與 Master 通信、接收調(diào)度指令、調(diào)用容器運(yùn)行時(shí)啟動(dòng)或終止 Pod并向 api-server 持續(xù)上報(bào)節(jié)點(diǎn)和容器的健康狀態(tài)。執(zhí)行探針掛載卷設(shè)置網(wǎng)絡(luò)等等。每個(gè) node 必須要有一個(gè) kubelet。Container Runtime容器運(yùn)行時(shí)根據(jù) kubelet 的指令拉取鏡像、創(chuàng)建/啟動(dòng)/停止容器管理容器的生命周期。如果簡(jiǎn)單的理解你就可以把他看成一個(gè) docker可以運(yùn)行相關(guān)的鏡像。kube-proxy在 每個(gè) Node 上維護(hù)網(wǎng)絡(luò)規(guī)則如 iptables 或 IPVS將訪問流量Service 的流量轉(zhuǎn)發(fā)到后端 Pod。每個(gè) Node 都需要運(yùn)行 kube-proxy因?yàn)槿绻粋€(gè)容器不跟外界通信那么也毫無(wú)意義。cAdvisor用于自動(dòng)發(fā)現(xiàn)并收集當(dāng)前 Node 節(jié)點(diǎn)上所有容器包括 Pod 中的容器的資源使用情況和性能數(shù)據(jù)比如 CPU、內(nèi)存、磁盤 I/O、網(wǎng)絡(luò)使用率等。4. 命名空間k8s 集群在搭建好之后需要提供給多個(gè)部門或者小組進(jìn)行使用。而在我們開發(fā)和生產(chǎn)過程中大概率不同小組可能會(huì)出現(xiàn)相同的資源例如應(yīng)用服務(wù)名同時(shí)每個(gè)小組需要的計(jì)算資源數(shù)量也可能不同以及每個(gè)小組的權(quán)限也不同例如開發(fā)團(tuán)隊(duì)不能訪問生產(chǎn)環(huán)境。為了解決這個(gè)問題k8s 提出了命名空間namespace的概念默認(rèn)的命名空間是default命名空間有如下好處資源隔離不同命名空間中的資源名稱可以重復(fù)例如兩個(gè)命名空間中都可以有名為 web-app 的 Deployment。避免資源命名沖突。限制資源使用配合 ResourceQuota 和 LimitRange。權(quán)限控制RBAC可以為不同命名空間設(shè)置不同的訪問權(quán)限。例如開發(fā)團(tuán)隊(duì)只能訪問 dev? 命名空間運(yùn)維團(tuán)隊(duì)可訪問 prod。環(huán)境隔離將開發(fā)dev、測(cè)試test、預(yù)發(fā)布staging、生產(chǎn)prod環(huán)境部署在不同命名空間中便于管理。簡(jiǎn)化管理可以按命名空間批量操作資源如刪除整個(gè)命名空間及其所有資源。日志、監(jiān)控、網(wǎng)絡(luò)策略等也可以按命名空間維度配置。但是需要注意的是在 k8s 集群中不同的命名空間里面應(yīng)用其網(wǎng)絡(luò)是互通的。如果要避免網(wǎng)絡(luò)互通則需要進(jìn)行相關(guān)的網(wǎng)絡(luò)配置。在比較大型的網(wǎng)絡(luò)開發(fā)中還是推薦將生產(chǎn)和測(cè)試集群分開部署而不是依賴于命名空間進(jìn)行隔離。