Google Cloud 提供工具、產品、指引和專業服務，協助您從 Amazon Elastic Kubernetes Service (Amazon EKS) 遷移至 Google Kubernetes Engine (GKE)。 本文可協助您設計、實作及驗證從 Amazon EKS 遷移至 GKE 的計畫。如果您正在評估遷移的可能性，並想瞭解遷移的預期情況，本文也提供相關指引。除了在 Amazon Elastic Compute Cloud (Amazon EC2) 上執行，Amazon EKS 還有其他幾種部署選項，例如 AWS 輸出上的 Amazon EKS 和 Amazon EKS Anywhere。本文著重於 EC2 上的 Amazon EKS。
本文是從 AWS 遷移至Google Cloud 的系列文章之一，其他文章包括：
- 開始使用
- 從 Amazon EC2 遷移至 Compute Engine
- 從 Amazon S3 遷移至 Cloud Storage
- 從 Amazon EKS 遷移至 Google Kubernetes Engine (本文件)
- 從 Amazon RDS 和 Amazon Aurora for MySQL 遷移至 MySQL 適用的 Cloud SQL
- 從 Amazon RDS 和 Amazon Aurora for PostgreSQL 遷移至 PostgreSQL 適用的 Cloud SQL 和 PostgreSQL 適用的 AlloyDB
- 從 SQL Server 適用的 Amazon RDS 遷移至 SQL Server 適用的 Cloud SQL
- 從 AWS Lambda 遷移至 Cloud Run
GKE 是 Google 代管的 Kubernetes 服務，可讓您透過 Google 的基礎架構，大規模部署及操作容器化應用程式，並提供有助於管理 Kubernetes 環境的功能，例如：
- 兩種版本：GKE Standard 和 GKE Enterprise。 使用 GKE Standard 時，您可以存取核心功能的 Standard 級功能。使用 GKE Enterprise，即可存取 GKE 的所有功能。詳情請參閱「GKE 版本」。
- 兩種作業模式：Standard 和 Autopilot。在 Standard 模式下，您可以管理 GKE 叢集中的底層基礎架構和每個節點的設定。在 Autopilot 模式下，GKE 會管理底層基礎架構，例如節點設定、自動調度資源、自動升級、基準安全性和網路設定。如要進一步瞭解 GKE 作業模式，請參閱「選擇 GKE 作業模式」。
- 業界獨一無二的 Pod 服務水準協議，適用於在多個可用區使用 Autopilot 的情況。
- 使用節點自動佈建功能，自動建立及刪除節點集區。
- Google 管理的多叢集網路，可協助您設計及實作工作負載的高可用性分散式架構。
如要進一步瞭解 GKE，請參閱 GKE 總覽。
如要進行這項遷移作業，建議您按照「遷移至 Google Cloud：開始使用」一文所述的遷移架構操作。 Google Cloud
以下是遷移流程圖。
您可能會從來源環境遷移至 Google Cloud ，並進行一系列的疊代作業，例如先遷移部分工作負載，再遷移其他工作負載。針對每次個別的遷移疊代作業，您會遵循一般遷移架構的各個階段：
- 評估及探索工作負載和資料。
- 規劃並奠定 Google Cloud的基礎。
- 將工作負載和資料遷移至 Google Cloud。
- 最佳化 Google Cloud 環境。
如要進一步瞭解這個架構的各個階段，請參閱「遷移至 Google Cloud：開始使用」。
為設計有效的遷移計畫，建議您驗證計畫的每個步驟，並確保您有復原策略。如要驗證遷移計畫，請參閱「遷移至 Google Cloud：驗證遷移計畫的最佳做法」。
評估來源環境
在評估階段，您會決定將來源環境遷移至 Google Cloud的需求和依附元件。
評估階段是您能否成功遷移的關鍵。您必須深入瞭解要遷移的工作負載、工作負載的要求和依附元件，以及您目前的環境。此外，您還必須知道要從何踏出第一步，以成功規劃並執行 Google Cloud遷移作業。
評估階段包含下列工作：
- 建立鉅細靡遺的工作負載清單。
- 根據工作負載的屬性和依附元件將工作負載編目。
- 訓練並教導您的團隊使用 Google Cloud。
- 在 Google Cloud上建立實驗和概念驗證。
- 計算目標環境的總持有成本 (TCO)。
- 為工作負載選擇遷移策略。
- 選擇遷移工具。
- 定義遷移計畫和時程。
- 驗證遷移計畫。
如要進一步瞭解評估階段和這些工作，請參閱「遷移至 Google Cloud：評估及探索工作負載」。以下各節內容皆以該文件為依據。
建立廣告空間
如要設定遷移範圍，請建立兩個清單：
- 叢集的庫存。
- 在這些叢集中部署的工作負載清單。
建立這些裝置清單後，您可以：
- 評估來源環境的部署和作業程序。
- 評估支援服務和外部依附元件。
建立叢集清單
如要建立叢集清單，請針對每個叢集考慮下列事項：
- 節點數量和類型。瞭解目前環境中的節點數量和每個節點的特性後，您就能在遷移至 GKE 時調整叢集大小。新環境中的節點可能與您環境中使用的節點不同，例如硬體架構或世代。每個架構和世代的效能都不同，因此新環境中所需的節點數量可能與舊環境不同。評估節點中使用的任何類型硬體，例如高效能儲存裝置、GPU 和 TPU。評估節點上使用的作業系統映像檔。
- 內部或外部叢集。評估每個叢集會受到哪些內部或外部行為者影響。為支援您的用途，這項評估會納入叢集中執行的工作負載，以及與叢集互動的介面。
- 多租戶。如果您在環境中管理多租戶叢集，請評估是否可在新 Google Cloud環境中運作。現在是評估如何改善多租戶叢集的好時機，因為多租戶策略會影響您在 Google Cloud上建構基礎的方式。
- Kubernetes 版本。收集叢集的 Kubernetes 版本相關資訊，評估這些版本與 GKE 可用版本之間是否不符。如果您執行的是舊版或最近發布的 Kubernetes 版本，可能正在使用 GKE 無法提供的功能。這些功能可能已淘汰，或 GKE 尚未提供搭載這些功能的 Kubernetes 版本。
- Kubernetes 升級週期。如要維持可靠的環境，請瞭解您如何處理 Kubernetes 升級，以及升級週期與 GKE 升級的關係。
- 節點集區。如果您使用任何形式的節點分組，可能需要考慮這些分組如何對應至 GKE 中的節點集區概念，因為您的分組條件可能不適合 GKE。
- 節點初始化。評估初始化每個節點的方式，然後將節點標示為可用來執行工作負載，以便將這些初始化程序移植到 GKE。
- 網路設定。評估叢集的網路設定、IP 位址分配情形、網路外掛程式的設定方式、DNS 伺服器和 DNS 服務供應商的設定方式、是否為這些叢集設定任何形式的 NAT 或 SNAT，以及叢集是否屬於多叢集環境。
- 法規遵循：評估叢集必須滿足的任何法規遵循和監管需求，以及您是否符合這些需求。
- 配額與限制。評估叢集的配額和限制設定。舉例來說，每個節點可以執行多少個 Pod？一個叢集最多可以有多少個節點？
- 標籤和標記。評估您套用至叢集、節點集區和節點的所有中繼資料，以及您使用這些中繼資料的方式。舉例來說，您可能會產生報表，其中包含詳細的成本歸因 (以標籤為準)。
您在清查中評估的下列項目，著重於基礎架構和 Kubernetes 叢集的安全性：
- 命名空間。如果您在叢集中使用 Kubernetes 命名空間，以邏輯方式分隔資源，請評估每個命名空間中的資源，並瞭解您建立這種分隔方式的原因。舉例來說，您可能會使用命名空間做為多租戶策略的一部分。您可能已在 Kubernetes 系統元件專用的命名空間中部署工作負載，而且在 GKE 中可能無法獲得充分的控制權。
- 角色型存取權控管 (RBAC)。如要在叢集中使用RBAC 授權，請列出您在叢集中設定的所有 ClusterRole 和 ClusterRoleBinding 說明。
- 網路政策。列出您在叢集中設定的所有網路政策，並瞭解網路政策在 GKE 中的運作方式。
- Pod 安全性環境。擷取您在叢集中設定的 Pod 安全性環境相關資訊，並瞭解這些環境在 GKE 中的運作方式。
- 服務帳戶。如果叢集中的任何程序與 Kubernetes API 伺服器互動，請擷取這些程序使用的服務帳戶相關資訊。
建立 Kubernetes 叢集清單時，您可能會發現部分叢集需要停用，才能完成遷移作業。請務必在遷移計畫中納入這些資源的淘汰作業。
建立 Kubernetes 工作負載的清單
完成 Kubernetes 叢集清查並評估環境安全性後，請建立部署在這些叢集中的工作負載清查。評估工作負載時，請收集下列方面的資訊：
- Pod 和控制器。 如要調整新環境中的叢集大小，請評估您部署的各項工作負載執行個體數量，以及您是否使用資源配額和運算資源用量限制。收集每個叢集控制層節點上執行的工作負載，以及每個工作負載使用的控制器相關資訊。舉例來說，您目前使用多少個部署作業？您目前使用多少個 DaemonSets？
- 工作和 CronJobs。 叢集和工作負載可能需要執行 Job 或 CronJob，做為初始化或作業程序的一部分。評估您已部署多少個 Job 和 CronJob 執行個體，以及每個執行個體的責任和完成條件。
- Kubernetes 自動調度資源。如要在新環境中遷移自動調度政策，請瞭解水平 Pod 自動調度器和垂直 Pod 自動調度器在 GKE 的運作方式。
- 無狀態和有狀態工作負載。無狀態工作負載不會將資料或狀態儲存到叢集或永久儲存空間。有狀態的應用程式會儲存資料以供日後使用。針對每個工作負載，評估哪些元件是無狀態，哪些是有狀態，因為遷移有狀態工作負載通常比遷移無狀態工作負載更困難。
- Kubernetes 功能。從叢集清單中，您可以瞭解每個叢集執行的 Kubernetes 版本。請參閱各 Kubernetes 版本的版本資訊，瞭解該版本提供的功能和已淘汰的功能。然後根據您需要的功能評估工作負載。這項工作的目標是瞭解您是否使用已淘汰的功能，或是 GKE 尚未提供的功能。如果發現任何無法使用的功能，請從已淘汰的功能遷移，並在新功能於 GKE 中推出時採用。
- 儲存空間。對於有狀態的工作負載，請評估是否使用 PersistenceVolumeClaims。列出所有儲存空間需求，例如大小和存取模式，以及這些 PersistenceVolumeClaim 如何對應至 PersistenceVolume。為因應未來成長，請評估是否需要擴充任何 PersistenceVolumeClaim。
- 設定和 Secret 注入。為避免每次環境設定變更時都必須重建可部署構件，請使用 ConfigMaps 和 Secret，將設定和密鑰注入 Pod。針對每個工作負載，評估該工作負載使用的 ConfigMap 和 Secret，以及您填入這些物件的方式。
- 依附元件。您的工作負載可能不會獨立運作。這些服務可能具有叢集內部或外部系統的依附元件。針對每個工作負載，擷取依附元件，並瞭解工作負載對依附元件無法使用的容許程度。舉例來說，常見的依附元件包括分散式檔案系統、資料庫、密碼發布平台、身分與存取權管理系統、服務探索機制，以及任何其他外部系統。
- Kubernetes Service。如要向內部和外部用戶端公開工作負載，請使用服務。您需要瞭解每項服務的類型。如果是對外公開的服務，請評估該服務與基礎架構其餘部分的互動方式。舉例來說，您的基礎架構如何支援 LoadBalancer 服務、Gateway 物件和 Ingress 物件？您在叢集中部署了哪些 Ingress 控制器？
- 服務網格。如果您在環境中使用服務網格，請評估其設定方式。您也需要瞭解服務網格涵蓋的叢集數量、網格包含的服務，以及如何修改網格的拓撲。
- Taint 和容許條件 以及相依性和反相依性。 針對每個 Pod 和節點，評估您是否已設定任何節點 taint、Pod 容許條件或親和性，以便自訂 Kubernetes 叢集中 Pod 的排程。這些屬性也可能提供洞察資料，瞭解可能的非同質節點或 Pod 設定，並可能表示需要特別關注和照護 Pod、節點或兩者。舉例來說，如果您設定一組特定的 Pod，只在 Kubernetes 叢集中的特定節點上排程，可能表示這些 Pod 需要的專屬資源只在這些節點上提供。
- 驗證：評估工作負載如何針對叢集中的資源和外部資源進行驗證。
評估支援服務和外部依附元件
評估叢集和工作負載後，請評估基礎架構中其餘的支援服務和層面，例如：
- StorageClasses 和 PersistentVolumes。列出動態佈建的 StorageClasses，以及靜態佈建的 PersistentVolumes，評估基礎架構如何支援 PersistentVolumeClaim。請為每個 PersistentVolume 考量下列事項：容量、磁碟區模式、存取模式、類別、回收政策、掛接選項和節點親和性。
- VolumeSnapshots 和 VolumeSnapshotContents。 針對每個 PersistentVolume，評估您是否已設定任何 VolumeSnapshot，以及是否需要遷移任何現有的 VolumeSnapshotContents。
- Container Storage Interface (CSI) 驅動程式。如果部署在叢集中，請評估這些驅動程式是否與 GKE 相容，以及是否需要調整磁碟區的設定，才能使用與 GKE 相容的 CSI 驅動程式。
- 資料儲存。如果您依賴外部系統佈建 PersistentVolume，請提供方法，讓 GKE 環境中的工作負載使用這些系統。資料位置會影響有狀態工作負載的效能，因為外部系統與 GKE 環境之間的延遲時間與兩者之間的距離成正比。針對每個外部資料儲存系統，請考量其類型 (例如區塊磁碟區、檔案儲存空間或物件儲存空間)，以及需要滿足的任何效能和可用性需求。
- 自訂資源和 Kubernetes 外掛程式。收集您可能已在叢集中部署的任何自訂 Kubernetes 資源和 Kubernetes 外掛程式相關資訊，因為這些資源可能無法在 GKE 中運作，或您可能需要修改這些資源。舉例來說，如果自訂資源與外部系統互動，請評估這是否適用於您的 Google Cloud 環境。
- 備份。評估您在來源環境中備份叢集設定和有狀態工作負載資料的方式。
評估部署和作業程序
請務必清楚瞭解部署和作業程序。這些程序是準備及維護實際工作環境和其中執行工作負載的實務做法，也是不可或缺的一環。
部署和作業程序可能會建構工作負載運作所需的構件。因此，您應收集各個構件類型的相關資訊。例如，構件可以是作業系統套件、應用程式部署套件、作業系統映像檔、容器映像檔或其他項目。
除了構件類型，請考慮如何完成下列工作：
- 開發工作負載。評估開發團隊建構工作負載的流程。舉例來說，開發團隊如何設計、編碼及測試工作負載？
- 產生要在來源環境中部署的構件。如要在來源環境中部署工作負載，您可能需要產生可部署的構件 (例如容器映像檔或作業系統映像檔)，或是自訂現有構件 (例如安裝及設定軟體，藉此自訂第三方作業系統映像檔)。收集有關如何產生這些構件的資訊，有助於確保產生的構件適合在Google Cloud中部署。
儲存構件。如果您在來源環境的構件登錄中產生構件並儲存，則必須在 Google Cloud 環境中提供這些構件。您可以採用下列策略：
- 在環境之間建立通訊管道：讓目標環境可存取來源環境中的構件。Google Cloud
- 重構構件建構程序：完成來源環境的次要重構，以便在來源環境和目標環境中儲存構件。這種做法可讓您在目標 Google Cloud環境中實作構件建構程序之前，先建構構件存放區等基礎架構，進而支援遷移作業。您可以直接採用這種做法，也可以先建立通訊管道，再採用這種做法。
如果來源和目標環境都有可用的構件，您就能專注於遷移作業，不必在目標環境中實作構件建構程序，做為遷移作業的一部分。 Google Cloud
掃描並簽署程式碼。在構件建構程序中，您可能會使用程式碼掃描功能，防範常見的安全性漏洞和非預期的網路曝光，並使用程式碼簽署功能，確保只有受信任的程式碼會在環境中執行。
在來源環境中部署構件。產生可部署的構件後，您可能會在來源環境中部署這些構件。建議您評估每個部署程序。這項評估可確保您的部署程序與 Google Cloud相容。此外，您也能瞭解最終重構程序所需的作業量。舉例來說，如果部署程序只適用於來源環境，您可能需要重構這些程序，才能以 Google Cloud 環境為目標。
注入執行階段設定。您可能會為特定叢集、執行階段環境或工作負載部署作業注入執行階段設定。設定可能會初始化環境變數和其他設定值，例如密鑰、憑證和金鑰。為確保執行階段設定注入程序可在 Google Cloud上運作，建議您評估來源環境中執行的工作負載設定方式。
記錄、監控及剖析。評估您現有的記錄、監控和剖析程序，瞭解如何監控來源環境的健康狀態、感興趣的指標，以及您如何使用這些程序提供的資料。
驗證。評估您在來源環境中進行驗證的方式。
佈建及設定資源。為準備來源環境，您可能已設計及實作佈建和設定資源的程序。舉例來說，您可能會使用 Terraform 和設定管理工具，在來源環境中佈建及設定資源。
用來建立來源環境商品目錄的工具
如要建立 Amazon EKS 叢集的清單，建議使用 Migration Center，Google Cloud這個統合式平台可協助您加快從目前環境遷移至 Google Cloud的端對端雲端旅程。您可以透過 Migration Center 匯入 Amazon EKS 和其他 AWS 資源的資料。Migration Center 接著會建議可遷移的相關 Google Cloud服務。
完善 Amazon EKS 叢集和工作負載的清查資料
遷移中心提供的資料可能無法完全擷取您感興趣的維度。在這種情況下，您可以將該資料與其他資料收集機制 (根據 AWS API、AWS 開發人員工具和 AWS 指令列介面建立) 的結果整合。
除了從遷移中心取得的資料，請針對要遷移的每個 Amazon EKS 叢集，考量下列資料點：
- 請考量每個 Amazon EKS 叢集的 Amazon EKS 專屬層面和功能，包括：
- 私人叢集
- 叢集端點存取權控管
- 密鑰加密
- 代管節點群組和自行管理的節點
- Amazon EKS 資源的標記
- EKS 中的 Amazon 自訂 AMI
- Amazon EKS Fargate 的用量
- Amazon EKS Managed Prometheus 的用量
- OpenID Connect 驗證設定
- 評估您如何對 Amazon EKS 叢集進行驗證，以及如何為 Amazon EKS 設定 AWS 身分與存取權管理 (IAM)。
- 評估 Amazon EKS 叢集的網路設定。
規劃及建立基礎
在規劃和建構階段，您會佈建及設定基礎架構，以執行下列操作：
- 滿足環境中的工作負載需求。 Google Cloud
- 連線來源環境和 Google Cloud 環境，完成遷移作業。
規劃和建構階段包含下列工作：
- 建立資源階層。
- 設定 Google Cloud身分與存取權管理 (IAM)。
- 設定帳單資訊。
- 設定網路連線。
- 強化安全性。
- 設定記錄、監控和快訊功能。
如要進一步瞭解各項工作，請參閱「遷移至 Google Cloud：規劃及建構基礎」。
以下各節內容整合了「遷移至Google Cloud：規劃及建構基礎」中的注意事項。
規劃多用戶群
如要設計有效率的資源階層，請考量您的業務和機構架構如何對應至 Google Cloud。舉例來說，如果您需要在 GKE 上建立多租戶環境，可以選擇下列選項：
- 為每個租戶建立一個 Google Cloud 專案。
- 在不同租戶之間共用一個專案，並佈建多個 GKE 叢集。
- 使用 Kubernetes 命名空間。
具體取決於您的隔離、複雜度和擴充性需求。舉例來說，每個租戶都有一個專案，可讓租戶彼此隔離，但專案數量過多會導致資源階層管理更加複雜。不過，雖然管理 Kubernetes 命名空間比複雜的資源階層簡單，但這個選項無法保證有同等程度的隔離效果。舉例來說，控制層可能會在租戶之間共用。詳情請參閱叢集多用戶群架構。
設定身分與存取權管理
GKE 支援多種選項，可讓您使用 RBAC 管理 Google Cloud 專案及其叢集內資源的存取權。詳情請參閱存取權控管一文。
設定 GKE 網路
網路設定是環境的基本要素。在佈建及設定任何叢集之前，建議您先評估 GKE 網路模型、GKE 網路最佳做法，以及遷移至 GKE 時如何規劃 IP 位址。
設定監控和快訊
清楚瞭解基礎架構和工作負載的執行情況，是找出改善領域的關鍵。GKE與 Google Cloud Observability 深度整合，因此您可以取得 GKE 叢集和叢集內工作負載的記錄、監控和剖析資訊。
遷移資料並部署工作負載
在部署階段，您將執行下列操作：
- 佈建及設定 GKE 環境。
- 設定 GKE 叢集。
- 重構工作負載。
- 重構部署和作業程序。
- 將資料從來源環境遷移至 Google Cloud。
- 在 GKE 環境中部署工作負載。
- 驗證工作負載和 GKE 環境。
- 公開在 GKE 上執行的工作負載。
- 將流量從來源環境轉移至 GKE 環境。
- 停用來源環境。
佈建及設定 Google Cloud 環境
將工作負載遷移至新 Google Cloud 環境前，請先佈建 GKE 叢集。
GKE 支援在現有叢集上啟用特定功能，但部分功能可能只能在建立叢集時啟用。為避免中斷服務並簡化遷移作業，建議您在建立叢集時啟用所需叢集功能。否則，如果叢集建立後無法啟用所需功能，您可能需要毀損並重新建立叢集。
完成評估階段後，您現在已瞭解如何在新的 Google Cloud 環境中佈建 GKE 叢集，以滿足您的需求。如要佈建叢集，請注意下列事項：
- 叢集數量、每個叢集的節點數量、叢集類型、每個叢集和節點的設定，以及每個叢集的可擴充性方案。
- 每個叢集的作業模式。GKE 提供兩種叢集作業模式：GKE Autopilot 和 GKE Standard。
- 私人叢集數量。
- 虛擬私有雲原生或以路由器為基礎的網路。
- GKE 叢集所需的 Kubernetes 版本和發布版本。
- 節點集區，可邏輯分組 GKE 叢集中的節點，以及是否需要使用節點自動佈建功能自動建立節點集區。
- 您可以從環境移植到 GKE 環境的初始化程序，以及您可以實作的新程序。舉例來說，您可以為叢集中的每個節點或節點集區，實作一或多個最終具備權限的初始化程序，自動啟動 GKE 節點。
- 每個叢集的擴充性方案。
- 您需要的其他 GKE 功能，例如 Cloud Service Mesh，以及 GKE 外掛程式，例如 Backup for GKE。
如要進一步瞭解如何佈建 GKE 叢集，請參閱：
機群管理
在佈建 GKE 叢集時，您可能會發現需要大量叢集，才能支援環境的所有用途。舉例來說，您可能需要將正式環境與非正式環境區隔開來，或是區隔各個團隊或地理位置的服務。詳情請參閱多叢集應用實例。
隨著叢集數量增加，管理大量叢集會帶來顯著的擴充性和作業挑戰，因此 GKE 環境的運作可能會變得更加困難。GKE 提供工具和功能，協助您管理 fleet (Kubernetes 叢集的邏輯分組)。詳情請參閱「車隊管理」。
多叢集網路
為協助您提升 GKE 環境的穩定性，並將工作負載分配到多個 GKE 叢集，您可以採取下列做法：
- 多叢集服務探索：跨叢集服務探索和叫用機制。服務可供探索，並在 GKE 叢集之間存取。詳情請參閱「多叢集服務探索」。
- 多叢集閘道，一種跨叢集 Ingress 流量負載平衡機制。詳情請參閱「部署多叢集閘道」。
- 代管 Cloud Service Mesh 的多叢集網格。詳情請參閱「設定多叢集網格」一文。
如要進一步瞭解如何從單一叢集 GKE 環境遷移至多叢集 GKE 環境，請參閱「遷移至多叢集網路」。
設定 GKE 叢集
佈建 GKE 叢集後，部署任何工作負載或遷移資料前，請為每個 GKE 叢集設定命名空間、RBAC、網路政策、服務帳戶，以及其他 Kubernetes 和 GKE 物件。
如要在 GKE 叢集中設定 Kubernetes 和 GKE 物件，建議您採取下列做法：
- 請確認您擁有必要憑證和權限，可存取來源環境和 GKE 環境中的叢集。
- 評估來源環境中 Kubernetes 叢集的物件是否與 GKE 相容，以及這些物件的實作方式與來源環境和 GKE 有何不同。
- 重構任何不相容的物件，使其與 GKE 相容，或將其淘汰。
- 將這些物件建立至 GKE 叢集。
- 在 GKE 叢集中設定任何其他需要的物件。
Config Sync
為協助您採用 GitOps 最佳做法，在 GKE 擴充時管理 GKE 叢集的設定，建議您使用 Config Sync，這項 GitOps 服務可從可靠來源部署設定。舉例來說，您可以將 GKE 叢集的設定儲存在 Git 存放區中，並使用 Config Sync 套用該設定。
詳情請參閱「Config Sync 架構」。
Policy Controller
您可以透過 Policy Controller 套用並強制執行可程式化的政策，確保 GKE 叢集和工作負載是以安全且符合規範的方式執行。隨著 GKE 環境擴充，您可以使用 Policy Controller，自動將政策、政策套件和限制套用至所有 GKE 叢集。舉例來說，您可以限制可從中提取容器映像檔的存放區，也可以規定每個命名空間至少要有一個標籤，確保資源用量追蹤的準確度。
詳情請參閱「Policy Controller」。
重構工作負載
設計容器化工作負載的最佳做法是避免依附於容器自動調度管理平台。由於工作負載的需求和設計，實務上可能無法一律採用這種做法。舉例來說，工作負載可能依賴僅在來源環境中提供的環境專屬功能，例如外掛程式、擴充功能和整合。
雖然您或許能將大部分工作負載原封不動地遷移至 GKE，但如果工作負載依附於環境專屬功能，您可能需要花費額外心力重構工作負載，盡量減少這些依附元件，最終改用 GKE 提供的替代方案。
如要在將工作負載遷移至 GKE 前重構工作負載，請執行下列操作：
- 查看來源環境專屬功能，例如外掛程式、擴充功能和整合。
- 採用合適的替代 GKE 解決方案。
- 重構工作負載。
查看來源環境專屬功能
如果您使用來源環境專屬功能，且工作負載依賴這些功能，則必須：
- 尋找合適的 GKE 替代解決方案。
- 重構工作負載，以便使用替代的 GKE 解決方案。
建議您在審查時採取下列行動：
- 請考慮是否可以淘汰任何這些來源環境專屬功能。
- 評估來源環境專屬功能對遷移作業成功與否的重要性。
採用合適的替代 GKE 解決方案
檢查來源環境專屬功能，並將這些功能對應至合適的 GKE 替代解決方案後，即可在 GKE 環境中採用這些解決方案。為簡化遷移作業，建議您採取下列做法：
- 避免採用替代的 GKE 解決方案，以取代您打算淘汰的來源環境專屬功能。
- 請著重為最關鍵的來源環境專屬功能採用替代 GKE 解決方案，並為其餘功能規劃專屬的遷移專案。
重構工作負載
雖然大部分工作負載可能都能在 GKE 中正常運作，但您可能需要重構部分工作負載，尤其是依賴來源環境特定功能的工作負載，因為您已採用替代的 GKE 解決方案。
這項重構作業可能包括：
- 以 YAML 格式表示的 Kubernetes 物件描述元，例如 Deployment 和 Service。
- 容器映像檔描述元，例如 Dockerfile 和 Containerfile。
- 工作負載原始碼。
為簡化重構作業，建議您專注於進行最少量的變更，讓工作負載適用於 GKE，並修正重大錯誤。您可以在未來的專案中規劃其他改善措施和變更。
重構部署和營運程序
重構工作負載後，請重構部署和作業程序，以執行下列操作：
- 在 Google Cloud 環境中佈建及設定資源，而不是在來源環境中佈建資源。
- 建構及設定工作負載，並部署至 Google Cloud，而非部署至來源環境。
您已在本程序的評估階段收集這些程序的相關資訊。
您需要為這些程序考量的重構類型，取決於您設計及實作這些程序的方式。重構作業也取決於您希望每個程序最終達到什麼狀態。舉例來說，你可以嘗試下列做法：
- 您可能已在來源環境中實作這些程序，並打算在 Google Cloud中設計及實作類似程序。舉例來說，您可以重構這些程序，改用 Cloud Build、Cloud Deploy 和 Infrastructure Manager。
- 您可能已在來源環境以外的其他第三方環境中實作這些程序。在這種情況下，您需要重構這些程序，以 Google Cloud 環境為目標，而非來源環境。
- 結合上述做法。
重構部署和作業程序可能相當複雜，需要投入大量心力。如果您嘗試在工作負載遷移期間執行這些工作，工作負載遷移作業可能會變得更加複雜，而且您可能會面臨風險。評估部署和作業程序後，您可能已瞭解這些程序的設計和複雜程度。如果您預估需要大量心力才能重構部署和作業程序，建議您考慮將這些程序重構作業納入獨立專案。
如要進一步瞭解如何在 Google Cloud上設計及實作部署程序，請參閱：
本文著重於部署程序，這些程序會產生要部署的構件，並將構件部署至目標執行階段環境。重構策略很大程度上取決於這些程序的複雜程度。以下列出可能的重構策略：
- 在 Google Cloud上佈建構件存放區。舉例來說，您可以使用 Artifact Registry 儲存構件和建構依附元件。
- 重構建構程序，將構件儲存在來源環境和 Artifact Registry 中。
- 重構部署程序，在目標Google Cloud 環境中部署工作負載。舉例來說，您可以先在 Google Cloud中部署一小部分工作負載，並使用儲存在 Artifact Registry 中的構件。然後逐步增加在 Google Cloud中部署的工作負載數量，直到所有要遷移的工作負載都在Google Cloud上執行為止。
- 重構建構程序，只將構件儲存在 Artifact Registry 中。
- 如有必要，請將舊版構件從來源環境的存放區遷移至 Artifact Registry，以便部署。例如，您可以將容器映像檔複製到 Artifact Registry。
- 不再需要來源環境中的存放區時，請將其停用。
為方便在遷移期間發生非預期問題時進行回溯，您可以在遷移至 Google Cloud 的過程中，將容器映像檔同時儲存在目前的構件存放區 Google Cloud 。最後，在來源環境停用程序中，您可以重構容器映像檔建構程序，只在Google Cloud 中儲存構件。
雖然這可能不是遷移作業成功的關鍵，但您可能需要將舊版構件從來源環境遷移至 Google Cloud的構件存放區。舉例來說，如要支援將工作負載回復至任意時間點，您可能需要將舊版構件遷移至 Artifact Registry。詳情請參閱「從第三方登錄檔遷移映像檔」。
如果您使用 Artifact Registry 儲存構件，建議您設定控管機制，確保構件存放區安全無虞，例如存取控管、防止資料外洩、漏洞掃描和二進位授權。詳情請參閱「控管存取權及保護構件」。
遷移資料
GKE 支援多種資料儲存服務，例如區塊儲存空間、原始區塊儲存空間、檔案儲存空間和物件儲存空間。詳情請參閱「GKE 叢集儲存空間總覽」。
如要將資料遷移至 GKE 環境，請執行下列操作：
- 佈建及設定所有必要的儲存空間基礎架構。
- 在 GKE 叢集中設定 StorageClass 佈建器。並非所有 StorageClass 佈建器都與所有環境相容。部署 StorageClass 佈建器前，建議您先評估其與 GKE 的相容性，以及相關依附元件。
- 設定 StorageClasses。
- 設定 PersistentVolume 和 PersistentVolumeClaim，以儲存要遷移的資料。
- 將資料從來源環境遷移至這些 PersistentVolume。資料遷移的具體細節取決於來源環境的特性。
如要將資料從來源環境遷移至 Google Cloud環境，建議您按照「遷移至 Google Cloud：轉移大型資料集」一文的指引，設計資料遷移計畫。
將資料從 EKS 遷移至 GKE
AWS 為 Amazon EKS 提供多種資料儲存選項。本文著重說明下列資料遷移情境：
- 將 Amazon EBS 磁碟區中的資料遷移至 GKE
PersistentVolume資源。 - 將 Amazon EBS 磁碟區中的資料複製到 Amazon S3 或 Cloud Storage，然後將資料遷移至 GKE
PersistentVolume資源。
將 Amazon EBS 磁碟區中的資料遷移至 GKE PersistentVolume
您可以採用下列任一方法，將 Amazon EBS 磁碟區的資料遷移至 GKE PersistentVolume 資源：
- 直接將資料從 Amazon EBS 磁碟區複製到 Compute Engine 永久磁碟：
- 佈建 Amazon EC2 執行個體，並連結包含要遷移資料的 Amazon EBS 磁碟區。
- 佈建 Compute Engine 執行個體，並提供容量足夠的空白永久磁碟，以儲存要遷移的資料。
- 執行資料同步工具 (例如 rsync)，將資料從 Amazon EBS 磁碟區複製到 Compute Engine 永久磁碟。
- 從 Compute Engine 執行個體卸離永久磁碟。
- 停用 Compute Engine 執行個體。
- 將永久磁碟設定為 GKE
PersistentVolume資源。
- 將 Amazon EC2 執行個體和 Amazon EBS 磁碟區遷移至 Compute Engine：
- 佈建 Amazon EC2 執行個體，並連結包含要遷移資料的 Amazon EBS 磁碟區。
- 使用 Migrate for Virtual Machines 將 Amazon EC2 執行個體和 Amazon EBS 磁碟區遷移至 Compute Engine。
- 從 Compute Engine 執行個體卸離永久磁碟。
- 停用 Compute Engine 執行個體。
- 將永久磁碟設定為 GKE
PersistentVolume資源。
如要進一步瞭解如何將 Amazon EC2 執行個體遷移至 Compute Engine，請參閱「從 AWS 遷移至 Google Cloud：將 Amazon EC2 遷移至 Compute Engine」。
如要進一步瞭解如何將 Compute Engine 永久磁碟做為 GKE PersistentVolume 資源使用，請參閱「使用既有的永久磁碟做為 PersistentVolumes」。
將 Amazon EBS 磁碟區中的資料複製到臨時媒體，然後遷移至 GKE 永久磁碟區
您可以先使用物件儲存空間等中介媒體，再從 Amazon EBS 磁碟區遷移至 GKE PersistentVolume 資源，不必直接遷移：
- 將 Amazon EBS 磁碟區的資料上傳至中繼媒體，例如 Amazon S3 值區或 Cloud Storage 值區。
- 將暫時性媒體中的資料下載至 GKE
PersistentVolume資源。
在某些情況下，使用多個媒體可根據網路和安全性設定簡化資料轉移作業。舉例來說，您可以先將資料上傳至 S3 值區，然後從 S3 值區複製到 Cloud Storage 值區，最後將資料下載至永久磁碟區。無論選擇哪種方法，為確保順利轉換並注意重要考量事項，建議您參閱「從 AWS 遷移 Google Cloud：從 Amazon S3 遷移至 Cloud Storage」。
選擇遷移方式
最適合的遷移選項取決於您的特定需求和規定，例如：
- 您需要遷移的資料量。
- 如果需要遷移的資料量不大 (例如幾個資料檔案)，建議使用 rsync 等工具，將資料直接複製到 Compute Engine 永久磁碟。這個選項相對快速，但可能不適合大量資料。
- 如果需要遷移大量資料，建議使用 Migrate to Virtual Machines 將資料遷移至 Compute Engine。這個選項比直接複製資料更複雜，但更可靠且可擴充。
- 需要遷移的資料類型。
- 來源和目標環境之間的網路連線。
- 如果無法在 AWS EC2 和 Compute Engine 執行個體之間建立直接網路連線，建議您考慮使用 Amazon S3 或 Cloud Storage 暫時儲存資料，然後再移轉至 Compute Engine。這個選項可能較便宜，因為您不必同時執行 EC2 和 Compute Engine 執行個體。
- 您的遷移時程。
- 如果網路頻寬有限或資料量龐大，且時間充裕，也可以考慮使用 Transfer Appliance 將資料從 AWS 移至 Google Cloud。
無論選擇哪種方式，請務必先測試遷移作業，再正式上線。測試有助於找出任何潛在問題，確保遷移作業順利完成。
部署工作負載
部署程序準備就緒後，即可將工作負載部署至 GKE。詳情請參閱工作負載部署總覽。
如要準備部署至 GKE 的工作負載，建議您分析 Kubernetes 描述元，因為 GKE 自動佈建的部分資源可透過 Kubernetes 標籤和註解設定，不必手動佈建這些資源。 Google Cloud舉例來說，您可以在 LoadBalancer 服務中新增註解，佈建內部負載平衡器，而非外部負載平衡器。
驗證工作負載
在 GKE 環境中部署工作負載後，建議您先進行大規模驗證和測試，再向使用者公開這些工作負載。這項測試可協助您確認工作負載是否如預期運作。舉例來說，您可以：
- 執行整合測試、負載測試、法規遵循測試、可靠性測試和其他驗證程序，確保工作負載在預期參數內運作，並符合規格。
- 在 Google Cloud Observability 中檢查記錄、指標和錯誤報告，找出潛在問題，並掌握趨勢，在問題發生前預先防範。
如要進一步瞭解工作負載驗證，請參閱「測試可靠性」。
公開工作負載
完成 GKE 環境中執行工作負載的驗證測試後，請公開工作負載，讓使用者可以存取。
如要公開 GKE 環境中執行的工作負載，可以使用 Kubernetes Service 和服務網格。
如要進一步瞭解如何公開在 GKE 中執行的工作負載，請參閱：
將流量轉移至 Google Cloud 環境
確認工作負載在 GKE 環境中執行，並向用戶端公開後，即可將流量從來源環境轉移至 GKE 環境。為協助您避免大規模遷移，以及所有相關風險，建議您逐步將流量從來源環境轉移至 GKE。
視您設計 GKE 環境的方式而定，您可以選擇幾種方法來實作負載平衡機制，逐步將流量從來源環境轉移至目標環境。舉例來說，您可以實作 DNS 解析政策，根據某些政策解析 DNS 記錄，將一定比例的要求解析至屬於 GKE 環境的 IP 位址。或者，您可以使用虛擬 IP 位址和網路負載平衡器，實作負載平衡機制。
開始逐步將流量轉移至 GKE 環境後，建議您監控工作負載的行為，瞭解負載增加時的狀況。
最後，您會執行轉換，也就是將所有流量從來源環境轉移至 GKE 環境。
如要進一步瞭解負載平衡，請參閱前端的負載平衡。
停用來源環境
GKE 環境中的工作負載正確處理要求後，即可停用來源環境。
開始停用來源環境中的資源之前，建議您執行下列操作：
- 備份所有資料，以便還原來源環境中的資源。
- 在停用環境前，請先通知使用者。
如要停用來源環境，請按照下列步驟操作：
- 停用來源環境叢集中執行的工作負載。
- 刪除來源環境中的叢集。
- 刪除與這些叢集相關聯的資源，例如安全群組、負載平衡器和虛擬網路。
為避免留下孤立資源，請務必依正確順序停用來源環境中的資源。舉例來說，某些供應商會要求您先停用導致建立負載平衡器的 Kubernetes 服務，才能停用含有這些負載平衡器的虛擬網路。
最佳化環境 Google Cloud
最佳化是遷移的最後階段。在這個階段，您會反覆執行最佳化工作，直到目標環境符合最佳化需求為止。每次疊代的步驟如下：
- 評估目前的環境、團隊和最佳化迴圈。
- 建立最佳化需求和目標。
- 最佳化環境和團隊。
- 調整最佳化迴圈。
重複這個程序，直到達成最佳化目標為止。
如要進一步瞭解如何最佳化 Google Cloud 環境，請參閱「遷移至 Google Cloud：最佳化環境」和「Google Cloud 架構完善的架構：效能最佳化」。
以下各節整合了「遷移至Google Cloud：將環境調整成最佳狀態」一文中的注意事項。
確立最佳化要求
最佳化需求可協助您縮小目前最佳化疊代的範圍。如要進一步瞭解最佳化需求和目標，請參閱確立最佳化需求和目標。
如要為 GKE 環境設定最佳化需求，請先考量下列層面：
- 安全性、隱私權和法規遵循：協助您提升 GKE 環境的安全防護機制。
- 可靠性：協助您提升 GKE 環境的可用性、可擴充性和復原能力。
- 成本最佳化：協助您最佳化 GKE 環境的資源消耗量和支出。
- 營運效率：協助您有效維護及運作 GKE 環境。
- 效能最佳化：協助您最佳化部署在 GKE 環境中的工作負載效能。
安全性、隱私權和法規遵循
- 監控 GKE 叢集的安全防護機制。您可以透過安全防護機制資訊主頁取得具體可行的建議，藉此提升 GKE 環境的安全防護機制。
- 強化 GKE 環境。瞭解 GKE 安全性模式，以及如何強化 GKE 叢集。
- 保護軟體供應鏈。對於安全性至關重要的工作負載，Google Cloud 提供一組模組化產品，在整個軟體生命週期中實作軟體供應鏈安全最佳做法。
可靠性
提高叢集的可靠性。為協助您設計 GKE 叢集，以因應不太可能發生的區域性服務中斷，建議您優先使用區域叢集，而非區域或多區域叢集。
工作負載備份與還原。使用 GKE 備份服務設定工作負載備份和還原工作流程。
成本最佳化
如要進一步瞭解如何最佳化 GKE 環境的成本，請參閱：
提升作業效率
為避免影響正式環境的問題，建議您採取下列做法：
- 將 GKE 叢集設計為可互換。將叢集視為可互換的資源，並自動佈建及設定叢集，即可簡化及一般化叢集維護作業流程，同時簡化日後的遷移作業和 GKE 叢集升級作業。舉例來說，如果您需要將可互換的 GKE 叢集升級至新的 GKE 版本，可以自動佈建及設定升級後的新叢集、自動在新叢集中部署工作負載，並停用舊的過時 GKE 叢集。
- 監控感興趣的指標。請確保系統已正確收集工作負載和叢集的所有相關指標。此外，請確認所有使用這些指標做為輸入內容的相關快訊都已就位，且運作正常。
如要進一步瞭解如何在 GKE 環境中設定監控、記錄和剖析功能，請參閱：
效能最佳化
- 設定叢集自動調度資源和節點自動佈建。使用叢集自動調度資源和節點自動佈建功能，根據需求自動調整 GKE 叢集大小。
- 自動調整工作負載的資源配置。GKE 支援多種資源調度機制，例如：
- 根據指標自動調整工作負載。
- 設定水平 Pod 自動調度資源，自動調整 Kubernetes 工作負載的 Pod 數量，進而調整工作負載規模。
- 設定垂直 Pod 自動調度資源，調整資源要求和限制，自動調度工作負載資源。
詳情請參閱「關於 GKE 可擴充性」。
後續步驟
- 瞭解其他 AWS 遷移至 Google Cloud 的歷程。
- 瞭解如何比較 AWS 和 Azure 服務與 Google Cloud。
- 瞭解何時應尋求遷移作業的相關協助。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。
貢獻者
作者：
- Marco Ferrari | 雲端解決方案架構師
- Xiang Shen | 解決方案架構師