本文件可協助您規劃、設計及實施從自管 Kubernetes 環境遷移至 Google Kubernetes Engine (GKE) 的作業。如果操作不當，從一個環境將應用程式移到另一個環境可能會是一項艱鉅的任務，因此您必須謹慎規劃和執行遷移作業。
不管您打算從自管 Kubernetes 環境遷移至 GKE，或是想瞭解遷移的預期情況，本文件都能提供實用的參考資料。您的環境可能會在內部部署環境、私人代管環境或其他雲端服務供應商中執行。不管您是想從內部部署環境、私人託管環境或其他雲端服務供應商遷移至 GCP，或是正在評估遷移的可能性，而想要進一步掌握遷移的預期情況，本文件都能提供實用的參考資料。
GKE 是 Google 代管的 Kubernetes 服務，可讓您透過 Google 基礎架構大規模部署及操作容器化應用程式，並提供有助於管理 Kubernetes 環境的功能，例如：
- 兩個版本：GKE Standard 和 GKE Enterprise。使用 GKE Standard，您就能存取標準層級的核心功能。您可以透過 GKE Enterprise 存取 GKE 的所有功能。詳情請參閱「GKE 版本」。
- 兩種作業模式：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 中不支援的功能。這些功能可能已淘汰，或是提供這些功能的 Kubernetes 版本尚未在 GKE 中提供。
- Kubernetes 升級週期。如要維持可靠的環境，請瞭解您如何處理 Kubernetes 升級作業，以及升級週期與 GKE 升級的關聯性。
- 節點集區。如果您使用任何形式的節點分組，建議您考量這些分組如何對應至 GKE 中的節點集區概念，因為您的分組條件可能不適合 GKE。
- 節點初始化。評估如何初始化每個節點，然後將其標示為可執行工作負載，以便將這些初始化程序移植至 GKE。
- 網路設定。評估叢集的網路設定、IP 位址分配方式、網路外掛程式的設定方式、DNS 伺服器和 DNS 服務供應商的設定方式、是否為這些叢集設定任何形式的 NAT 或 SNAT，以及是否屬於多叢集環境。
- 法規遵循：評估叢集必須滿足的任何法規遵循和監管規定，以及您是否符合這些規定。
- 配額與限制。評估您如何為叢集設定配額和限制。例如，每個節點可以執行多少 Pod？叢集可以有多少節點？
- 標籤和代碼。評估您套用至叢集、節點資源池和節點的所有中繼資料，以及您如何使用這些中繼資料。舉例來說，您可能會產生報表，其中包含詳細的標籤成本歸因。
您在清單中評估的下列項目，著重於基礎架構和 Kubernetes 叢集的安全性：
- 命名空間。如果您在叢集中使用 Kubernetes 命名空間，透過邏輯方式區隔資源，請評估各個命名空間中的資源，並瞭解為何要建立這項區隔。舉例來說，您可能會在多租戶策略中使用命名空間。您可能會在為 Kubernetes 系統元件保留的命名空間中部署工作負載，因此在 GKE 中可能無法享有太多控制權。
- 角色型存取權控管 (RBAC)。如果您在叢集中使用 RBAC 授權，請列出您在叢集中設定的所有 ClusterRoles 和 ClusterRoleBindings 說明。
- 網路政策。列出您在叢集中設定的所有網路政策，並瞭解網路政策在 GKE 中的運作方式。
- Pod 安全性情境。擷取您在叢集中設定的Pod 安全性內容相關資訊，並瞭解 Pod 在 GKE 中的運作方式。
- 服務帳戶。如果叢集中的任何程序都與 Kubernetes API 伺服器互動，請擷取這些程序使用的服務帳戶相關資訊。
建立 Kubernetes 叢集的清單時，您可能會發現部分叢集需要在遷移期間停用。請確認遷移計畫包含這些資源的淘汰作業。
建立 Kubernetes 工作負載清單
完成 Kubernetes 叢集清單並評估環境安全性後，請建立這些叢集中部署的工作負載清單。評估工作負載時，請收集下列各方面的資訊：
- Pod 和控制器。如要為新環境中的叢集設定大小，請評估您已部署的每個工作負載的執行個體數量，以及是否使用資源配額和運算資源用量限制。收集有關在各叢集控制層節點上執行的工作負載，以及各工作負載使用的控制器的資訊。例如，您使用了多少個部署？您使用多少個 DaemonSets？
- 工作和 CronJobs。叢集和工作負載可能需要在初始化或作業程序中執行工作或 Cron 工作。評估您已部署的工作和 CronJob 例項數量，以及每個例項的職責和完成標準。
- Kubernetes 自動配置器。如要在新環境中遷移自動調度資源政策，請瞭解 水平 Pod 自動配置器和垂直 Pod 自動配置器在 GKE 上的運作方式。
- 無狀態和有狀態工作負載。無狀態工作負載不會將資料或狀態儲存在叢集或永久儲存空間中。有狀態的應用程式會儲存資料，以便日後使用。針對每項工作負載，評估哪些元件為無狀態，哪些元件為有狀態，因為遷移有狀態工作負載通常比遷移無狀態工作負載更困難。
- Kubernetes 功能。您可以透過叢集清單瞭解每個叢集執行的 Kubernetes 版本。請查看各個 Kubernetes 版本的版本資訊，瞭解該版本提供哪些功能，以及淘汰哪些功能。接著，根據您需要的 Kubernetes 功能評估工作負載。這項工作的目標是瞭解您是否使用已淘汰的功能，或是尚未在 GKE 中提供的功能。如果您發現任何無法使用的功能，請在GKE 提供時，從已淘汰的功能遷移至新功能，並採用新功能。
- 儲存空間。針對有狀態的工作負載，評估是否使用 PersistenceVolumeClaims。列出所有儲存空間需求 (例如大小和存取模式)，以及這些 PersistentVolumeClaim 如何對應至 PersistenceVolume。為因應未來的成長，請評估是否需要擴充任何 PersistenceVolumeClaim。
- 設定和 Secret 注入。為避免每次環境設定變更時，都需要重新建構可部署的構件，請使用 ConfigMaps 和 Secrets，將設定和機密資料注入 Pod。針對每個工作負載，評估工作負載使用的 ConfigMap 和 Secret，以及您如何填入這些物件。
- 依附元件。您的工作負載可能無法獨立運作。這些作業可能會依附叢集內部或外部系統的依附元件。針對每個工作負載，擷取依附元件，並瞭解工作負載是否有任何依附元件無法使用時的容許值。舉例來說，常見的依附元件包括分散式檔案系統、資料庫、機密資料發布平台、身分和存取權管理系統、服務探索機制，以及任何其他外部系統。
- Kubernetes 服務。如要將工作負載公開給內部和外部用戶端，請使用服務。您必須知道每項服務的類型。針對外部公開的服務，評估該服務與其他基礎架構的互動方式。舉例來說，您的基礎架構如何支援 LoadBalancer 服務、Gateway 物件和Ingress 物件？您在叢集中部署了哪些Ingress 控制器？
- 服務網格。如果您在環境中使用服務網格，請評估其設定方式。您也需要瞭解網格涵蓋的叢集數量、網格包含哪些服務，以及如何修改網格的拓撲圖。
- Taint 和容許條件，以及相依性和反相依性。針對每個 Pod 和節點，評估您是否已設定任何節點 taint、Pod 容許條件或相依性，以便自訂 Kubernetes 叢集中的 Pod 排程。這些屬性也可能提供您有關可能不均勻的節點或 Pod 設定的洞察資料，並可能表示需要特別專注及小心評估 Pod 或節點，或兩者皆需評估。舉例來說，如果您將特定 Pod 組別設為只在 Kubernetes 叢集中的特定節點上排程，這可能表示 Pod 需要專屬資源，而這些資源只在這些節點上可用。
- 驗證：評估工作負載如何驗證叢集中的資源，以及外部資源。
評估支援服務和外部依附元件
評估叢集及其工作負載後，請評估基礎架構中的其他支援服務和層面，例如：
- StorageClasses 和 PersistentVolumes。如要評估基礎架構如何支援 PersistentVolumeClaim，請列出動態佈建的 StorageClasses，以及靜態佈建的 PersistentVolumes。針對每個 PersistentVolume，請考量下列事項：容量、磁碟區模式、存取模式、類別、回收政策、掛載選項和節點關聯。
- VolumeSnapshots 和 VolumeSnapshotContents。針對每個 PersistentVolume，評估您是否已設定任何 VolumeSnapshot，以及是否需要遷移任何現有的 VolumeSnapshotContents。
- Container Storage 介面 (CSI) 驅動程式。如果在叢集中部署，請評估這些驅動程式是否與 GKE 相容，以及是否需要調整磁碟區設定，以便與與 GKE 相容的 CSI 驅動程式搭配運作。
- 資料儲存。如果您需要外部系統來佈建 PersistentVolumes，請提供方法，讓 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 搭配設定管理工具，在來源環境中佈建及設定資源。
規劃及建立基礎
在規劃和建構階段，您會佈建及設定基礎架構，以便執行下列工作：
- 在 Google Cloud 環境中支援工作負載。
- 連結來源環境和 Google Cloud 環境，完成遷移作業。
規劃和建構階段包含下列工作：
- 建立資源階層。
- 設定 Google Cloud的 Identity and Access Management (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 環境
在將任何工作負載移至新環境之前，您必須先佈建 GKE 叢集。 Google Cloud
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 叢集中進行探索及存取。詳情請參閱「多叢集服務探索」。
- 多叢集閘道，跨叢集 Ingress 流量負載平衡機制。詳情請參閱「部署多叢集 Gateway」。
- 在代管 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 叢集。舉例來說，您可以限制可從中提取容器映像檔的存放區，或是要求每個命名空間至少要有一個標籤，以便確保資源用量追蹤的準確性。
詳情請參閱「政策控制器」。
重構工作負載
設計容器化工作負載時，最佳做法是避免對容器自動調度管理平台的依附性。但在實際操作中，這不一定可行，因為這取決於工作負載的需求和設計。舉例來說，您的工作負載可能會依賴特定環境功能，而這類功能僅在來源環境中提供，例如外掛程式、擴充功能和整合。
雖然您可以將大部分工作負載原封不動地遷移至 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 部署工作負載，建議您分析 Kubernetes 描述項，因為 GKE 自動為您配置的部分 Google Cloud資源可使用 Kubernetes 標籤和註解進行設定，而不需要手動配置這些資源。舉例來說，您可以在 LoadBalancer 服務中新增註解，藉此佈建內部負載平衡器，而非外部負載平衡器。
驗證工作負載
在 GKE 環境中部署工作負載後，但尚未向使用者提供這些工作負載前，建議您進行全面的驗證和測試。這項測試可協助您驗證工作負載是否正常運作。舉例來說，您可以：
- 執行整合測試、負載測試、法規遵循測試、可靠度測試和其他驗證程序，確保工作負載可在預期參數範圍內運作，並符合規格。
- 檢查 Google Cloud Observability 中的記錄、指標和錯誤報告，找出任何潛在問題，並掌握趨勢，在問題發生前預先採取行動。
如要進一步瞭解工作負載驗證，請參閱「測試可靠性」。
公開工作負載
完成在 GKE 環境中執行的工作負載驗證測試後，請公開工作負載，讓其他人可以存取。
如要公開在 GKE 環境中執行的工作負載，您可以使用 Kubernetes 服務和服務網格。
如要進一步瞭解如何在 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 支援多種資源調度機制，例如：
- 依據指標自動調整工作負載。
- 設定水平 Pod 自動調度資源，藉此變更 Kubernetes 工作負載的 Pod 數量，自動調整工作負載。
- 設定垂直 Pod 自動調度功能，調整資源要求和限制，自動調整工作負載。
詳情請參閱「關於 GKE 可擴充性」。
後續步驟
- 瞭解何時應尋求遷移作業相關協助。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 雲端架構中心。
貢獻者
作者：Marco Ferrari | 雲端解決方案架構師