規劃最佳做法

本主題會根據使用 Migrate to Containers 遷移實際應用程式的經驗，提供將應用程式遷移至 Google Kubernetes Engine (GKE) 或 GKE Enterprise 的建議。

Migration Center 用戶資產評估器 CLI 或 mcdc CLI 是用來判斷 VM 工作負載是否適合遷移至容器的工具。

建議將特定類型的 Linux 和 Windows 工作負載遷移至容器，詳情請參閱下文。

適合

Linux

適合使用 Migrate to Containers 遷移的 Linux 應用程式，包括下列應用程式架構：

  • 網頁/應用程式伺服器
  • 商業邏輯中介軟體 (例如 Tomcat)
  • 多個 VM、多層堆疊 (例如 LAMP)
  • 小型/中型資料庫 (例如 MySQL 和 PostgreSQL)

此外，最適合使用 Migrate to Containers 遷移功能的應用程式，具有下列運作特性：

  • 低負載週期和突發的工作負載
  • 開發、測試和訓練研究室環境
  • 隨時運作、負載量低的服務

一般來說，大多數 Linux 工作負載都與遷移作業相容，但下方「不太適合」一節明確列出的工作負載除外。

Windows

適合使用 Migrate to Containers 遷移的 Windows 應用程式，包括符合下列所有特徵的工作負載：

  • IIS 7 以上版本、ASP.NET 搭配 .NET Framework 3.5 以上版本
  • 網頁和邏輯層
  • WS2008 R2 以上版本

作業系統支援

Migrate to Containers 與下列VM 作業系統相容。

不太適合

Linux

就 Linux 而言，以下應用程式和伺服器不適合使用 Migrate to Containers 進行遷移：

  • 高效能和大型記憶體內資料庫
  • 使用特殊核心驅動程式的 VM (例如核心模式 NFS)
  • 依賴特定硬體
  • 軟體授權與特定硬體 ID 註冊綁定

Windows

就 Windows 而言，未安裝 IIS 7 以上版本的工作負載不適合遷移。其他不適合遷移的應用程式類型包括：

  • 依附於 GPU 或 TPU 的應用程式
  • 低層級網路應用程式
  • 桌面、遠端桌面和虛擬桌面基礎架構應用程式
  • 使用 BYOL 的應用程式

DNS 和網路存取規則

遷移至 GKE 前，請務必瞭解遷移工作負載使用的網路資源和服務，並確保這些資源和服務可透過虛擬私有雲存取及尋址。

規劃 Kubernetes 服務名稱

如果工作負載需要透過 DNS 存取服務，您就需要規劃 Kubernetes 命名空間配置方案、網路政策和服務名稱。

遷移程序產生的部署規格包含建議的無頭 Service 物件，類型為「ClusterIP」。「ClusterIP」表示沒有負載平衡，且只有叢集內部可以存取單一叢集內部 IP。Kubernetes 端點控制器會修改 DNS 設定，以便傳回指向 Pod 的記錄 (位址)，這些 Pod 在 deployment_spec.yaml 中標示為 "app": "app-name"。

建立及套用連結至 Pod 和容器的服務

遷移工作負載後，主機名稱就不再適用。如要允許連線至工作負載，請建立並套用服務。

找出並設定已遷移的名稱和 IP

GKE 會管理 /etc/hosts 檔案。在 Migrate to Containers 中，從來源 VM 調整主機檔案至 GKE 的作業尚未自動化。您必須找出遷移後的 VM 主機檔案中的名稱和 IP，並將其設為 hostAliases。

將相依服務放在同一個命名空間

彼此相依的服務應位於相同的 Kubernetes 命名空間中，並使用短 DNS 名稱 (例如 app 和 db) 進行通訊。這項設定也能協助複製多個應用程式環境，例如實際工作、模擬和測試環境。

使用 GKE 網路控管存取層面

GKE 提供精密的網路控制選項。Pod 可透過不同的網路存取，例如公用網際網路、虛擬私有雲網路或內部叢集網路。這可讓您進一步控制工作負載的存取途徑，並限制存取途徑，而無須管理 VLAN、篩選器或路由規則，避免增加複雜度。

舉例來說，典型的三層式應用程式包含前端、應用程式和資料庫層。遷移至 Google Cloud時，前端服務會在 VPC 網路上設定 LoadBalancer。其他層級無法從 GKE 叢集外部直接存取。網路存取政策可確保應用程式服務只能由內部叢集網路內的前端 Pod 存取。另一項政策則可確保只有應用程式 pod 可以存取資料庫 pod。

NFS

將 NFS 掛接點定義為永久磁碟區

建立遷移計畫時，系統會自動偵測來源 VM 上的 NFS 用戶端掛接點，並將其新增至產生的計畫。

雖然掛載點會新增至企劃書，但預設為停用。也就是說，產生遷移構件時，deployment_spec.yaml 檔案中不會包含 PersistentVolume 和 PersistentVolumeClaim 定義。如果您希望「遷移至容器」產生 PersistentVolume 和 PersistentVolumeClaim 定義，請先編輯遷移計畫，啟用 NFS 用戶端掛載。

詳情請參閱「自訂 NFS 掛載」。

核心模式 NFS 伺服器

在核心模式下執行 NFS 伺服器的 VM 無法透過 Migrate to Containers 遷移至 GKE。這些 VM 必須遷移至 Compute Engine 中的 VM。您也可以使用 Filestore 取得原生雲端 NFS 解決方案。

從來源 NFS 共用區遷移資料

如果來源 VM 使用 NFS 共用掛載點，系統就無法自動遷移這項資料。請使用 NFS 永久磁碟區，在已遷移的工作負載容器上掛載共用區，或者如果來源 NFS 共用區為遠端，請將資料複製到另一個可提供較低延遲叢集存取權的檔案共用區。

如需資料複製選項，請參閱以下內容：

  1. Storage 移轉服務或 Transfer Appliance。

  2. 使用 gcloud storage rsync 複製資料 (從來源檔案共用區複製到值區，再從值區複製到雲端檔案共用區)。

  3. 第三方解決方案，例如 NetApp SnapMirror 到 NetApp Cloud Volumes。

  4. OSS 公用程式，例如 Rsync。

確保資料庫可供存取

如果應用程式需要使用資料庫 (在 VM 上本機執行或在外部電腦上執行)，您必須確保資料庫仍可從新遷移的 Pod 存取。您必須驗證網路防火牆政策是否允許叢集存取資料庫。

如要將資料庫遷移至 Google Cloud，建議您使用資料庫移轉服務

或者，您也可以在叢集內執行資料庫。詳情請參閱「規劃 GKE 中的資料庫部署作業」。

確認已插入中繼資料

如果應用程式需要注入中繼資料 (例如環境變數)，您必須確保這些中繼資料可在 GKE 上使用。如果無法使用相同的中繼資料插入方法，GKE 提供 ConfigMaps 和 Secrets。

設定必要服務，以便在執行層級 3 啟動

Migrate to Containers 工作負載只能達到執行層級 3。透過 Migrate to Containers 遷移至 GKE 的 VM 會以 Linux runlevel 3 在容器中啟動。根據預設，某些服務 (例如 X11 或 XDM，用於使用 VNC 進行遠端 GUI 存取) 只會在執行層級 5 啟動。所有必要的服務都應設為在執行層級 3 啟動。

停用不必要的服務

Migrate to Containers 會自動停用硬體或環境專屬服務，以及在 VM 上執行的預先定義額外服務組合。將工作負載遷移至容器後，就不需要這些服務。

舉例來說，Migrate to Containers 會自動停用 iptables、ip6tables 和 firewalld。如需 Migrate to Containers 停用的服務完整清單，請下載 blocklist.yaml 檔案。

自訂停用的服務

根據預設，「遷移至容器」會停用上述不必要的服務。您也可以自訂遷移計畫，定義封鎖清單，藉此定義要封鎖的服務自訂清單，在遷移的容器中停用這些服務。您可以使用封鎖清單，在已遷移的容器中指定一或多項要停用的服務。

維護及更新已遷移的 VM

您可以使用遷移期間產生的構件，套用應用程式和使用者模式 OS 軟體更新、安全性修補程式、編輯嵌入式設定、新增或取代檔案，以及更新 Migrate to Containers 執行階段軟體。

詳情請參閱「遷移後映像檔更新」。

後續步驟