Kubernetes 架構圖

每日分享最新,最流行的軟體開發知識與最新行業趨勢,希望大家能夠一鍵三連,多多支援,跪求關注,點贊,留言。

你知道 Kubernetes 架構圖是什麼嗎?Kubectl、微服務、無伺服器計算、Kubernetes、AWS、容器、Fluentd、pod、節點或擴充套件怎麼樣?

如今,您可能在生活中的某個階段聽說過很多計算術語,但您可能還無法完全瞭解 IT。

即使您熟悉所有這些術語,您是否瞭解它們的上下文?

如果您瞭解我到目前為止提到的所有內容,那麼您可能會考慮進一步閱讀,因為您將要了解更多。但是,如果你不熟悉上面提到的術語,請坐下來聽我說的話。

當我將 Kubernetes 主題分解為原子並逐步構建它時,您將遇到坎坷,因此您將瞭解 Kubernetes 架構圖,每個 Kubernetes 架構示例,整個結構,什麼它的用途,以及如何使用它。

因此,讓我們點選進入 IT!

什麼是 Kubernetes?

Kubernetes 叢集架構由一個主(控制)平面和一個或多個節點(工作機器)組成。或者,如果您使用 kubeadmn、kops 等 Kubernetes 自我管理的服務,它可能會更多。

這兩個例項都可以在雲中,以虛擬機器的形式,甚至是物理裝置。但是,當涉及到 Azure AKS、GCP GKE 和 AWS EKS 等託管 Kubernetes 架構環境時,控制平面的管理由指定的雲提供商完成。

現在,當大型企業希望執行關鍵任務時,他們會使用 Kubernetes,因為它是一個用於容器管理的開源系統,是滿足他們需求的完美解決方案。為什麼 Kubernetes 如此出色?這是它可以做的:

Kubernetes 架構圖

除了其基本的框架功能外,Kubernetes 在其他方面也很有幫助。它允許使用者從各種選項中進行選擇,例如語言、日誌記錄和監控工具、應用程式框架的型別,以及使用者可能需要的許多其他有價值的工具。

Kubernetes 本身不是平臺即服務 (PaaS),但您可以將其用作完整的 PaaS 起始基礎。

自從 Kubernetes 出現在市場上以來,它已經成為一種非常流行的工具,也是當今最成功的開源平臺之一。

為什麼我們需要 Kubernetes?

Kubernetes 的唯一目的是以自動化方式和容器形式託管您的應用程式。這允許您根據需要部署儘可能多的應用程式例項,但這還不是全部。您還可以在應用程式中找到的所有服務之間啟用可訪問的通訊。

聽起來不可思議;你可能會想,“Kubernetes 有什麼不能做的嗎?” 你這樣想也沒錯。

我們需要 Kubernetes 僅僅是因為它允許我們在所有可用資源上有效地分配我們的工作負載,但它也允許我們最佳化基礎設施成本。此外,Kubernetes 具有可擴充套件性、高可用性、可移植性和安全性等幾個王牌。

可擴充套件性

Kubernetes 中部署的所有應用程式都稱為微服務,它們由許多容器組成,這些容器進一步分組為 Pod。從這裡開始,每個容器在邏輯上都被設計為執行一個單一的任務。

高可用性

幾乎所有容器編排引擎都可以提供應用程式可用性。然而,Kubernetes 的高可用架構的存在是為了實現基礎設施和應用程式的可用性。它還透過利用複製控制器、寵物集和副本集來確保應用程式前端的高可用性。

Kubernetes 在應用程式前端使用複製控制器、副本集和寵物集來確保高可用性。此外,使用者可以隨時設定最小執行 Pod 數。

此外,Kubernetes(高可用性)支援基礎設施可用性,包括廣泛的儲存後端。其中包括塊儲存裝置,如 Amazon Elastic Block Store (EBS)、Google Compute Engine 永久磁碟等。

此外,它還支援 NFS、GlusterFSand 等分散式檔案系統和 Flocker 等專用容器儲存外掛。

可移植性

Kubernetes 的設計在作業系統、容器執行時、雲平臺、PaaS 和處理器架構方面提供了多種選擇。此外,您可以在不同的 Linux 發行版上配置 Kubernetes 叢集,例如 CentOs、Debian、Fedora、CoreOS、Ubuntu 和 Red Hat Linux。

您可以將其部署為在基於 KVM、libvirt 和 vSphere 的本地或虛擬環境中執行。

Kubernetes 的無伺服器架構能夠在 Google Cloud、Azure 和 AWS 等雲平臺上執行。儘管如此,如果您跨雲提供商或本地混合和匹配叢集,您也可以建立混合雲。

安全

談到 Kubernetes 安全性,應用程式架構在多個級別上進行了安全配置。

Kubernetes 優勢

Kubernetes 的主要優勢是巨大的,這就是 Kubernetes 必須提供的:

Kubernetes 架構圖

自動裝箱

Kubernetes 將自動打包您的應用程式並根據所有可用資源和要求建立容器排程,而不會犧牲可用性。因此,Kubernetes 將在盡力而為和關鍵工作負載之間取得平衡,以節省未使用的資源並確保完全利用。

負載平衡和服務發現

由於 Kubernetes 會自動為容器分配 IP 地址,因此可以讓您在網路和通訊方面放心。此外,對於一組容器,它提供了一個單一的 DNS 名稱,用於對叢集內的流量進行負載平衡。

儲存編排

Kubernetes 允許您選擇要掛載的系統儲存。您可以選擇 AWS、GCP 甚至本地儲存等公共雲提供商。此外,您可以使用 iSCSI、NFS 等共享網路儲存系統。

自我修復

Kubernetes 能夠自動重啟所有在執行期間失敗的容器。此外,它將殺死所有不響應使用者先前定義的健康檢查的容器。最後,如果節點死亡,它將重新排程並替換所有其他可用節點中的所有失敗容器。

秘密和配置管理

Kubernetes 可以幫助您更新和部署機密和應用程式配置,而無需重建映像並在堆疊配置中公開機密。

批次執行

除了管理服務之外,Kubernetes 還可以處理您的批處理和 CI 工作負載,如果需要,它們將替換失敗的容器

水平縮放

Kubernetes 需要一個命令來擴充套件容器,但它也可以使用 CLI 縮小容器。您可以透過 Kubernetes UI 中的儀表板執行擴充套件。

自動回滾和轉出

Kubernetes 可以逐步推出對您的應用程式或其配置的更新和更改。如果出現問題,Kubernetes 可以並且將會回滾更改。

這些是 Kubernetes 架構圖的一些最關鍵的優勢,但這並不是 Kubernetes 提供的全部。因此,讓我們更深入地瞭解 Kubernetes 更有吸引力的方面及其實際用例。

Kubernetes 和在企業和公司中的採用

您會驚訝地發現超過 25,000 家公司使用 Kubernetes 叢集架構。大多數使用 Kubernetes 的公司都來自美國,從事 CS(計算機軟體)行業。

據 Enlyft 稱,過去五年Kubernetes 資料使用情況和有關 Kubernetes 使用統計的資料更加透明。

使用 Kubernetes 的企業擁有 100 萬至 1000 萬美元的收入和 10-50 名員工。這些公司是小型企業,佔使用 Kubernetes 的企業的 38%。

此外,使用 Kubernetes 的公司中有 43% 是擁有 50-1000 名員工的中型公司。最後,使用 Kubernetes 架構的企業中有 19% 是擁有超過 1000 名員工的大公司。

一些在其工作流程中使用 Kubernetes 的著名公司包括 Shopify、Google、Udemy、Slack 等。

為什麼這些公司使用 Kubernetes?這就是為什麼。

在本地執行 Kubernetes 背後的原因

當企業在其資料中心中實施 Kubernetes 架構圖而不是替代方案(公共雲提供商)時,這變成了一件大事。很自然,這幾個基本因素對於公司決定 Kubernetes 本地戰略實施至關重要:

經營方針

每個企業都有特定的業務策略要求,例如需要在準確指定的地理位置執行工作負載。如果您考慮特定的策略需求集,您就會理解為什麼企業可能難以利用公共雲。

此外,如果提及的業務對其競爭有嚴格的業務政策,一些公司可能不會接受來自各種公共雲提供商的報價。

避免鎖定

許多企業希望避免使用來自一個雲提供商的服務,因為他們可能希望在多個雲中部署他們的應用程式。這包括本地(私有)雲。因此,企業將降低由於某些雲提供商的問題而造成的永久性影響的風險。

此外,這使公司有機會與雲提供商協商更好的價格。

成本

在規模上,在公共雲中執行應用程式的成本可能很高,而成本效益可能是在本地使用 Kubernetes 的最重要原因。

此外,如果您的應用程式依賴於處理和攝取大量資料,您可以期望支付高昂的費用在公共雲環境中執行它們。

另一方面,由於現有資料中心,利用“內部”Kubernetes 將顯著降低運營成本。

資料隱私和合規

一些組織針對資料隱私和合規問題制定了規定。例如,如果公司的服務巢狀在特定的公共雲中,這些規則可能會阻止公司為世界各地的客戶提供服務。

您將使用自己的資料中心有效地將您的應用程式現代化為雲原生格式。如果您選擇退出 Kubernetes 本地部署,您將顯著改變您的業務。像這樣的有效策略將幫助您節省大量資金,同時無疑會改善基礎設施的使用。

為什麼需要容器來使用 Kubernetes?

想要將其應用程式容器化的公司必須大規模使用容器,因為他們不使用一兩個容器,而是使用數十個甚至上百個容器,以確保高可用性和負載平衡流量。

接下來發生的事情是他們必須擴大集裝箱數量。當流量每秒都在增加時,需要“擴充套件”過程來服務“n”個請求。或者,在需求低的情況下,您應該縮減容器數量。

老實說,即使這是可能的,您也只能在涉及管理這些容器的大量手動工作之後才能做到這一點。因此,在我腦海中徘徊的問題是,這一切是否值得麻煩。自動化干預會讓您的生活更輕鬆並節省您數小時的體力勞動嗎?毫無疑問會的!

因此,容器管理工具至關重要。有許多著名的容器編排和管理工具可用,但 Kubernetes 是市場的領導者。它受歡迎的原因是它無與倫比的功能以及它是谷歌產品的事實。

因此,選擇 Kubernetes 的一個很好的理由是基於流量需求的容器自動擴充套件。

Kubernetes 架構及其元件

Kubernetes 架構圖的元件是節點(一組機器)和控制平面。現在,讓我們更深入地瞭解這些元件。

Kubernetes 架構圖

Kubernetes 中的主節點是什麼?

Master Node 是所有管理任務的起點,它的職責是管理 Kubernetes 叢集架構。

叢集中可能有多個主節點,並且隨著更多主節點檢查容錯性所需的操作將使系統處於稱為“高可用性”的模式。

但是,一個主節點具有執行所有任務的主節點的角色。

主節點元件

Kubernetes API 伺服器

主節點內的 API 伺服器是執行所有管理任務的地方。

REST 命令然後轉到將處理和驗證請求的 API 伺服器。

根據請求,叢集的結果狀態將基於分散式鍵值進行儲存。

排程器

該元件將任務排程到指定的從節點。此外,每個從節點都會儲存資源使用資訊。

Scheduler 會以 Services 和 Pod 的形式排程所有的工作。

在任務排程之前,排程器會考慮服務需求質量、親和性、反親和性、資料區域性性等。

控制管理器

控制管理器被稱為控制器,它是一個調整 Kubernetes 叢集的守護程序。Kubernetes 叢集用於管理各種非終止控制迴圈。

這個元件還有其他一些事情,比如節點垃圾收集、事件垃圾收集、級聯刪除垃圾收集。此外,它還具有建立名稱空間等生命週期功能。

本質上,控制器檢視託管物件的所需狀態,但它也使用 API 伺服器來忽略和管理其當前狀態。如果未滿足物件的期望狀態,則控制迴路將透過採取特定步驟來確保平衡當前和期望狀態以實現該目標。

ETCD

該元件分發一個鍵值儲存,最終使用叢集狀態進行儲存。

您可以在外部配置 ETCD,甚至可以將其作為 Kubernetes Master 的一部分。

“Go”程式語言是人們用來編寫 ETCD 的一種語言。在 Kubernetes 中,您可以儲存 Secrets、ConfigMaps、子網等配置詳細資訊,並存儲叢集狀態。

高層次的 Kubernetes 架構

當談到高層時,Kubernetes 架構由幾個部分組成,如控制平面(主節點)、幾個 Kubelet(叢集節點)和 ETCD(有助於保持叢集狀態一致的分散式儲存系統)。

控制平面在這一切中去哪裡?

控制平面是一個特定的系統,它永久地管理物件狀態,幫助匹配系統物件的實際和期望狀態,並響應叢集內的任何變化。

控制平面由三個基本元件組成——kKubescheduler、kKubeapiserver 和 kKubecontroller-manager。這些元件將透過單個主節點執行,甚至可以在多個主節點中複製(高可用性)。

Kube 排程器

元件會忽略沒有分配節點的新建立的 Pod,並選擇它們將執行的節點。

排程決策基於幾個因素,包括資料區域性性、工作負載間的干擾、軟體/硬體/策略限制、資源需求(個人和集體)、親和性和反親和性規範以及截止日期。

這是 Apiserver

kKubeapiserver 元件作為 API 伺服器的主要實現元件。此外,它透過部署額外的例項進行擴充套件(水平擴充套件)。可以執行多個例項並平衡它們之間的流量。

API 伺服器公開了 Kubernetes API,它是 Kubernetes 控制平面的前端元件。

Kube-Controller-Manager

即使每個控制器都是一個獨立的程序,您也可以將多個控制器合併為一個二進位制檔案,但為了降低複雜性,它將作為單個程序執行。

這些是一些控制器型別:

節點控制器

——在節點關閉時通知和響應。

作業控制器

——監視作業物件(一次性任務)並建立完成任務的 Pod。

Endpoints 控制器

——填充 Endpoints 物件(合併 Pod 和服務)。

令牌控制器和服務帳戶

——建立新名稱空間所需的預設帳戶和 API 訪問令牌。

工作節點架構

工作節點透過 Pod 執行應用程式,主節點控制 Pod。Pod 排程在物理伺服器(從節點)上。因此,當您想從外部環境訪問應用程式時,您必須連線到這些節點。

工作節點元件

1. 容器執行時

Worker Node 需要一個容器執行時來管理和執行容器的生命週期。

Docker 經常被混淆為容器執行時,但它是一個以這種方式利用容器的平臺。

2. 庫貝萊特

Kubelet 與主節點通訊並在工作節點上執行。它透過 API 伺服器獲取 Pod 規格。此外,它執行健康且積極執行的 Pod 中描述的相關容器。

3. cAdvisor

cAdvisor 用於分析在指定節點上執行的每個容器的網路使用情況、檔案、CPU 和記憶體的所有指標。您應該找到一個好的監控工具,因為 cAdvisor 沒有提供長期儲存解決方案。

您無需採取特定步驟來安裝 cAdvisor,因為它集成了 kubelet 二進位制檔案。

4. 快速 Kubelet 工作流程圖

一個更實用的解決方案是向您展示 Kubelet 工作流程的圖解圖表,以便您更好地瞭解它是如何工作的。您將在下面看到 Kubelet 工作流程的詳細而快速的介紹。

Kubernetes 架構圖

5. 代理

Kube-proxy 在每個節點上執行,它與每個主機子網分開工作,以確保外部各方可以訪問所有服務。

它還充當位於工作節點上的任何服務的負載平衡器和網路代理的角色。此外,Kubee-proxy 將管理 UDP 和 TCP 資料包的網路路由。

網路代理在每個工作節點上執行,並遵循每個服務端點的 API 伺服器(刪除/建立)。

為了讓 Kube-proxy 到達服務端點,它建立了不同的路由。

Kubernetes 概念、工具、部署和其他重要元素

ETCD

深入瞭解 Kubernetes 架構圖的表面總是很有趣,而 ETCD 是一個偉大的 Kubernetes 架構示例的關鍵元素。Kubernetes 將所有叢集狀態資訊儲存在 ETCD 中,被稱為控制平面的唯一有狀態元素。

ETCD 高度一致,使其成為錨協調點。此外,得益於 Raft 共識演算法,ETCD 具有高可用性。

ETCD 的另一個出色功能是它能夠將更改流式傳輸到客戶端。這有助於所有 Kubernetes 叢集元件保持同步。

Kubectl

這是 Kubernetes 的命令列工具,它可以幫助您執行命令。此外,Kubectl 有利於管理和檢查叢集資源、檢視日誌和應用程式部署。

Kubectl 使使用者能夠控制訪問以執行任何 Kubernetes 操作。從更技術的角度來看,kubectl 是 Kubernetes API 的客戶端。

Kubernetes 網路

“IP-per-pod”模型是 Kubernetes 的運作方式。這意味著每個 pod 都被分配了一個 IP 地址。此外,位於單個 pod 中的容器將共享相同的 IP 地址和網路名稱空間。

網路 Kubernetes 有一個獨特的網路模型,適用於 pod 到 pod 和叢集範圍的網路。

通常,CNI(容器網路介面)會使用覆蓋網路,透過 VXLAN(流量封裝)來隱藏 Pod 的底層網路。此外,它可以利用完全路由的其他解決方案。無論它使用哪種解決方案,叢集範圍的 pod 網路都是 pod 進行通訊的地方,而 CNI 提供者管理這種通訊。

Pod 內沒有任何限制,因此容器之間可以相互通訊,因為在 Pod 中,容器共享相同的 IP 地址和網路名稱空間。

這是什麼意思呢?首先,這意味著容器的通訊是透過 localhost 完成的。其次,Pod 之間的通訊是可能的,這要歸功於 Pod IP 地址。

Kubernetes 中的儲存

Kubernetes 基於卷的概念,本質上,卷是一個目錄,其中可能包含一些 pod 可以訪問的資料。但是,特定卷型別的使用決定了它的內容,選擇了備份這個目錄的介質,以及這個目錄最初是如何形成的。

一個 pod 中的任何容器都能夠消耗同一個 pod 中的儲存。最初,當 Pod 重新啟動時,儲存將繼續存在,但在刪除 Pod 後會發生什麼取決於儲存型別。

各種可用選項將允許您將塊儲存和檔案儲存掛載到 pod,最流行的是雲端儲存服務,如 gcePersistentDisk 和 AWS EBS。或者,iSCSI、Flocker、NFS、CephFS 和 glusterFS 等物理儲存也是可以考慮的選項。

此外,管理員可以為您提供 PersistentVolumes (PV) 儲存解決方案。PV 是叢集範圍的物件,它們進一步連結到後備儲存提供程式,允許您使用這些資源。所以 PV 所做的就是繫結到已經存在的儲存資源。

PersistentVolumeClaim 將為同一名稱空間下的每個 pod 建立一個儲存消耗請求。但是,根據使用情況,它可以具有不同的狀態或階段。這些狀態被稱為可用、繫結、釋放和失敗。

最後,StorageClasses 是一個抽象層,可以讓您看到底層儲存的質量差異。此外,運營商使用 StorageClasses 來描述不同的儲存型別,它根據來自每個 pod 的所有傳入宣告為儲存提供動態配置。

Kubernetes 概念

要使 Kubernetes 架構圖實用,您必須瞭解該架構用來表示 Kubernetes 系統內狀態的各種抽象。

Pod

– 由一個或多個容器控制的單個應用程式。一個 pod 包含一個唯一的網路 ID、應用程式容器和儲存資源,以確定它將如何執行容器。

服務

——Pod 很容易發生變化。因此,Kubernetes 無法保證物理 pod 將保持活動狀態(如果複製控制器結束並以新 pod 開始)。

相反,該服務將顯示一組邏輯 pod,但它也將扮演閘道器的角色。這意味著您不必跟蹤組成服務的 pod,因為 pod 將能夠向服務傳送請求。

NameSpace

– 是一個虛擬叢集,可在多個專案的多個使用者的環境中工作。值得一提的是,一個物理叢集可以同時執行多個虛擬叢集。

名稱空間中的資源必須是唯一的,並且它們不會被授予訪問另一個名稱空間的許可權。此外,可以為名稱空間分配資源配額,這樣您就可以避免過度消耗物理叢集中的整體資源。

Volume

——在 Kubernetes 中,卷將應用於整個 pod。因此,它將安裝在位於指定 pod 中的所有容器上。即使容器重啟,Kubernetes 也可以保證所有資料都會被儲存。但是,如果 pod 被殺死,volume 也會消失。一個 pod 可以有許多不同型別的卷。

部署

——這個概念描述了 pod 的期望狀態或其副本集,通常在 yaml 檔案中。在部署檔案中指定的當前和預期狀態匹配之前,部署控制器將緩慢更新環境。此環境更新包括刪除或建立副本。

yaml 檔案的作用是為每個 pod 定義兩個副本。但是,當只有其中一個在執行時,yaml 檔案定義也會建立另一個。因此,重要的是要知道在部署管理副本時不應直接操作它們。請改用新的部署。

Kubernetes Supervisord

管理和建立流程是主管的主要工作。但是,這些過程的起點是其配置檔案中的資料。如果您想知道主管是如何做到這一點的,答案很簡單——它會建立子流程。

只要子程序處於活動狀態,Supervisord 就會管理它建立的每個子程序。這就是為什麼監督者被稱為子程序的“後代”的父程序。

Fluentd

Fluentd 是一個流行的開源資料收集器,您可以在 Kubernetes 節點上進行設定。您將快速轉換和過濾日誌資料,並在設定後跟進容器日誌檔案。您將能夠將它們傳送到 Elasticsearch 叢集,以便索引和儲存資料。

JSON 統一日誌記錄

——Fluentd 將盡可能嘗試將資料結構化為 JSON。這對於處理日誌資料很重要,因為 Fluentd 會統一它們。處理日誌資料包括過濾、收集跨多個目的地和源的日誌輸出以及緩衝。

可插拔架構

——社群能夠擴充套件功能,這要歸功於 Fluentd 擁有的靈活的外掛系統。此外,這些外掛將連線多個數據輸出和資料來源。Fluentd 外掛是有益的,因為它們允許更好、更直接的日誌使用。

內建可靠性

——由於此資料收集器使用基於檔案的緩衝並支援記憶體,它可以防止您在節點間丟失有價值的資料。此外,您可以將其設定為高可用性,但請記住,它在應對艱難的故障轉移方面也表現出色。

所需資源最少

——這個開源收集器佔用的系統資源最少,因為它是用 Ruby 和 C 語言組合編寫的。

Kubernetes Deployment

Deployment 為 Kubernetes 提供了修改或建立承載容器化應用程式的 pod 例項的說明。部署可以實現許多目標,例如在受控環境中啟用更新程式碼、擴充套件副本 pod 數量以及將程式碼回滾到以前的部署版本以防您需要回滾。

Deployment優勢

Kubernetes 部署給我們帶來的最有意義的好處是關於各種重複功能(擴充套件、更新生產應用程式、部署)的自動化系統。

此外,自動 pod 例項啟動機制讓您放心,因為現在您可以放心,您的例項將按預期執行並跨叢集內的所有節點執行。從本質上講,自動化程度越高越好。即使您的部署速度更快,您也會遇到更少的錯誤。

由於對節點和 Pod 的持續健康和效能監控,Kubernetes 部署可以繞過出現故障的節點,甚至替換失敗的 Pod。透過這樣做,部署控制器可以輕鬆替換 pod,最終目標是確保所有重要應用程式的無縫工作。

結論

Kubernetes 架構圖一開始並不是一個容易理解的系統,但是當你這樣做時,你的生活和工作時間會變得容易得多。

我們瞭解到,Kubernetes 被證明是一種出色的擴充套件解決方案,支援多樣化和解耦的有狀態和無狀態工作負載,並提供自動回滾和部署。儘管如此,它還是一個很棒的平臺,允許您編排您的應用程式(基於容器)。

今天我們一起經歷了很多資訊。我只是希望您對 Kubernetes 以及它是什麼以及它是如何工作的有更好的瞭解。如果有任何問題,您可能想知道我們還沒有討論過,請聯絡我們,我們團隊的專業人員將幫助您解決任何問題。