本節說明開發人員平台使用的控制項。
平台身分、角色和群組
如要存取 Google Cloud 服務，必須使用 Google Cloud 身分。藍圖會使用 fleet Workload Identity Federation for GKE，將做為 Pod 身分的 Kubernetes 服務帳戶，對應至Google Cloud 控管服務存取權的服務帳戶 Google Cloud。為防範跨環境的權限提升，每個環境都有專屬的身分集區 (也稱為一組受信任的識別資訊提供者)，供其 Workload Identity Federation for GKE 帳戶使用。
平台人物角色
部署藍圖時，您會建立三種使用者群組：開發人員平台團隊、應用程式團隊 (每個應用程式一個團隊)，以及安全營運團隊。
開發人員平台團隊負責開發及管理開發人員平台。這個團隊的成員如下：
- 開發人員平台開發人員：這些團隊成員會擴充藍圖，並將其整合至現有系統。這個團隊也會建立新的應用程式範本。
- 開發人員平台管理員：這個團隊負責下列事項：
- 核准建立新的房客團隊。
- 執行會影響多個房客的排定和未排定工作，包括：
- 核准將應用程式升級至非正式環境和正式環境。
- 協調基礎架構更新。
- 制定平台層級的容量方案。
開發人員平台租戶是指單一軟體開發團隊，以及負責該軟體運作的人員。租戶團隊由兩組人員組成：應用程式開發人員和應用程式營運人員。這兩組房客團隊的職責如下：
- 應用程式開發人員：這個團隊負責編寫及偵錯應用程式程式碼。有時也稱為「軟體工程師」或「全端開發人員」。其職責包括：
- 在應用程式元件部署到開發環境時，對該元件執行測試和品質保證。
- 在開發環境中管理應用程式擁有的雲端資源 (例如資料庫和儲存空間 bucket)。
- 設計供應用程式使用的資料庫或儲存空間結構定義。
- 應用程式營運人員或網站可靠性工程師 (SRE)：這個團隊負責管理在實際執行環境中執行的應用程式可靠性，並確保應用程式開發人員所做的變更安全地發布至實際執行環境。有時也稱為「服務營運人員」、「系統工程師」或「系統管理員」。其職責包括：
- 規劃應用程式層級的容量需求。
- 為服務建立快訊政策及設定服務等級目標 (SLO)。
- 使用特定應用程式的記錄和指標診斷服務問題。
- 回應快訊和呼叫，例如服務未達到 SLO 時。
- 與一或多個應用程式開發人員群組合作。
- 核准將新版本部署至正式環境。
- 在非實際工作環境和實際工作環境中，管理應用程式擁有的雲端資源 (例如備份和結構定義更新)。
平台機構結構
企業應用程式藍圖會使用企業基礎藍圖提供的機構結構。下圖顯示企業應用程式藍圖專案在基礎藍圖結構中的位置。
平台專案
下表說明應用程式藍圖需要哪些額外專案 (基礎藍圖提供的專案除外)，才能部署資源、設定和應用程式。
| 資料夾 | 專案 | 說明 |
|---|---|---|
|
|
包含用於部署租戶基礎架構的多租戶基礎架構管道。 |
|
內含應用程式工廠 ，用於建立單一租戶應用程式架構，以及持續整合和持續部署 (CI/CD) 管道。這個專案也包含用於 GKE 叢集設定的 Config Sync。 |
|
|
包含應用程式的持續整合/持續部署管道，這些管道位於獨立專案中，可讓開發團隊彼此區隔。每個應用程式都有一個管道。 |
|
|
|
包含開發人員平台適用的 GKE 叢集，以及用於註冊叢集以進行機群管理的邏輯。 |
( |
包含任何單一租戶應用程式服務，例如應用程式團隊使用的資料庫或其他代管服務。 |
平台叢集架構
藍圖會在三種環境中部署應用程式：開發、非實際工作環境和實際工作環境。每個環境都與車隊相關聯。 在本藍圖中，機群是指包含一或多個叢集的專案。不過，機群也可以將多個專案分組。機群可做為管理控制的邏輯安全界線。機群能有條理地將 Kubernetes 叢集分類並正規化，讓基礎架構管理作業更輕鬆。
下圖顯示在每個環境中建立的兩個 GKE 叢集，用於部署應用程式。這兩個叢集會做為兩個不同地區中的相同 GKE 叢集，提供多區域復原能力。為善用機群功能，藍圖採用相同性概念，適用於命名空間物件、服務和身分。
企業應用程式藍圖會使用 GKE 叢集，並透過控制層的 Private Service Connect 存取權和私人節點集區啟用私人空間，藉此從網際網路中移除潛在的攻擊面。叢集節點和控制層都沒有公開端點。叢集節點會執行 Container-Optimized OS，以限制攻擊途徑，並使用 Shielded GKE Nodes，限制攻擊者模擬節點的能力。
透過 Connect 閘道啟用 GKE 叢集的管理存取權。在藍圖部署作業中，每個環境都會使用一個 Cloud NAT 執行個體，為 Pod 和 Config Sync 提供存取網際網路資源 (例如 GitHub) 的機制。GKE 叢集的存取權是由 Kubernetes RBAC 授權控管，這項授權是以 Google Groups for GKE 為依據。您可以使用群組，透過身分管理員控管的中央身分管理系統來控管身分。
平台 GKE Enterprise 元件
開發人員平台會使用 GKE Enterprise 元件，協助您建構、交付及管理應用程式的生命週期。藍圖部署作業會使用下列 GKE Enterprise 元件：
- 使用 GKE 管理容器
- 政策控制器 用於政策管理及執行
- Cloud Service Mesh 服務管理
- 二進位授權，用於容器映像檔認證
- GKE Gateway 控制器 適用於 GKE 叢集的多叢集閘道控制器
平台機群管理
機群可讓您以單一統一的方式管理多個 GKE 叢集。機群團隊管理功能可讓平台管理員更輕鬆地為開發人員平台租戶佈建及管理基礎架構資源。租戶可控管自身命名空間內的資源，包括應用程式、記錄和指標。
如要為個別團隊佈建部分機群資源，管理員可以使用團隊範圍。團隊範圍可讓您為每個團隊定義一組機群資源，並將各個團隊範圍連結至一或多個機群成員叢集。
機群命名空間可控管哪些使用者有權存取機群中的特定命名空間。應用程式使用部署在一個機群上的兩個 GKE 叢集，並有三個團隊範圍，每個範圍都有一個機群命名空間。
下圖顯示環境中與範例叢集對應的車隊和範圍資源，如藍圖所實作。
平台網路
就網路而言，GKE 叢集會部署在共用 VPC 中，而共用 VPC 是在企業基礎藍圖中建立的。GKE 叢集需要在開發、非實際工作環境和實際工作環境中，指派多個 IP 位址範圍。藍圖使用的每個 GKE 叢集，都需要為節點、Pod、服務和控制層分配不同的 IP 位址範圍。PostgreSQL 適用的 AlloyDB 執行個體也需要個別的 IP 位址範圍。
下表說明在不同環境中部署藍圖叢集時使用的 VPC 子網路和 IP 位址範圍。在「Application GKE cluster region 2」(應用程式 GKE 叢集區域 2) 的開發環境中，即使已為兩個開發 GKE 叢集分配 IP 位址空間，藍圖也只會部署一個 IP 位址空間。
| 資源 | IP 位址範圍類型 | 開發 | 非正式環境 | 生產 |
|---|---|---|---|---|
應用程式 GKE 叢集區域 1 |
主要 IP 位址範圍 |
10.0.64.0/24 |
10.0.128.0/24 |
10.0.192.0/24 |
Pod IP 位址範圍 |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
服務 IP 位址範圍 |
100.0.80.0/24 |
100.0.144.0/24 |
100.0.208.0/24 |
|
GKE 控制層 IP 位址範圍 |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
應用程式 GKE 叢集區域 2 |
主要 IP 位址範圍 |
10.1.64.0/24 |
10.1.128.0/24 |
10.1.192.0/24 |
Pod IP 位址範圍 |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
服務 IP 位址範圍 |
100.1.80.0/24 |
100.1.144.0/24 |
100.1.208.0/24 |
|
GKE 控制層 IP 位址範圍 |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
AlloyDB for PostgreSQL |
資料庫 IP 位址範圍 |
10.9.64.0/18 |
10.9.128.0/18 |
10.9.192.0/18 |
如要自行設計 IP 位址分配機制，請參閱「GKE 中的 IP 位址管理」和「GKE IPv4 位址規劃」。
平台 DNS
藍圖會使用 Cloud DNS for GKE，為 Pod 和 Kubernetes 服務提供 DNS 解析。GKE 適用的 Cloud DNS 是代管 DNS，不需要叢集代管的 DNS 供應商。
在藍圖中，Cloud DNS 是針對虛擬私有雲範圍設定。 透過 VPC 範圍，專案中所有 GKE 叢集的服務都能共用單一 DNS 區域。單一 DNS 區域可讓服務跨叢集解析，且叢集外部的 VM 或 Pod 可解析叢集內的服務。
平台防火牆
建立 GKE 叢集、GKE 服務、GKE Gateway 防火牆和 GKE Ingress 防火牆時，GKE 會自動建立防火牆規則，讓叢集在您的環境中運作。所有自動建立的防火牆規則優先順序均為 1000。由於企業基礎藍圖設有預設規則，會封鎖共用 VPC 中的流量，因此需要這些規則。
平台存取 Google Cloud 服務
由於藍圖應用程式使用私人叢集，因此私人 Google 存取權可提供 Google Cloud 服務的存取權。
平台高可用性
這項藍圖的設計宗旨是確保可用區和區域發生中斷時，系統仍能正常運作。應用程式運作所需的資源會分散在兩個區域。選取要部署藍圖的區域。如果資源不在提供及回應負載的關鍵路徑中，則只會位於一個區域或全域。下表說明資源及其部署位置。
位置 |
區域 1 |
區域 2 |
全球 |
|---|---|---|---|
這個位置有資源的環境 |
|
|
|
在這個位置有資源的專案 |
|
|
|
這個位置的資源類型 |
|
|
|
下表摘要說明不同元件對區域或可用區中斷的反應，以及如何減輕這些影響。
失敗範圍 |
外部服務影響 |
資料庫效果 | 建構及部署特效 | Terraform 管道效果 |
|---|---|---|---|---|
區域 1 的可用區 |
有。 |
有。 待命執行個體會變成有效執行個體，復原點目標為零。 |
可用，可能需要手動變更。 如果 |
可用，可能需要手動變更。 如果 |
區域 2 的可用區 |
有。 |
有。 |
有。 |
可用，可能需要手動變更。 如果 |
區域 1 |
有。 |
需要手動變更。 運算子必須手動升級次要叢集。 |
無法使用。 |
無法使用。 |
區域 2 |
有。 |
有。 |
可用，可能需要手動變更 您還是可以使用建構版本。您可能需要手動部署新版本。現有建構作業可能無法順利完成。 |
有。 |
雲端服務供應商中斷只是造成停機的原因之一。高可用性也取決於有助於減少錯誤的程序和作業。下表說明藍圖中與高可用性相關的所有決策，以及做出這些決策的原因。
| 藍圖決策 | 對於可用性的影響 |
|---|---|
變更管理 |
|
使用 GitOps 和 IaC。 |
支援同儕審查變更，並快速還原至先前的設定。 |
逐步將變更推行至各個環境。 |
降低軟體和設定錯誤的影響。 |
讓非正式環境和正式環境相似。 |
確保差異不會延遲錯誤的探索。兩個環境都是雙區域。 |
在環境中一次變更一個區域的複製資源。 |
確保未透過逐步升級程序發現的問題，只會影響一半的執行階段基礎架構。 |
在環境中一次變更一個區域的服務。 |
確保未透過逐步升級偵測到的問題只會影響一半的服務副本。 |
複製的運算基礎架構 |
|
使用區域叢集控制層。 |
升級和調整大小期間，區域控制層仍可使用。 |
建立多區域節點集區。 |
叢集節點集區至少有三個節點，分布在三個區域。 |
設定共用虛擬私有雲網路。 |
共用虛擬私有雲網路涵蓋兩個區域。區域性故障只會影響故障區域中資源的網路流量。 |
複製映像檔登錄檔。 |
映像檔會儲存在 Artifact Registry 中，並設定為複製到多個區域，因此雲端區域中斷不會妨礙應用程式在倖存區域中擴充。 |
複製服務 |
|
將服務副本部署至兩個區域。 |
如果發生區域性中斷，Kubernetes 服務在正式和非正式環境中仍可使用。 |
使用滾動式更新，在區域內變更服務。 |
您可以透過滾動式更新部署模式更新 Kubernetes 服務，降低風險和停機時間。 |
為每個服務在一個區域中設定三個副本。 |
Kubernetes 服務至少要有三個副本 (Pod)，才能在正式和非正式環境中支援滾動更新。 |
將部署的 Pod 分散到多個可用區。 |
Kubernetes 服務會使用反親和性段落，分散到不同區域的 VM 中。單一節點中斷或整個可用區中斷時，系統可以容許這種情況，而不會在相依服務之間產生額外的跨區域流量。 |
複寫儲存空間 |
|
部署多區域資料庫執行個體。 |
PostgreSQL 適用的 AlloyDB 可在區域中提供高可用性。主要執行個體的備援節點位於該區域的兩個不同可用區。如果主要執行個體所在的可用區發生問題，系統會自動觸發容錯移轉至待命可用區，確保區域可用性。如果單一可用區發生故障，地區儲存空間可確保資料耐久性。 |
跨區域複製資料庫。 |
PostgreSQL 適用的 AlloyDB 採用跨區域複製功能，提供災害復原功能。資料庫會以非同步方式，將主要叢集的資料複製到位於不同Google Cloud 區域的次要叢集。 |
作業 |
|
為應用程式佈建的資源是預期負載的兩倍。 |
如果其中一個叢集發生故障 (例如區域服務中斷)，在剩餘叢集中執行的服務部分可以完全吸收負載。 |
自動修復節點。 |
叢集已設定節點自動修復功能。如果節點在延長的時間範圍內持續未通過健康狀態檢查，GKE 就會針對該節點啟動修復程序。 |
確保節點集區升級作業會考量應用程式。 |
部署作業會使用 |
自動重新啟動死結服務。 |
支援服務的部署作業會定義有效性探測，用來識別並重新啟動死結程序。 |
自動檢查副本是否已準備就緒。 |
支援服務的部署作業會定義完備性探測，指出應用程式啟動後何時準備好提供服務。在滾動更新和節點集區升級期間，就緒探針可省去手動檢查或計時等待的作業。 |
參考架構適用於有區域和地區高可用性需求的應用程式。確保高可用性會產生一些費用 (例如備用零件費用或跨地區複製費用)。「替代方案」一節說明如何降低這些費用。
平台配額、效能限制和資源調度限制
您可以在開發人員平台中控管資源的配額、效能和調度。以下列出一些需要注意的事項：
- 基礎架構需要多個專案，每個額外的租戶則需要四個專案。部署及新增更多房客前，您可能需要申請額外的專案配額。
- 每個專案最多只能有 100 個 MultiClusterGateway 資源。開發人員平台上的每個面向網際網路的 Kubernetes 服務，都需要一個 MultiClusterGateway。
- Cloud Logging 專案最多只能有 100 個 bucket。藍圖中每個租戶的記錄存取權，都依賴各租戶專屬的值區。
- 如要建立超過 20 個租戶，可以申請提高專案的配額，以用於範圍和範圍命名空間資源。如需查看配額的操作說明，請參閱「查看及管理配額」。使用篩選器找出
gkehub.googleapis.com/global-per-project-scopes和gkehub.googleapis.com/global-per-project-scope-namespaces配額類型。
後續步驟
- 瞭解服務架構 (本系列文件的下一份文件)。