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 和 AlloyDB for PostgreSQL
- 從 Amazon RDS for SQL Server 遷移至 SQL Server 適用的 Cloud SQL
- 從 AWS Lambda 遷移至 Cloud Run
GKE 是 Google 代管的 Kubernetes 服務，可讓您透過 Google 的基礎架構，大規模部署及操作容器化應用程式，並提供可協助您管理 Kubernetes 環境的功能，例如：
- 兩種作業模式：Standard 和 Autopilot。在 Standard 模式下，您必須管理 GKE 叢集中每個節點的基礎架構和設定。在 Autopilot 模式下，GKE 會管理底層基礎架構，例如節點設定、自動調度資源、自動升級、基準安全性，以及網路設定。如要進一步瞭解 GKE 作業模式，請參閱「選擇 GKE 作業模式」。
- 在多個可用區使用 Autopilot 時，可享有業界獨一無二的 Pod 服務水準協議。
- 使用自動佈建節點功能，自動建立及刪除節點集區。
- 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 叢集盤點作業後，請盤點命名空間和已部署的 Kubernetes 物件，以保護 Kubernetes 叢集：
- 命名空間。如果您在叢集中使用 Kubernetes 命名空間，以邏輯方式分隔資源，請評估每個命名空間中的資源，並瞭解建立這項分隔的原因。舉例來說，您可能在多租戶策略中使用了命名空間。您可能已在保留給 Kubernetes 系統元件的命名空間中部署工作負載，但在 GKE 中可能沒有太多控制權。
- 角色式存取控管 (RBAC)。如果您在叢集中使用 RBAC 授權，請列出您在叢集中設定的所有 ClusterRole 和 ClusterRoleBinding 的說明。
- 網路政策。列出您在叢集中設定的所有網路政策，並瞭解網路政策在 GKE 中的運作方式。
- Pod 安全性情境。擷取您在叢集中設定的 Pod 安全性背景資訊相關資訊，並瞭解其在 GKE 中的運作方式。
- 服務帳戶。如果叢集中的任何程序與 Kubernetes API 伺服器互動，請擷取其使用的服務帳戶相關資訊。
建立 Kubernetes 工作負載的清單
完成 Kubernetes 命名空間盤點後，請盤點部署在這些叢集中的工作負載和 Kubernetes 物件。評估工作負載時，請收集下列各方面的資訊：
- Pod 和控制器。如要調整新環境中的叢集大小，請評估您部署的各項工作負載執行個體數量，以及是否使用資源配額和運算資源消耗限制。收集各叢集控制層節點上執行的工作負載，以及各工作負載使用的控制器相關資訊。例如，您使用了多少個部署項目？您使用多少個 DaemonSets？
- 工作和 CronJobs。叢集和工作負載可能需要執行工作或 CronJob，做為初始化或作業程序的一部分。評估您部署了多少個 Jobs 和 CronJobs 執行個體，以及每個執行個體的責任和完成條件。
- Kubernetes 自動配置器。如要在新環境中遷移自動調度資源政策，請瞭解水平 Pod 自動配置器和垂直 Pod 自動配置器在 GKE 中的運作方式。
- 無狀態和有狀態工作負載。無狀態工作負載不會將資料或狀態保存在叢集或永久儲存空間。有狀態應用程式會儲存資料供日後使用。針對每項工作負載，評估哪些元件是無狀態，哪些是有狀態，因為遷移有狀態工作負載通常比遷移無狀態工作負載更困難。
- Kubernetes 功能。您可以從叢集清單中，瞭解每個叢集執行的 Kubernetes 版本。請參閱各 Kubernetes 版本的版本資訊，瞭解該版本提供的功能和淘汰的功能。接著，根據您需要的 Kubernetes 功能評估工作負載。這項工作的目標是瞭解您是否使用已淘汰的功能，或 GKE 尚未提供的功能。如果發現任何無法使用的功能，請從已淘汰的功能遷移，並在 GKE 提供新功能時採用。
- 儲存空間。針對有狀態的工作負載，請評估是否使用 PersistenceVolumeClaims。列出所有儲存空間需求，例如大小和存取模式，以及這些 PersistenceVolumeClaim 如何對應至 PersistenceVolume。為因應未來成長，請評估是否需要擴充任何 PersistenceVolumeClaim。
- 設定和 Secret 插入。為避免每次環境設定變更時，都要重新建構可部署的構件，請使用 ConfigMaps 和 Secret 將設定和 Secret 插入 Pod。針對每項工作負載，評估該工作負載使用的 ConfigMap 和 Secret，以及您填入這些物件的方式。
- 依附元件。工作負載可能不會單獨運作。這些工作負載可能具有依附元件，無論是叢集內部或外部系統。針對每個工作負載，擷取依附元件，並確認工作負載是否能容忍依附元件無法使用的情況。例如，常見的依附元件包括分散式檔案系統、資料庫、密鑰發布平台、身分與存取權管理系統、服務探索機制，以及任何其他外部系統。
- Kubernetes 服務。如要向內部和外部用戶端公開工作負載，請使用 Service。您必須瞭解每項 Service 的類型。對於對外公開的服務，請評估該服務與基礎架構其他部分的互動方式。例如，您的基礎架構如何支援 LoadBalancer 服務、Gateway 物件和 Ingress 物件？您在叢集中部署了哪些 Ingress 控制器？
- 服務網格。如果您在環境中使用服務網格，請評估其設定方式。您也需要知道網格涵蓋多少叢集、哪些服務屬於網格，以及如何修改網格的拓撲。
- taint 和容許條件，以及親和性和反親和性。針對每個 Pod 和節點，評估是否設定了任何節點污點、Pod 容許或親和性，以自訂 Kubernetes 叢集中的 Pod 排程。這些屬性也可能讓您深入瞭解可能不均勻的節點或 Pod 設定，並可能表示需要特別關注和謹慎評估 Pod、節點或兩者。舉例來說，如果您將一組特定 Pod 設為只能在 Kubernetes 叢集中的特定節點上排程，這可能表示 Pod 需要專用資源，而這些資源只能在這些節點上使用。
- 驗證：評估工作負載如何對叢集中的資源和外部資源進行驗證。
評估支援服務和外部依附元件
評估叢集及其工作負載後，請評估基礎架構中的其他支援服務和層面，例如：
- StorageClasses 和 PersistentVolume。列出動態佈建的 StorageClasses 和靜態佈建的 PersistentVolumes，評估基礎架構如何支援 PersistentVolumeClaim。針對每個 PersistentVolume，請考量下列事項：容量、磁碟區模式、存取模式、類別、回收政策、掛接選項和節點親和性。
- VolumeSnapshots 和 VolumeSnapshotContents。針對每個 PersistentVolume，評估是否已設定任何 VolumeSnapshot，以及是否需要遷移任何現有的 VolumeSnapshotContents。
- 容器儲存空間介面 (CSI) 驅動程式。如果已在叢集中部署，請評估這些驅動程式是否與 GKE 相容，以及是否需要調整磁碟區設定，以便與與 GKE 相容的 CSI 驅動程式搭配使用。
- 資料儲存庫。如果您需要透過外部系統佈建 PersistentVolume，請提供一種方法，讓 GKE 環境中的工作負載使用這些系統。資料位置會影響有狀態工作負載的效能，因為外部系統與 GKE 環境之間的延遲時間，與兩者之間的距離成正比。針對每個外部資料儲存系統，請考量其類型 (例如區塊磁碟區、檔案儲存空間或物件儲存空間)，以及必須滿足的效能和可用性需求。
- 自訂資源和 Kubernetes 外掛程式。收集您可能已在叢集中部署的任何自訂 Kubernetes 資源和 Kubernetes 外掛程式相關資訊，因為這些資源可能無法在 GKE 中運作，或者您可能需要修改這些資源。舉例來說，如果自訂資源與外部系統互動，您需要評估這是否適用於 Google Cloud 環境。
- 備份。評估您在來源環境中備份叢集設定和有狀態工作負載資料的方式。
建立資產清單及評估來源環境的工具
如要收集 Amazon EKS 叢集和物件的必要資料點，請使用下列工具：
- 探索 Amazon EKS 叢集、探索及評估節點。如要探索 Amazon EKS 叢集，建議您使用 KubeScan，並透過 Migration Center 修正資產清單。Migration Center 是 Google Cloud的整合式平台，可協助您加快從目前環境遷移至 Google Cloud的端對端雲端旅程。Migration Center 會探索 Amazon EKS 叢集和叢集節點，並提供評估建議，協助您調整 GKE 環境。
- Kubernetes 物件庫存。如要建立 Kubernetes 叢集中部署的物件清單，建議您使用 KubeScan。
- Kubernetes 物件評估。如要評估 Kubernetes 物件，建議您使用 Gemini CLI。舉例來說，您可以將列出叢集中 Kubernetes 物件的清查檔案新增至 Gemini CLI 內容，然後提示 Gemini 協助您評估這些物件。詳情請參閱「運用 Gemini 遷移至 Google Cloud」。
精細管理 Amazon EKS 叢集和工作負載的清單
Migration Center 提供的資料可能無法完整擷取您感興趣的維度。在這種情況下，您可以將該資料與其他資料收集機制的結果整合，這些機制是您根據 AWS API、AWS 開發人員工具和 AWS 指令列介面建立。
除了從 Migration Center 取得的資料外，請考量要遷移的各個 Amazon EKS 叢集下列資料點：
- 請考量每個 Amazon EKS 叢集的 Amazon EKS 專屬層面和功能，包括：
- 私人叢集
- 叢集端點存取控管
- Secret 加密
- Amazon EKS 資源的標記
- EKS 中的 Amazon 自訂 AMI
- Amazon EKS Managed Prometheus 的使用情形
- OpenID Connect 驗證設定
- 評估您如何對 Amazon EKS 叢集進行驗證，以及如何為 Amazon EKS 設定 AWS Identity and Access Management (IAM)。
- 評估 Amazon EKS 叢集的網路設定。
評估部署和作業流程
請務必清楚瞭解部署和作業流程的運作方式。這些程序是準備及維護正式環境和其中執行的工作負載時，不可或缺的基本做法。
部署和作業程序可能會建構工作負載運作所需的構件。因此，您應該收集每種構件類型的資訊。例如，構件可以是作業系統套件、應用程式部署套件、作業系統映像檔、容器映像檔或其他項目。
除了構件類型外，請思考如何完成下列工作：
- 開發工作負載。評估開發團隊建構工作負載的流程。例如，開發團隊如何設計、編寫及測試工作負載？
- 產生要在來源環境中部署的構件。如要在來源環境中部署工作負載，您可能會產生可部署的構件 (例如容器映像檔或作業系統映像檔)，也可能會自訂現有構件 (例如透過安裝及設定軟體來自訂第三方作業系統映像檔)。收集這些構件的生成方式資訊，有助於確保生成的構件適合部署在Google Cloud中。
儲存構件。如果您在來源環境中產生並儲存構件，則必須在 Google Cloud 環境中提供這些構件。您可以採用下列策略：
- 在環境之間建立通訊管道：讓目標Google Cloud 環境可以存取來源環境中的構件。
- 重構構件建構程序：對來源環境進行小幅重構，以便在來源環境和目標環境中儲存構件。這種做法可讓您在目標 Google Cloud環境中實作構件建構程序之前，先建構構件存放區等基礎架構，進而支援遷移作業。您可以直接採用這種方法，也可以先建立通訊管道，再採用這種方法。
在來源和目標環境中提供構件，可讓您專注於遷移作業，而不必在目標 Google Cloud 環境中實作構件建構程序，做為遷移作業的一部分。
掃描及簽署程式碼。在建構構件的過程中，您可能會使用程式碼掃描功能，防範常見的安全漏洞和意外的網路暴露，並使用程式碼簽署功能，確保只有受信任的程式碼會在環境中執行。
在來源環境中部署構件。生成可部署的構件後，您可能會在來源環境中部署這些構件。建議您評估各項部署程序。這項評估有助於確保部署程序與 Google Cloud相容。此外，您也能瞭解最終重構程序所需的工作。舉例來說，如果部署程序僅適用於來源環境，您可能需要重構這些程序，以指定 Google Cloud 環境。
插入執行階段設定。您可能正在為特定叢集、執行階段環境或工作負載部署作業，插入執行階段設定。設定可能會初始化環境變數和其他設定值，例如 Secret、憑證和金鑰。為確保執行階段設定插入程序能在 Google Cloud上運作，建議您評估來源環境中執行的工作負載設定方式。
記錄、監控和剖析。評估現有的記錄、監控和分析程序，監控來源環境的健康狀態、相關指標，以及如何使用這些程序提供的資料。
驗證。評估您對來源環境的驗證方式。
佈建及設定資源。為了準備來源環境，您可能已設計並實作佈建及設定資源的程序。舉例來說，您可能會使用 Terraform 搭配設定管理工具，在來源環境中佈建及設定資源。如果您使用 Terraform，可以根據偏好的起點，使用下列工具在 Google Cloud 上建構基礎和登陸區：
- Google Cloud Terraform Provider 中的資源：使用基本建構模塊從頭開始。
- Google Cloud的 Terraform 藍圖和模組： 從基準 Terraform 模組開始。這種方法是以 Google Cloud Terraform 供應商中的資源為基礎。
- 企業基礎藍圖：從預先設定的基礎和登陸區開始。這個方法是以 Google Cloud的 Terraform 藍圖和模組為基礎。
- Cloud Foundation Fabric：從預先設定的基礎和登陸區開始。Cloud Foundation Fabric 是獨立實作項目，使用自己的 Terraform 模組。這個方法是以 Google Cloud Terraform 供應商中的資源為基礎。
規劃及奠定基礎
在規劃和建構階段，您需要佈建及設定基礎架構，以執行下列操作：
- 支援 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 外掛程式，例如 GKE 備份。
如要進一步瞭解如何佈建 GKE 叢集，請參閱：
機群管理
佈建 GKE 叢集時，您可能會發現需要大量叢集，才能支援環境中的所有用途。舉例來說，您可能需要將正式環境與非正式環境區隔開來，或是區隔各個團隊或地理位置的服務。詳情請參閱「多叢集用途」。
隨著叢集數量增加，GKE 環境可能會變得更難操作，因為管理大量叢集會帶來重大的擴充性和營運挑戰。GKE 提供工具和功能，協助您管理機群 (Kubernetes 叢集的邏輯群組)。詳情請參閱「機群管理」。
多叢集網路
如要提高 GKE 環境的可靠性，並將工作負載分散到多個 GKE 叢集，可以使用：
- 多叢集服務探索：跨叢集服務探索和叫用機制。可跨 GKE 叢集探索及存取服務。詳情請參閱「多叢集服務探索」。
- 多叢集閘道：跨叢集輸入流量負載平衡機制。詳情請參閱「部署多叢集閘道」。
- 代管 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 解決方案時。
這項重構作業可能包括：
- Kubernetes 物件描述元，例如以 YAML 格式表示的 Deployment 和 Service。
- 容器映像檔描述元，例如 Dockerfile 和 Containerfile。
- 工作負載原始碼。
為簡化重構作業，建議您著重於套用最少量的變更，讓工作負載適用於 GKE，並修正重大錯誤。您可以規劃其他改善措施和變更，做為未來專案的一部分。
運用 Gemini 加速工作負載審查和重構
如要加快程式碼審查和重構作業，您可以使用 Gemini 擴充遷移團隊。舉例來說，您可以使用 Gemini CLI 執行下列操作：
- 評估要遷移的工作負載原始碼，以及其 Kubernetes 物件，例如 Deployment、Service 和 Gateway。
- 規劃程式碼重構。
- 重構程式碼並驗證變更。
詳情請參閱「透過 Gemini 遷移至 Google Cloud」。
重構部署和作業程序
重構工作負載後，您需要重構部署和作業程序，以便執行下列操作：
- 在 Google Cloud 環境中佈建及設定資源，而非在來源環境中佈建資源。
- 建構及設定工作負載，並部署至 Google Cloud，而非來源環境。
您在評估階段已收集這些程序的相關資訊。
您需要考慮對這些程序進行的重構類型，取決於您設計和實作這些程序的方式。重構也取決於您希望每個程序的最終狀態為何。例如，請考慮以下幾點：
- 您可能已在來源環境中實作這些程序，並打算在 Google Cloud中設計及實作類似的程序。舉例來說，您可以重構這些程序，改用 Cloud Build、Cloud Deploy 和 Infrastructure Manager。
- 您可能已在來源環境以外的其他第三方環境中實作這些程序。在這種情況下，您需要重構這些程序，改為指定 Google Cloud 環境，而非來源環境。
- 結合上述方法。
重構部署和作業程序可能相當複雜，需要投入大量心力。如果您嘗試在工作負載遷移期間執行這些工作，工作負載遷移作業可能會變得更複雜，並可能帶來風險。評估部署和作業程序後，您應該已瞭解其設計和複雜度。如果您預估需要投入大量心力重構部署和作業程序，建議您考慮將這些程序重構為獨立的專屬專案。
如要進一步瞭解如何在 Google Cloud上設計及實作部署程序，請參閱：
本文件著重於產生要部署的構件，並將其部署至目標執行階段環境的部署程序。重構策略高度取決於這些程序的複雜程度。以下清單概述可能的一般重構策略：
- 在 Google Cloud佈建構件存放區。例如，您可以使用 Artifact Registry 儲存構件及建構依附元件。
- 重構建構程序，將構件同時儲存在來源環境和 Artifact Registry。
- 重構部署程序，將工作負載部署至目標Google Cloud 環境。舉例來說，您可以先使用 Artifact Registry 中儲存的構件，在 Google Cloud中部署一小部分工作負載。接著，您會逐步增加部署在 Google Cloud中的工作負載 數量，直到所有要遷移的工作負載都在 Google Cloud上執行。
- 重構建構程序，只將構件儲存在 Artifact Registry。
- 如有必要，請將要部署的早期版本構件，從來源環境中的存放區遷移至 Artifact Registry。舉例來說，如要將容器映像檔遷移至 Artifact Registry，可以使用 gcrane 或 Rackware SWIFT 等工具。
- 不再需要來源環境中的存放區時，請將其停用。
為了在遷移期間因未預期的問題而最終復原，您可以在遷移至 Google Cloud 時，將容器映像檔儲存在 Google Cloud 目前的構件存放區中。最後，在停用來源環境時，您可以重構容器映像檔建構程序，只將構件儲存在Google Cloud 中。
雖然這可能不是遷移成功的關鍵，但您可能需要將舊版構件從來源環境遷移至 Google Cloud上的構件存放區。舉例來說，如要支援將工作負載復原至任意時間點，您可能需要將舊版構件遷移至 Artifact Registry。詳情請參閱「從第三方註冊資料庫遷移映像檔」。
如果您使用 Artifact Registry 儲存構件，建議您設定控管機制，協助保護構件存放區，例如存取控管、資料竊取防護、安全漏洞掃描和二進位授權。詳情請參閱「控管存取權及保護構件」。
遷移資料
將工作負載遷移至 GKE 時，請評估其有狀態性。相較於遷移有狀態工作負載，遷移無狀態工作負載較為簡單。遷移無狀態工作負載時，您會在目標環境中重新部署，不會影響資料。不過，遷移有狀態工作負載時，您也需要遷移其資料，例如 PersistentVolume 和有狀態 ConfigMap。
GKE 支援多種資料儲存服務，例如區塊儲存空間、原始區塊儲存空間、檔案儲存空間和物件儲存空間。詳情請參閱「GKE 叢集儲存空間總覽」。
如要將資料遷移至 GKE 環境，請按照下列步驟操作：
- 佈建及設定所有必要的儲存空間基礎架構。
- 在 GKE 叢集中設定 StorageClass 佈建工具。並非所有 StorageClass 佈建工具都與所有環境相容。部署 StorageClass 佈建工具之前，建議您評估其與 GKE 的相容性及其依附元件。
- 設定 StorageClass。
- 設定 PersistentVolume 和 PersistentVolumeClaim，以儲存要遷移的資料。
- 將資料從來源環境遷移至這些 PersistentVolume。這項資料遷移作業的具體細節取決於來源環境的特性。
如要將資料從來源環境遷移至 Google Cloud環境，建議您設計資料遷移計畫。資料遷移計畫的設計取決於多項因素，例如要完成的資料遷移類型、停機時間規定，以及工作負載提供的資料管理和管理工具：
如果工作負載提供移動或複製資料的工具或功能，您可以使用這些工具執行遷移計畫。舉例來說，如要將資料從有狀態工作負載執行個體遷移至在 GKE 上執行的目標工作負載執行個體，可以使用下列選項：
- 任何支援工作負載的資料管理和管理工具。
- 工作負載支援的任何資料複製功能。
如果工作負載未提供任何應用程式層級的工具或功能來遷移資料，您可以使用第三方工具，例如 Rackware SWIFT 或 Velero。
如要進一步瞭解如何設計資料遷移計畫，請參閱「遷移至 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 資源，請參閱「使用既有的永久磁碟做為 PersistentVolume」。
將 Amazon EBS 磁碟區的資料複製到臨時媒體，並遷移至 GKE PersistentVolume
您可以改用物件儲存庫等臨時媒體，而不是直接從 Amazon EBS 磁碟區遷移至 GKE PersistentVolume 資源：
- 將 Amazon EBS 磁碟區中的資料上傳至臨時媒體，例如 Amazon S3 bucket 或 Cloud Storage bucket。
- 將資料從臨時媒體下載到 GKE
PersistentVolume資源。
在某些情況下，根據網路和安全性設定，使用多種媒體可以簡化資料移轉作業。例如，您可以先將資料上傳至 S3 bucket，然後從 S3 bucket 複製到 Cloud Storage bucket，最後將資料下載至永久磁碟區。無論選擇哪種方法，為確保轉換過程順利，並留意重要考量事項，建議您參閱「從 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 自動佈建的部分 Google Cloud資源可使用 Kubernetes 標籤和註解設定，不必手動佈建。舉例來說，您可以在 LoadBalancer Service 中新增註解，佈建內部負載平衡器，而非外部負載平衡器。
驗證工作負載
在 GKE 環境中部署工作負載後，建議您先進行全面驗證和測試，再向使用者公開這些工作負載。這項測試可協助您驗證工作負載是否正常運作。例如：
- 執行整合測試、負載測試、法規遵循測試、可靠性測試和其他驗證程序，確保工作負載在預期參數內運作，並符合規格。
- 在 Google Cloud Observability 中檢查記錄、指標和 Error Reporting，找出潛在問題，並觀察趨勢，在問題發生前預先防範。
如要進一步瞭解工作負載驗證，請參閱「測試可靠性」。
公開工作負載
完成 GKE 環境中執行工作負載的驗證測試後，請公開工作負載，讓工作負載可供存取。
如要公開在 GKE 環境中執行的工作負載，可以使用 Kubernetes Service 和服務網格。
如要進一步瞭解如何公開在 GKE 中執行的工作負載，請參閱：
將流量轉移至 Google Cloud 環境
確認工作負載在 GKE 環境中執行，並向用戶端公開後，請將流量從來源環境轉移至 GKE 環境。為避免大規模遷移和所有相關風險，建議您逐步將流量從來源環境轉移至 GKE。
開始逐步將流量轉移至 GKE 環境後，建議您監控工作負載在負載增加時的行為。
視您設計 GKE 環境的方式而定，您可以選擇下列選項，導入將流量從來源環境逐步轉移至目標環境的機制：
- DNS 解析政策，可將一定比例的要求解析為屬於 GKE 環境的 IP 位址。這項技術相對容易實作，但可能缺乏必要的彈性，無法滿足所有流量轉移需求。此外，這項機制也假設用戶端會遵循 DNS 解析回應，而非積極快取過去的回應來提高效能。
手動設定的 Cloud Load Balancing 負載平衡器，您可以在其中附加下列項目：
- 獨立網路端點群組 (NEG)，指向部署在 GKE 上的工作負載執行個體。
- 混合式連線能力 NEG，指向部署在來源環境中的工作負載執行個體。
接著，您會設定負載平衡器，逐步將流量從來源環境轉移至 GKE 環境。使用這項技術時，您會將負載平衡委派給 Cloud Load Balancing，但必須自行設定負載平衡器。如果您想改用 GKE 代管的負載平衡器，例如佈建 Kubernetes Gateway、Ingress 或 LoadBalancer 類型的 Service，這項技術也會帶來挑戰。
部署在 GKE 環境中的 Proxy，可將流量從 GKE 環境轉送至來源環境。接著，您需要設定 Cloud Service Mesh，將流量從 Proxy 逐步轉移至部署在 GKE 上的工作負載執行個體。
最後，您會執行轉換，將所有流量從來源環境轉移至 GKE 環境。
如要進一步瞭解負載平衡，請參閱「前端負載平衡」。
停用來源環境
GKE 環境中的工作負載正確處理要求後，您就可以停用來源環境。
在開始停用來源環境中的資源之前，建議您執行下列操作：
- 備份所有資料，以便還原來源環境中的資源。
- 在停用環境前通知使用者。
如要停用來源環境，請按照下列步驟操作：
- 停用在來源環境叢集中執行的工作負載。
- 刪除來源環境中的叢集。
- 刪除與這些叢集相關聯的資源，例如安全性群組、負載平衡器和虛擬網路。
為避免留下孤立資源，請務必按照正確順序停用來源環境中的資源。舉例來說，某些供應商會要求您先停用會建立負載平衡器的 Kubernetes 服務，才能停用包含這些負載平衡器的虛擬網路。
最佳化 Google Cloud 環境
最佳化是遷移作業的最後階段。在這個階段，您會反覆執行最佳化工作，直到目標環境符合最佳化需求。每次疊代的步驟如下：
- 評估目前的環境、團隊和最佳化循環。
- 確立最佳化需求和目標。
- 最佳化環境和團隊。
- 調整最佳化循環。
重複這個流程，直到達成最佳化目標。
如要進一步瞭解如何最佳化 Google Cloud 環境，請參閱「遷移至 Google Cloud：最佳化環境」和「Google Cloud Well-Architected Framework：效能最佳化」。
以下各節整合了「遷移至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。
- 瞭解如何取得遷移作業相關協助。
- 參加 Google Skills 訓練課程，瞭解如何遷移至 Google Cloud。
- 如要查看更多參考架構、圖表和最佳做法，請瀏覽 Cloud Architecture Center。
貢獻者
作者：
- Marco Ferrari | 雲端解決方案架構師
- Xiang Shen | 解決方案架構師