部署藍圖

Last reviewed 2024-12-13 UTC

本節說明可用來部署藍圖的程序、命名慣例，以及藍圖建議的替代方案。

整合所有資訊

如要實作本文件所述的架構，請完成本節中的步驟。

在新機構中部署藍圖

如要在新 Google Cloud 機構中部署藍圖，請完成下列步驟：

  1. 使用企業基礎架構藍圖建立基礎架構。完成下列操作：

    1. 建立機構結構，包括用於區隔環境的資料夾。
    2. 設定基礎身分與存取權管理權限，授予開發人員平台管理員存取權。
    3. 建立虛擬私有雲網路。
    4. 部署基礎架構管道。

    如果您未使用企業基礎藍圖，請參閱不使用企業基礎藍圖部署藍圖。

  2. 部署企業應用程式藍圖，如下所示：

    1. 開發人員平台管理員會使用基礎基礎架構管道，建立多租戶基礎架構管道、應用程式工廠和車隊範圍管道。
    2. 開發人員平台管理員使用多租戶基礎架構管道來部署 GKE 叢集和共用基礎架構。
    3. 應用程式操作員會使用應用程式工廠來導入新的應用程式。作業員會在應用程式工廠存放區中新增一或多個項目，觸發建立應用程式專屬資源的動作。
    4. 應用程式開發人員會在應用程式專屬基礎架構中使用應用程式 CI/CD 管道，將應用程式部署至多租戶基礎架構。

不含企業基礎藍圖的藍圖部署作業

如果您未在企業基礎架構藍圖上部署企業應用程式藍圖，請完成下列步驟：

  1. 建立下列資源：
    • 包含 development、nonproduction 和 production 資料夾的機構階層
    • 每個資料夾中都有一個共用虛擬私有雲網路
    • 考量 GKE 叢集所需 IP 範圍的 IP 位址配置
    • GKE 叢集的 DNS 機制
    • 符合安全防護機制的防火牆政策
    • 透過私人 IP 位址存取 Google Cloud API 的機制
    • 與內部部署環境的連線機制
    • 集中式記錄功能，用於安全性和稽核
    • 用於威脅監控的 Security Command Center
    • 符合安全防護狀態的機構政策
    • 可用於部署應用程式工廠、多租戶基礎架構管道和車隊範圍管道的管道
  2. 部署資源後，請繼續執行「在新機構中部署藍圖」中的步驟 2。

將藍圖納入現有的 GKE 部署作業

這個藍圖要求您先部署開發人員平台，然後再將應用程式部署至開發人員平台。下表說明如果您已在 Google Cloud上執行容器化應用程式，如何使用藍圖。

現有用量 遷移策略

已擁有 CI/CD 管道。

即使應用程式建構和部署作業使用不同的產品，您仍可使用藍圖的車隊和叢集架構。我們建議您至少將圖片鏡像到兩個區域。

現有的機構架構不符合企業基礎架構藍圖。

建議您至少建立兩個環境，以便更安全地進行序列部署作業。您不必在不同的共用 VPC 或資料夾中部署環境。不過，請勿將屬於不同環境的工作負載部署至同一叢集。

請勿使用 IaC。

如果您目前的應用程式部署程序未使用 IaC，可以使用Terraform 的Google Cloud 成熟度模型評估您的準備情況。將現有資源匯入其他 Terraform 專案，並按照與此藍圖類似的架構進行整理，以便將多租戶和個別租戶管道分開。如要建立新叢集，您可以使用 Google Cloud的 Terraform 模組。

叢集會分散至相同環境中的多個專案。

您可以將多個專案的叢集分組成一個機群。請確認命名空間在同一個機群中具有獨特的含義。在將叢集新增至機群之前，請要求團隊將應用程式移至具有專屬名稱的命名空間 (例如，不要使用 default)。

接著，您可以將命名空間分組成範圍。

叢集位於單一區域。

您不需要在實際工作環境和非實際工作環境中使用多個區域，即可採用藍圖。

有不同的環境組合。

您可以修改藍圖，支援多於或少於三個環境。

叢集建立作業會委派給應用程式開發人員或應用程式操作團隊。

為確保開發人員平台的安全性和一致性，您可以嘗試將叢集的擁有權從應用程式團隊移至開發人員平台團隊。如果無法做到，您仍可採用許多藍圖做法。舉例來說，您可以將不同應用程式團隊擁有的叢集新增至車隊。不過，如果要將擁有權獨立的叢集合併，請勿使用 GKE 或 Cloud Service Mesh 的 Workload Identity Federation，因為這兩者無法提供足夠的控管功能，無法確保誰可以宣告哪些工作負載身分。請改用自訂組織政策，禁止團隊在 GKE 叢集中啟用這些功能。

叢集分組成機群後，您仍可稽核及強制執行政策。您可以使用自訂機構政策，要求在機群中建立叢集，並與叢集專案所在的環境資料夾相對應。您可以使用車隊預設設定，要求新叢集使用政策控制機制。

替代預設最佳化建議

本節將說明本指南中預設建議的替代方案。

決策區域 可能的替代方案

所有應用程式都會在同一組五個叢集中執行。

藍圖使用五個叢集 (兩個正式環境、兩個非正式環境和一個開發環境)。您可以修改藍圖，製作更多五個叢集的組合。

將應用程式指派給五個叢集組合。請勿將應用程式的範圍或機群命名空間繫結至其他集合中的叢集。您可能需要將應用程式分割成不同的叢集組，以便完成下列活動：

  • 將幾個有特殊法規疑慮的應用程式歸類在一起 (例如 PCI-DSS)。
  • 隔離需要在叢集升級期間特別處理的應用程式 (例如使用持久性磁碟區的有狀態應用程式)。
  • 隔離具有風險安全性設定檔的應用程式 (例如，使用記憶體不安全的語言處理使用者提供的內容)。
  • 隔離需要 GPU 的應用程式、成本敏感度和效能敏感度。
  • 如果節點數量 (65,000 個節點) 已接近 GKE 叢集限制，您可以建立新的叢集組合。
  • 針對需要在 VPC Service Controls 範圍內執行的應用程式，請使用其他共用虛擬私有雲。在範圍內建立一個叢集組合，在範圍外建立一個叢集組合。

請勿為每個應用程式或租用戶建立新的叢集組合，因為這可能導致下列其中一種情況：

  • 即使使用最小的可用執行個體類型，應用程式仍無法充分利用最小叢集大小 (3 個 VM x 2 個區域)。
  • 未能透過不同應用程式的 bin-packing 降低成本。
  • 由於規劃會個別套用至每個應用程式，因此容量成長規劃繁瑣且不確定。針對廣泛的應用程式進行匯總，可更準確地預測容量。
  • 為新租戶或應用程式建立新叢集的時間延遲，導致租戶對平台的滿意度降低。舉例來說，在某些機構中，分配所需的 IP 位址可能需要花費時間，且需要額外核准。
  • 在虛擬私有雲網路中達到私人叢集限制。

實際工作環境和非實際工作環境在兩個區域中都有叢集。

為降低多個地區使用者的延遲時間，您可以將正式版和非正式版工作負載部署到多個區域 (例如，正式版三個區域、非正式版三個區域，以及開發版一個區域)。這種部署策略會增加在其他區域維護資源的成本和額外負擔。

如果所有應用程式都具有較低的可用性需求，您可以將正式和非正式工作負載部署至單一區域 (一個正式環境、一個非正式環境和一個開發環境)。這項策略有助於降低成本，但無法提供與雙地區或多地區架構相同的可用性。

如果應用程式有不同的可用性需求，您可以為不同的應用程式建立不同的叢集集合 (例如，cluster-set-1 有兩個實際工作環境、兩個非實際工作環境和一個開發環境，而 cluster-set-2 則有一個實際工作環境、一個非實際工作環境和一個開發環境)。

軸輻式拓撲比共用虛擬私有雲更能滿足您的需求。

您可以在集線和輻條設定中部署藍圖，其中每個環境 (開發、正式版和非正式版) 都會在各自的輻條中代管。使用輻射狀拓撲可提高環境區隔性。詳情請參閱「輻射狀網路拓撲」。

每個應用程式都有獨立的 Git 存放區。

有些機構會使用單一 Git 存放區 (monorepo) 來儲存所有原始碼，而非使用多個存放區。如果您使用單一存放區，可以修改藍圖的 應用程式工廠元件，以支援您的存放區。完成下列操作：

  • 請勿為每個新應用程式建立新的存放區，而是在現有存放區中建立子目錄。
  • 請不要將新存放區的擁有者權限授予應用程式開發人員群組，而是授予現有存放區的寫入權限，並將應用程式開發人員群組設為新子目錄變更的必要審查者。使用 CODEOWNERS 功能和分支保護功能。

後續步驟