叢集架構

在 Google Kubernetes Engine 中,一個「叢集」包含至少一個「叢集主要機器」和多個稱為「節點」的工作站機器。這些主要機器和節點機器會執行 Kubernetes 叢集自動化調度管理系統。

叢集是 GKE 的基礎:代表容器化應用程式的 Kubernetes 物件全都以叢集為基礎來執行。

叢集主要機器

「叢集主要機器」會執行 Kubernetes 控制層程序,包含 Kubernetes API 伺服器、排程器和核心資源控制器。當您建立刪除叢集時,主要機器的生命週期會由 GKE 代管。管理內容包含替叢集主要機器上執行的 Kubernetes 版本進行升級,GKE 會自動執行這項作業,但如果您想在自動排程之前先升級,也可以要求手動執行。

叢集主要機器和 Kubernetes API

主要機器是叢集的整合式端點。所有與叢集的互動都透過 Kubernetes API 呼叫來完成,且主要機器會執行 Kubernetes API 伺服器程序來處理這些要求。您可以直接透過 HTTP/gRPC 進行 Kubernetes API 呼叫,也可以透過執行 Kubernetes 指令列用戶端 (kubectl) 的指令或透過 GCP Console 的 UI 進行互動來間接呼叫。

叢集主要機器的 API 伺服器程序是叢集所有通訊的中樞。所有內部叢集程序 (例如叢集節點、系統與元件、應用程式控制器) 都可做為 API 伺服器的用戶端使用;API 伺服器是整個叢集的單一「可靠來源」。

主要機器和節點互動

叢集主要機器負責決定所有叢集節點上執行的項目。這可能包括排定工作負載,例如容器化應用程式、管理工作負載的生命週期、資源調度和升級。主要機器也會為這些工作負載管理網路和儲存空間資源。

主要機器和節點也會使用 Kubernetes API 進行通訊。

與 gcr.io Container Registry 的主要機器互動

當您建立或更新叢集時,系統會從 gcr.io Container Registry 擷取主要機器 (和節點) 上執行的 Kubernetes 軟體的容器映像檔因服務中斷所發生的 gcr.io 註冊資料庫中斷可能會導致以下類型的故障:

  • 服務中斷期間,建立新叢集會失敗。
  • 中斷期間,叢集升級會失敗。
  • 根據服務中斷的具體性質和時間長短,即使沒有使用者介入,仍可能發生工作負載中斷的情形。

如果 gcr.io Container Registry 發生區域或地區性服務中斷,Google 可能會將要求重新導向至不受服務中斷影響的區域或地區。

如要查看 GCP 服務目前的狀態,請前往 GCP 狀態資訊主頁

節點

叢集通常會有一或多個「節點」,這些節點是執行容器化應用程式和其他工作負載的工作站機器。個別機器是指建立叢集時,GKE 代替您建立的 Compute Engine VM 執行個體

每個節點都能透過主要機器管理,主要機器會接收各節點自行回報的狀態最新資訊。您可以對節點的生命週期進行部分的手動控制,或讓 GKE 在叢集的節點上執行自動修復自動升級

節點會執行必要服務以支援構成叢集工作負載的 Docker 容器。這些服務包括 Docker 執行階段和 Kubernetes 節點代理程式 (kubelet),後者會與主要機器通訊,並負責啟動及執行該節點上排定的 Docker 容器。

在 GKE 中,還有許多特殊容器做為節點代理程式執行,以提供記錄收集和叢集內網路連線等功能。

節點機器類型

每個節點都是標準的 Compute Engine 機器類型。預設類型為 n1-standard-1,包含 1 個虛擬 CPU 和 3.75 GB 的記憶體。您可以在建立叢集時選取不同的機器類型。

節點 OS 映像檔

每個節點都會執行專屬 OS 映像檔以執行容器。您可以指定叢集和節點集區使用的 OS 映像檔。

最低 CPU 平台

建立叢集或節點集區時,您可以指定節點的最低 CPU 平台基準。選擇特定 CPU 平台對於進階作業或需要大量運算資源的工作負載十分有利。詳情請參閱最低 CPU 平台

可分配的節點資源

節點有一些資源必須執行 GKE 和 Kubernetes 節點元件,才能讓該節點做為叢集的一部分運作。因此,您可能會注意到 GKE 中節點的「資源總數」 (如機器類型說明文件中所列) 和節點的「可分配資源」有差異。

您可以要求或限制 pod 的資源用量。如要瞭解如何要求或限制 pod 的資源用量,請參閱管理容器的運算資源

如要檢查叢集的節點可分配資源,請執行下列指令:

kubectl describe node [NODE_NAME] | grep Allocatable -B 4 -A 3

傳回的輸出內容會包含 CapacityAllocatable 欄位,其中顯示暫時儲存空間、記憶體和 CPU 的測量結果。

可分配的記憶體和 CPU 資源

可分配資源的計算方式如下:

Allocatable = Capacity - Reserved - Eviction Threshold

以記憶體資源來說,GKE 保留下列項目:

  • 記憶體容量小於 1 GB 的機器,可使用 255 MiB 的記憶體
  • 第一個 4 GB 記憶體的 25%
  • 下一個 4 GB 記憶體的 20% (最高 8 GB)
  • 下一個 8 GB 記憶體的 10% (最高 16 GB)
  • 下一個 112 GB 記憶體的 6% (最高 128 GB)
  • 如果記憶體大小超過 128 GB,則保留任何記憶體的 2%

GKE 會在每個節點上保留額外的 100 MiB 記憶體以應對 Kubelet 的移除

以 CPU 資源來說,GKE 保留下列項目:

  • 第一個核心的 6%
  • 下一個核心的 1% (最多 2 個核心)
  • 後兩個核心的 0.5% (最多 4 個核心)
  • 若超過 4 個核心,則超過的任一核心保留 0.25%

下表顯示每個標準節點機器類型在排定叢集工作負載時,可使用的可分配記憶體和 CPU 資源數量:

機器類型 記憶體容量 (GB) 可分配的記憶體 (GB) CPU 容量 (核心數) 可分配的 CPU (核心數)
f1-micro 0.6 0.24 1 0.94
g1-small 1.7 1.2 1 0.94
n1-standard-1 (預設) 3.75 2.7 1 0.94
n1-standard-2 7.5 5.7 2 1.93
n1-standard-4 15 12.3 4 3.92
n1-standard-8 30 26.6 8 7.91
n1-standard-16 60 54.7 16 15.89
n1-standard-32 120 111.2 32 31.85
n1-standard-64 240 228.4 64 63.77
n1-standard-96 360 346.4 96 95.69
n1-highmem-2 13 10.7 2 1.93
n1-highmem-4 26 22.8 4 3.92
n1-highmem-8 52 47.2 8 7.91
n1-highmem-16 104 96.0 16 15.89
n1-highmem-32 208 197.4 32 31.85
n1-highmem-64 416 400.8 64 63.77
n1-highmem-96 624 605.1 96 95.69
n1-highcpu-2 1.8 1.3 2 1.93
n1-highcpu-4 3.6 2.6 4 3.92
n1-highcpu-8 7.2 5.5 8 7.91
n1-highcpu-16 14.4 11.9 16 15.89
n1-highcpu-32 28.8 25.3 32 31.85
n1-highcpu-64 57.6 52.5 64 63.77
n1-highcpu-96 86.4 79.6 96 95.69

可分配的本機暫時儲存空間資源

從 GKE 1.10 版起,您可以在管理 CPU 和記憶體資源時一併管理本機暫時儲存空間資源。系統保留的本機儲存空間主要用於容器映像檔使用的磁碟空間。

如果節點不會耗用所有保留的儲存空間,則 pod 仍然可以使用該空間。但無論如何,pod 都不會無法使用磁碟空間。

可分配的本機暫時儲存空間資源會使用下列公式計算,撤銷門檻為儲存空間容量的 10%:

Allocatable = Capacity - Reserved - Eviction Threshold
磁碟容量 (GB) 保留的容量 (GB) 可分配的容量 (GB)
8 4 3.2
16 8 6.4
32 16 12.8
64 28.4 29.2
128 50.8 64.4
256 95.6 134.8
512 100 360.8
1024 100 821.6
2048 100 1743.2
4096 100 3586.4
本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Kubernetes Engine 說明文件