前言

本文關(guān)于 Kubernetes 架構(gòu)的綜合指南旨在通過插圖詳細(xì)解釋每個 Kubernetes 組件。

• 了解 Kubernetes 的架構(gòu)。
• 掌握 Kubernetes 的基本概念。
• 了解 Kubernetes 架構(gòu)組件。
• 探索連接這些組件的工作流。

一、什么是 Kubernetes 架構(gòu)？

以下 Kubernetes 架構(gòu)圖顯示了 Kubernetes 集群的所有組件以及外部系統(tǒng)如何連接到 Kubernetes 集群。

關(guān)于 Kubernetes，應(yīng)該了解的第一件事是，它是一個分布式系統(tǒng)。即它有多個組件分布在網(wǎng)絡(luò)上的不同服務(wù)器上。這些服務(wù)器可以是虛擬機(jī)或裸機(jī)服務(wù)器。我們稱之為 Kubernetes 集群。

Kubernetes 集群由控制平面節(jié)點(diǎn)和工作節(jié)點(diǎn)組成。

1.1、控制平面

控制平面負(fù)責(zé)容器編排和維護(hù)集群的所需狀態(tài)。它具有以下組件。

1. kube-api服務(wù)器。
2. etcd。
3. kube-調(diào)度程序。
4. kube-控制器管理器。
5. 云控制器管理器。

1.2、工作節(jié)點(diǎn)

Worker 節(jié)點(diǎn)負(fù)責(zé)運(yùn)行容器化應(yīng)用程序。worker 節(jié)點(diǎn)具有以下組件。

• kubelet。
• kube-代理。
• 容器運(yùn)行時。

二、Kubernetes 控制平面組件

首先看一下每個控制平面組件以及每個組件背后的重要概念。

2.1、kube-api服務(wù)器

kube-api 服務(wù)器是公開 Kubernetes API 的 Kubernetes 集群的中心樞紐。

最終用戶和其他集群組件通過 API 服務(wù)器與集群通信。在極少數(shù)情況下，監(jiān)控系統(tǒng)和第三方服務(wù)可能會與 API 服務(wù)器通信以與集群進(jìn)行交互。

因此，當(dāng)使用 kubectl 管理集群時，在后端實(shí)際上是通過 HTTP REST API 與 API 服務(wù)器進(jìn)行通信。但是，內(nèi)部集群組件（如調(diào)度程序、控制器等）使用 gRPC 與 API 服務(wù)器通信。

API 服務(wù)器與集群中的其他組件之間的通信通過 TLS 進(jìn)行，以防止對集群進(jìn)行未經(jīng)授權(quán)的訪問。

Kubernetes api-server 負(fù)責(zé)以下工作：

1. API 管理：公開集群 API 終端節(jié)點(diǎn)并處理所有 API 請求。
2. 身份驗(yàn)證（使用客戶端證書、持有者令牌和 HTTP 基本身份驗(yàn)證）和授權(quán)（ABAC 和 RBAC 評估）。
3. 處理 API 請求并驗(yàn)證 API 對象（如 Pod、服務(wù)等）的數(shù)據(jù)（驗(yàn)證和變更準(zhǔn)入控制器）
4. 它是唯一與etcd通信的組件。
5. api-server 協(xié)調(diào)控制平面和工作節(jié)點(diǎn)組件之間的所有進(jìn)程。
6. api-server 有一個內(nèi)置的堡壘 apiserver 代理。它是 API 服務(wù)器進(jìn)程的一部分。它主要用于啟用從群集外部訪問 ClusterIP 服務(wù)，即使這些服務(wù)通常只能在群集本身內(nèi)訪問。

注意：為了減少群集攻擊面，保護(hù) API 服務(wù)器至關(guān)重要。Shadowserver 基金會進(jìn)行了一項(xiàng)實(shí)驗(yàn)，發(fā)現(xiàn)了 380,000 個可公開訪問的 Kubernetes API 服務(wù)器。

2.2、etcd

Kubernetes 是一個分布式系統(tǒng)，它需要一個高效的分布式數(shù)據(jù)庫，如 etcd 來支持其分布式性質(zhì)。它既充當(dāng)后端服務(wù)發(fā)現(xiàn)，又充當(dāng)數(shù)據(jù)庫。可以稱它為 Kubernetes 集群的大腦。

etcd 是一個開源的強(qiáng)一致性分布式鍵值存儲。那么這意味著什么呢？

1. 強(qiáng)一致性：如果對某個節(jié)點(diǎn)進(jìn)行了更新，則強(qiáng)一致性將確保它立即更新到集群中的所有其他節(jié)點(diǎn)。此外，如果看過CAP定理，就不可能實(shí)現(xiàn)100%的可用性，并具有很強(qiáng)的一致性和&分區(qū)容差。
2. 分布式：etcd 被設(shè)計(jì)為在不犧牲一致性的情況下作為集群在多個節(jié)點(diǎn)上運(yùn)行。
3. 鍵值存儲：將數(shù)據(jù)存儲為鍵和值的非關(guān)系數(shù)據(jù)庫。它還公開鍵值 API。數(shù)據(jù)存儲建立在 BboltDB 之上，BboltDB 是 BoltDB 的一個分支。

etcd 使用 raft 共識算法，具有很強(qiáng)的一致性和可用性。它以領(lǐng)導(dǎo)者-成員的方式工作，以實(shí)現(xiàn)高可用性并承受節(jié)點(diǎn)故障。

那么 etcd 是如何與 Kubernetes 一起工作的呢？簡單地說，當(dāng)使用 kubectl 獲取 kubernetes 對象詳細(xì)信息時，是從 etcd 獲取的。此外，當(dāng)部署像 pod 這樣的對象時，會在 etcd 中創(chuàng)建一個條目。

需要了解的有關(guān) etcd 的信息：

1. etcd 存儲 Kubernetes 對象的所有配置、狀態(tài)和元數(shù)據(jù)（pod、secret、daemonsets、deployments、configmaps、statefulsets 等）。
2. etcd允許客戶端使用 API 訂閱事件。Kubernetes api-server 使用 etcd 的監(jiān)視功能來跟蹤對象狀態(tài)的變化。Watch()
3. etcd 使用 gRPC 公開鍵值 API。此外，gRPC 網(wǎng)關(guān)是一個 RESTful 代理，可將所有 HTTP API 調(diào)用轉(zhuǎn)換為 gRPC 消息。這使它成為 Kubernetes 的理想數(shù)據(jù)庫。
4. etcd 以鍵值格式存儲 /registry 目錄項(xiàng)下的所有對象。例如，可以在 /registry/pods/default/nginx 下找到默認(rèn)命名空間中名為 Nginx 的 Pod 的信息。

此外，etcd 它是控制平面中唯一的 Statefulset 組件。

2.3、kube-scheduler

kube-scheduler 負(fù)責(zé)在工作節(jié)點(diǎn)上調(diào)度 Kubernetes Pod。

部署容器時，可以指定容器要求，例如 CPU、內(nèi)存、關(guān)聯(lián)性、污點(diǎn)或容錯、優(yōu)先級、持久卷 （PV） 等。調(diào)度程序的主要任務(wù)是識別創(chuàng)建請求，并為滿足要求的 Pod 選擇最佳節(jié)點(diǎn)。

下圖顯示了調(diào)度程序工作原理的高級概述。

在 Kubernetes 集群中，將有多個工作節(jié)點(diǎn)。那么調(diào)度程序是如何從所有工作節(jié)點(diǎn)中選擇節(jié)點(diǎn)的呢？

下面是調(diào)度程序的工作原理：

1. 為了選擇最佳節(jié)點(diǎn)，Kube-scheduler 使用過濾和評分操作。
2. 在篩選中，調(diào)度程序會找到最適合調(diào)度 Pod 的節(jié)點(diǎn)。例如，如果有 5 個具有資源可用性的工作器節(jié)點(diǎn)來運(yùn)行 Pod，則它會選擇所有 5 個節(jié)點(diǎn)。如果沒有節(jié)點(diǎn)，則 Pod 不可調(diào)度并移動到調(diào)度隊(duì)列。如果它是一個大型集群，假設(shè)有 100 個工作節(jié)點(diǎn)，并且調(diào)度程序不會遍歷所有節(jié)點(diǎn)。有一個名為 的調(diào)度器配置參數(shù)。默認(rèn)值通常為 50%。因此，它試圖以循環(huán)方式迭代超過 50% 的節(jié)點(diǎn)。如果工作器節(jié)點(diǎn)分布在多個區(qū)域中，則調(diào)度程序?qū)⒈闅v不同區(qū)域中的節(jié)點(diǎn)。對于非常大的集群，默認(rèn)值為 5%。
3. 在評分階段，調(diào)度程序通過向篩選的工作器節(jié)點(diǎn)分配分?jǐn)?shù)來對節(jié)點(diǎn)進(jìn)行排名。調(diào)度程序通過調(diào)用多個調(diào)度插件進(jìn)行評分。最后，將選擇排名最高的 worker 節(jié)點(diǎn)來調(diào)度 pod。如果所有節(jié)點(diǎn)的排名相同，則將隨機(jī)選擇一個節(jié)點(diǎn)。
4. 選擇節(jié)點(diǎn)后，調(diào)度程序?qū)⒃?API 服務(wù)器中創(chuàng)建綁定事件。表示綁定 Pod 和節(jié)點(diǎn)的事件。

相關(guān)調(diào)度程序的說明：

1. 它是一個控制器，用于偵聽 API 服務(wù)器中的 Pod 創(chuàng)建事件。
2. 調(diào)度程序有兩個階段。調(diào)度周期和綁定周期。統(tǒng)稱為調(diào)度上下文。 調(diào)度周期選擇工作器節(jié)點(diǎn)，綁定周期將該更改應(yīng)用于集群。
3. 調(diào)度程序始終將高優(yōu)先級的 Pod 放在低優(yōu)先級的 Pod 之前進(jìn)行調(diào)度。此外，在某些情況下，在 Pod 開始在所選節(jié)點(diǎn)中運(yùn)行后，Pod 可能會被逐出或移動到其他節(jié)點(diǎn)。
4. 可以創(chuàng)建自定義調(diào)度程序，并在集群中運(yùn)行多個調(diào)度程序以及本機(jī)調(diào)度程序。部署 Pod 時可以在 Pod 清單中指定自定義調(diào)度程序。因此，調(diào)度決策將基于自定義調(diào)度程序邏輯進(jìn)行。
5. 調(diào)度程序具有可插拔的調(diào)度框架。即可以將自定義插件添加到調(diào)度工作流程中。

2.4、Kube 控制器管理器

什么是控制器？ 控制器是運(yùn)行無限控制循環(huán)的程序，即它連續(xù)運(yùn)行并監(jiān)視對象的實(shí)際和所需狀態(tài)。如果實(shí)際狀態(tài)和期望狀態(tài)存在差異，則確保 kubernetes 資源/對象處于期望狀態(tài)。

官方文件的描述：在 Kubernetes 中，控制器是監(jiān)視集群狀態(tài)的控制循環(huán)，然后在需要時進(jìn)行更改或請求更改。每個控制器都嘗試將當(dāng)前集群狀態(tài)移近所需狀態(tài)。

假設(shè)要創(chuàng)建部署，在清單 YAML 文件中指定所需的狀態(tài)（聲明性方法）。例如，2 個副本、1 個卷掛載、configmap 等。內(nèi)置的部署控制器可確保部署始終處于所需狀態(tài)。如果用戶使用 5 個副本更新部署，則部署控制器會識別它并確保所需的狀態(tài)為 5 個副本。

Kube 控制器管理器是管理所有 Kubernetes 控制器的組件。Kubernetes 資源/對象（如 Pod、命名空間、作業(yè)、副本集）由各自的控制器管理。此外，Kube 調(diào)度器也是由 Kube 控制器管理器管理的控制器。

重要的內(nèi)置 Kubernetes 控制器列表。

1. 部署控制器
2. Replicaset 控制器
3. DaemonSet 控制器
4. 作業(yè)控制器（Kubernetes 作業(yè)）)
5. CronJob 控制器
6. 端點(diǎn)控制器
7. 命名空間控制器
8. 服務(wù)帳戶控制器。
9. 節(jié)點(diǎn)控制器

需要了解的有關(guān) Kube 控制器管理器的信息：

• 它管理所有控制器，控制器嘗試將集群保持在所需狀態(tài)。
• 可以使用與自定義資源定義關(guān)聯(lián)的自定義控制器來擴(kuò)展 kubernetes。

2.5、云控制器管理器 （CCM）

在云環(huán)境中部署 kubernetes 時，云控制器管理器充當(dāng)云平臺 API 和 Kubernetes 集群之間的橋梁。

這樣，核心 kubernetes 核心組件可以獨(dú)立工作，并允許云提供商使用插件與 kubernetes 集成。（例如，kubernetes 集群和 AWS 云 API 之間的接口）

云控制器集成允許 Kubernetes 集群預(yù)置云資源，例如實(shí)例（用于節(jié)點(diǎn)）、負(fù)載均衡器（用于服務(wù)）和存儲卷（用于持久卷）。

云控制器管理器包含一組特定于云平臺的控制器，可確保特定于云的組件（節(jié)點(diǎn)、負(fù)載均衡器、存儲等）處于所需狀態(tài)。以下是云控制器管理器中的三個主要控制器：

1. 節(jié)點(diǎn)控制器：此控制器通過與云提供商 API 通信來更新與節(jié)點(diǎn)相關(guān)的信息。例如，節(jié)點(diǎn)標(biāo)記和注釋，獲取主機(jī)名，CPU和內(nèi)存可用性，節(jié)點(diǎn)運(yùn)行狀況等。
2. 路由控制器：它負(fù)責(zé)在云平臺上配置網(wǎng)絡(luò)路由。這樣不同節(jié)點(diǎn)的 Pod 就可以相互通信。
3. 服務(wù)控制器：它負(fù)責(zé)為 kubernetes 服務(wù)部署負(fù)載均衡器、分配 IP 地址等。

云控制器管理器的一些經(jīng)典示例：

• 部署負(fù)載均衡器類型的 Kubernetes 服務(wù)。在這里，Kubernetes 預(yù)置了特定于云的負(fù)載均衡器，并與 Kubernetes 服務(wù)集成。
• 為云存儲解決方案支持的 Pod 配置存儲卷 （PV）。

一句話：Cloud Controller Manager 管理 Kubernetes 使用的云特定資源的生命周期。

三、Kubernetes 工作節(jié)點(diǎn)組件

現(xiàn)在看一下每個工作節(jié)點(diǎn)組件。

3.1、Kubelet

Kubelet 是一個 Agent 組件，運(yùn)行在集群中的每個節(jié)點(diǎn)上。t 不作為容器運(yùn)行，而是作為守護(hù)程序運(yùn)行，由 systemd 管理。

它負(fù)責(zé)向 API 服務(wù)器注冊工作節(jié)點(diǎn)，并主要從 API 服務(wù)器使用 podSpec（Pod 規(guī)范 – YAML 或 JSON）。podSpec 定義了應(yīng)在 Pod 內(nèi)運(yùn)行的容器、它們的資源（例如 CPU 和內(nèi)存限制）以及其他設(shè)置，例如環(huán)境變量、卷和標(biāo)簽。然后，它通過創(chuàng)建容器將 podSpec 帶到所需狀態(tài)。

簡單地說，kubelet 負(fù)責(zé)以下工作：

1. 創(chuàng)建、修改和刪除容器。
2. 負(fù)責(zé)處理活躍度、準(zhǔn)備情況和啟動探測。
3. 負(fù)責(zé)通過讀取 Pod 配置并在主機(jī)上為卷掛載創(chuàng)建相應(yīng)的目錄來掛載卷。
4. 通過調(diào)用 API 服務(wù)器來收集和報告節(jié)點(diǎn)和 Pod 狀態(tài)，實(shí)現(xiàn)方式為 cAdvisor 和CRI。

Kubelet 也是一個控制器，它監(jiān)視 Pod 的變化，并利用節(jié)點(diǎn)的容器運(yùn)行時來拉取鏡像、運(yùn)行容器等。

除了來自 API 服務(wù)器的 PodSpec 之外，kubelet 還可以接受來自文件、HTTP 端點(diǎn)和 HTTP 服務(wù)器的 podSpec。“來自文件的 podSpec”的一個很好的例子是 Kubernetes 靜態(tài) pod。

靜態(tài) Pod 由 kubelet 控制，而不是由 API 服務(wù)器控制。即可以通過向 Kubelet 組件提供 Pod YAML 位置來創(chuàng)建 Pod。但是，Kubelet 創(chuàng)建的靜態(tài) Pod 不受 API 服務(wù)器的管理。

靜態(tài) Pod 的真實(shí)示例用例：在引導(dǎo)控制平面時，kubelet 從位于pod/etc/kubernetes/manifests的 podSpecs 的靜態(tài) pod 啟動 api-server、scheduler 和控制器管理器。

kubelet 的一些關(guān)鍵內(nèi)容：

1. Kubelet 使用 CRI（容器運(yùn)行時接口）gRPC 接口與容器運(yùn)行時通信。
2. 它還公開 HTTP 終結(jié)點(diǎn)以流式傳輸日志，并為客戶端提供 exec 會話。
3. 使用 CSI（容器存儲接口）gRPC 配置塊存儲卷。
4. 它使用集群中配置的 CNI 插件來分配 Pod IP 地址，并為 Pod 設(shè)置任何必要的網(wǎng)絡(luò)路由和防火墻規(guī)則。

3.2、Kube 代理

要了解 Kube 代理需要對 Kubernetes 服務(wù)和端點(diǎn)對象有基本的了解。

Kubernetes 中的服務(wù)是一種在內(nèi)部或向外部流量公開一組 Pod 的方法。創(chuàng)建服務(wù)對象時，它會為其分配一個虛擬 IP。它被稱為 clusterIP。它只能在 Kubernetes 集群中訪問。

Endpoint 對象包含 Service 對象下 Pod 組的所有 IP 地址和端口。端點(diǎn)控制器負(fù)責(zé)維護(hù)容器 IP 地址（端點(diǎn)）列表。服務(wù)控制器負(fù)責(zé)為服務(wù)配置終結(jié)點(diǎn)。

無法 ping ClusterIP，因?yàn)樗鼉H用于服務(wù)發(fā)現(xiàn)，這與可 ping 的 Pod IP 不同。

現(xiàn)在讓我們了解一下 Kube Proxy。Kube-proxy 是一個守護(hù)進(jìn)程，它作為守護(hù)進(jìn)程集在每個節(jié)點(diǎn)上運(yùn)行。它是一個代理組件，用于實(shí)現(xiàn) Pod 的 Kubernetes 服務(wù)概念。（具有負(fù)載均衡功能的一組 Pod 的單個 DNS）。它主要代理 UDP、TCP 和 SCTP，不理解 HTTP。

當(dāng)使用 Service （ClusterIP） 公開 Pod 時，Kube-proxy 會創(chuàng)建網(wǎng)絡(luò)規(guī)則，將流量發(fā)送到 Service 對象下分組的后端 Pod（端點(diǎn)）。即所有負(fù)載均衡和服務(wù)發(fā)現(xiàn)都由 Kube 代理處理。

那么 Kube-proxy 是如何工作的呢？

Kube 代理與 API 服務(wù)器通信，以獲取有關(guān)服務(wù) （ClusterIP） 和相應(yīng) Pod IP 和端口（端點(diǎn)）的詳細(xì)信息。它還監(jiān)視服務(wù)和終結(jié)點(diǎn)的更改。然后，kube-proxy 使用以下任一模式創(chuàng)建/更新規(guī)則，將流量路由到 Service 后面的 Pod。

1. IPTables：這是默認(rèn)模式。在 IPTables 模式量由 IPtable 規(guī)則處理。這意味著，對于每個服務(wù)，都會創(chuàng)建 IPtable 規(guī)則。這些規(guī)則捕獲進(jìn)入 ClusterIP 的流量，然后將其轉(zhuǎn)發(fā)到后端 Pod。此外，在這種模式下，kube-proxy 會隨機(jī)選擇后端 pod 進(jìn)行負(fù)載均衡。建立連接后，請求將轉(zhuǎn)到同一 Pod，直到連接終止。
2. IPVS：對于服務(wù)超過 1000 的集群，IPVS 提供性能改進(jìn)。它支持以下后端負(fù)載均衡算法。
   • rr： round-robin ：這是默認(rèn)模式。
   • lc：最少連接數(shù)（最小打開連接數(shù)）。
   • dh：目標(biāo)哈希。
   • sh：源哈希。
   • sed：最短的預(yù)期延遲。
   • nq：從不排隊(duì)。
3. 用戶空間（舊版&不推薦）
4. Kernelspace：此模式僅適用于 Windows 系統(tǒng)。

此外，可以通過將 Kubernetes 集群替換為 Cilium 來運(yùn)行沒有 kube-proxy 的 Kubernetes 集群。

Kubeproxy 有一個基于 nftables 的新后端。nftables 是 IPtables 的繼任者，旨在更簡單、更高效。

3.3、容器運(yùn)行時

如果了解 Java 運(yùn)行時 （JRE）。它是在主機(jī)上運(yùn)行 Java 程序所需的軟件。同樣，容器運(yùn)行時是運(yùn)行容器所需的軟件組件。

容器運(yùn)行時在 Kubernetes 集群中的所有節(jié)點(diǎn)上運(yùn)行。它負(fù)責(zé)從容器注冊表中提取映像、運(yùn)行容器、分配和隔離容器資源，以及管理主機(jī)上容器的整個生命周期。

為了更好地理解這一點(diǎn)，讓我們看一下兩個關(guān)鍵概念：

• 容器運(yùn)行時接口 （CRI）：它是一組 API，允許 Kubernetes 與不同的容器運(yùn)行時進(jìn)行交互。它允許不同的容器運(yùn)行時與 Kubernetes 互換使用。CRI 定義了用于創(chuàng)建、啟動、停止和刪除容器以及管理映像和容器網(wǎng)絡(luò)的 API。
• 開放容器計(jì)劃 （OCI）：它是一組容器格式和運(yùn)行時的標(biāo)準(zhǔn)。

Kubernetes 支持多個符合容器運(yùn)行時接口 （CRI） 的容器運(yùn)行時（CRI-O、Docker 引擎、containerd 等）。即所有這些容器運(yùn)行時都實(shí)現(xiàn)了 CRI 接口，并公開了 gRPC CRI API（運(yùn)行時和圖像服務(wù)端點(diǎn)）。

那么 Kubernetes 是如何利用容器運(yùn)行時的呢？

正如在 Kubelet 部分所了解的，kubelet 代理負(fù)責(zé)使用 CRI API 與容器運(yùn)行時進(jìn)行交互，以管理容器的生命周期。它還從容器運(yùn)行時獲取所有容器信息，并將其提供給控制平面。

以 CRI-O 容器運(yùn)行時接口為例。下面是容器運(yùn)行時如何與 Kubernetes 配合使用的高級概述。

1. 當(dāng) API 服務(wù)器對 Pod 有新的請求時，kubelet 會與 CRI-O 守護(hù)進(jìn)程通信，以通過 Kubernetes 容器運(yùn)行時接口啟動所需的容器。
2. CRI-O 使用 containers/image 庫檢查并從配置的容器注冊表中提取所需的容器映像。
3. 然后，CRI-O 為容器生成 OCI 運(yùn)行時規(guī)范 （JSON）。
4. 然后，CRI-O 啟動與 OCI 兼容的運(yùn)行時 （runc） 以根據(jù)運(yùn)行時規(guī)范啟動容器進(jìn)程。

四、Kubernetes 集群插件組件

除了核心組件之外，kubernetes 集群還需要附加組件才能完全運(yùn)行。選擇插件取決于項(xiàng)目要求和用例。

以下是集群上可能需要的一些常用插件組件：

• CNI 插件(Container Network Interface)。
• CoreDNS（用于DNS服務(wù)器）：CoreDNS 充當(dāng) Kubernetes 集群中的 DNS 服務(wù)器。通過啟用此插件，您可以啟用基于 DNS 的服務(wù)發(fā)現(xiàn)。
• Metrics Server （用于資源指標(biāo)）：該插件可幫助您收集集群中節(jié)點(diǎn)和 Pod 的性能數(shù)據(jù)和資源使用情況。
• Web UI（Kubernetes 儀表板）：此插件使 Kubernetes 儀表板能夠通過 Web UI 管理對象。

4.1、CNI插件

首先需要了解容器網(wǎng)絡(luò)接口 （CNI）。它是一個基于插件的架構(gòu)，具有供應(yīng)商中立的規(guī)范和庫，用于為容器創(chuàng)建網(wǎng)絡(luò)接口。

它不是特定于 Kubernetes 的。借助 CNI，容器網(wǎng)絡(luò)可以在 Kubernetes、Mesos、CloudFoundry、Podman、Docker 等容器編排工具之間實(shí)現(xiàn)標(biāo)準(zhǔn)化。

在容器網(wǎng)絡(luò)方面，公司可能有不同的要求，例如網(wǎng)絡(luò)隔離、安全性、加密等。隨著容器技術(shù)的進(jìn)步，許多網(wǎng)絡(luò)提供商為具有廣泛網(wǎng)絡(luò)功能的容器創(chuàng)建了基于 CNI 的解決方案?？梢苑Q它為CNI-Plugins

這允許用戶從不同的提供商處選擇最適合其需求的網(wǎng)絡(luò)解決方案。

CNI 插件如何與 Kubernetes 配合使用？

1. Kube-controller-manager 負(fù)責(zé)為每個節(jié)點(diǎn)分配 Pod 網(wǎng)段。每個 Pod 從 Pod CIDR 獲取一個唯一的 IP 地址。
2. Kubelet 與容器運(yùn)行時交互以啟動定時 Pod。作為容器運(yùn)行時一部分的 CRI 插件與 CNI 插件交互以配置 Pod 網(wǎng)絡(luò)。
3. CNI 插件支持使用疊加網(wǎng)絡(luò)在分布在相同或不同節(jié)點(diǎn)上的 Pod 之間聯(lián)網(wǎng)。

CNI 插件提供的高級功能：

• Pod 網(wǎng)絡(luò)
• Pod 網(wǎng)絡(luò)安全和隔離，使用網(wǎng)絡(luò)策略來控制 Pod 之間和命名空間之間的流量。

流行的 CNI 插件包括：

• Calico
• Flannel
• Weave Net
• Cilium（使用 eBPF）
• Amazon VPC CNI（適用于 AWS VPC）。
• Azure CNI（適用于 Azure 虛擬網(wǎng)絡(luò)）Kubernetes 網(wǎng)絡(luò)是一個大主題，它因托管平臺而異。

五、Kubernetes 原生對象

到目前為止，已經(jīng)了解了核心 kubernetes 組件以及每個組件的工作原理。所有這些組件都致力于管理以下關(guān)鍵 Kubernetes 對象。

• Pod
• Namespaces
• Replicaset
• Deployment
• Daemonset
• Statefulset
• Jobs & Cronjobs

此外，Kubernetes 可以使用 CRD 和自定義控制器進(jìn)行擴(kuò)展。因此，群集組件還管理使用自定義控制器和自定義資源定義創(chuàng)建的對象。

六、Kubernetes 架構(gòu)常見問題

（1）Kubernetes 控制平面的主要用途是什么？
控制平面負(fù)責(zé)維護(hù)集群及其上運(yùn)行的應(yīng)用程序的所需狀態(tài)。它由 API 服務(wù)器、etcd、調(diào)度程序和控制器管理器等組件組成。

（2）Kubernetes 集群中工作節(jié)點(diǎn)的用途是什么？
工作器節(jié)點(diǎn)是在群集中運(yùn)行容器的服務(wù)器（裸機(jī)或虛擬）。它們由控制平面管理，并從控制平面接收有關(guān)如何運(yùn)行屬于 Pod 的容器的指令。

（3）如何在 Kubernetes 中保護(hù)控制平面和工作節(jié)點(diǎn)之間的通信？
控制平面和工作節(jié)點(diǎn)之間的通信使用 PKI 證書進(jìn)行保護(hù)，不同組件之間的通信通過 TLS 進(jìn)行。這樣，只有受信任的組件才能相互通信。

（4）Kubernetes 中 etcd 鍵值存儲的目的是什么？
Etcd 主要存儲集群的 kubernetes 對象、集群信息、節(jié)點(diǎn)信息以及集群的配置數(shù)據(jù)，例如集群上運(yùn)行的應(yīng)用程序的期望狀態(tài)。

（5）如果 etcd 宕機(jī)，Kubernetes 應(yīng)用程序會發(fā)生什么？
雖然如果 etcd 遇到中斷，正在運(yùn)行的應(yīng)用程序不會受到影響，但如果沒有正常運(yùn)行的 etcd，將無法創(chuàng)建或更新任何對象。

七、總結(jié)

了解 Kubernetes 架構(gòu)有助于進(jìn)行日常 Kubernetes 實(shí)施和操作。在實(shí)施生產(chǎn)級群集設(shè)置時，對 Kubernetes 組件有正確的了解將有助于運(yùn)行應(yīng)用程序并對其進(jìn)行故障排除。

文章來源地址http://www.zghlxwxcb.cn/news/detail-848684.html

到了這里，關(guān)于【解讀Kubernetes架構(gòu)】全面指南，帶你掌握Kubernetes的設(shè)計(jì)原理與構(gòu)成！的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！