自訂 Linux VM 的遷移計畫

執行遷移計畫前，請先檢查並視需要自訂計畫。遷移計畫的詳細資料可用於從來源 VM 中擷取工作負載的容器構件，並產生 Kubernetes 部署檔案，以便將容器映像檔部署至其他叢集 (例如實際運作叢集)。

本頁說明遷移計畫的內容，以及執行遷移作業並產生部署構件前，您可能會考慮的客製化類型。

事前準備

本主題假設您已建立遷移計畫，並取得產生的遷移計畫檔案。

編輯遷移計畫

複製及分析檔案系統後，您可以在指定輸出路徑 ANALYSIS_OUTPUT_PATH/config.yaml 中建立的新目錄中找到遷移計畫。

視需要編輯遷移計畫並儲存變更。

請查看遷移計畫詳細資料和指引性註解，視需要新增資訊。具體來說，請考慮針對下列部分進行編輯：

指定要從遷移作業中排除的內容

根據預設，「Migrate to Containers」會排除在 GKE 環境中不相關的一般 VM 內容。您可以自訂該篩選器。

filters 欄位值會列出應從遷移作業中排除的路徑，這些路徑不會是容器映像檔的一部分。這個欄位的值會列出 rsync 篩選規則，指定要轉移和略過哪些檔案。在每個路徑和檔案前方加上減號符號，表示清單中的項目應從遷移作業中排除。系統會依照 YAML 中的行順序處理清單，並據此評估排除/納入項目。

進一步瞭解 rsync 篩選器規則。

檔案過大，無法納入 Docker 映像檔，會列於 YAML 檔案中。系統會標記大小超過 1 GB 的檔案，供您考量是否要上傳。如果 Docker 映像檔太大 (超過 15 GB)，在遷移期間可能會失敗。

您可以編輯 YAML 清單，新增或移除路徑。請參閱下方的 YAML 範例，其中包含排除項目範例，以及大型和稀疏檔案的通知。請按照內嵌指示執行下列任一動作：

• 取消註解並將其放在全域篩選器部分，即可排除偵測到的資料夾。
• 取消註解並將所偵測到的資料夾置於資料資料夾專區下方，即可將這些資料夾移至永久磁碟區。

您也可以以相同的方式排除或移動偵測到的稀疏檔案。

  global:
    # Files and directories to exclude from the migration, in rsync format.
    filters:
      - "- *.swp"
      - "- /etc/fstab"
      - "- /boot/"
      - "- /tmp/*"
      - "- /var/log/*.log*"
      - "- /var/log/*/*.log*"
      - "- /var/cache/*"

    ## The data folders below are too large to be included in the docker image.
    ## Consider uncommenting and placing them under either the global filters
    ## or the data folder section.
      # - '- /a' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/c' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

    ## Sparse files will fail the run of a docker image. Consider excluding the below
    ## detected files and any other sparse files by uncommenting and placing them in 
    ## the global filters section, or export them to a persistent volume by specifying
    ## them in the data folder section.
      # - '- /a/b' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/d' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

設定容器映像檔的名稱

image 區段中的 name 欄位值會定義從用於容器的已遷移 VM 建立的映像檔名稱。如要使用其他名稱，您可以變更這個值。

image:
     # Review and set the name for runnable container image.
     name: linux-system

自訂服務清單

根據預設，當您將 VM 遷移至容器時，「遷移至容器」會停用 VM 上不需要的服務。這些服務有時可能會導致已遷移容器發生問題，或是在容器情境中不需要這些服務。

除了由「遷移至容器」自動停用的服務外，您也可以選擇停用其他服務：

• Migrate to Containers 會自動偵測可選停用的服務，並將這些服務列在遷移計畫中。在遷移的工作負載中，可能不需要 ssh 或網頁伺服器等服務，但這取決於您的決定。如有需要，請編輯遷移計畫來停用這些服務。

• 「遷移至容器」不會列出在來源 VM 上執行的所有服務。例如，它會省略作業系統相關服務。您可以選擇編輯遷移計畫，自行新增要停用的服務清單，以便在遷移的容器中停用這些服務。

systemServices 欄位會指定「Migrate to Containers」探索到的服務清單。例如：

    systemServices:
    - enabled: true|false
      name: service-name
      probed: true|false
    - enabled: true|false
      name: service-name
      probed: true|false
      ...

如要停用服務，請將 enabled 設為 false。

「遷移至容器」不會列出來源 VM 上執行的所有服務，例如作業系統相關服務。您也可以在清單中新增其他服務。例如，如要停用 service2 和 cron 服務，請執行以下指令：

    systemServices:
    - enabled: true
      name: service1
      probed: false
    - enabled: false
      name: service2
      probed: false
    - enabled: false
      name: cron
      probed: false

當您執行遷移作業來產生遷移構件時，「遷移至容器」會建立 blocklist.yaml 檔案。這個檔案會根據遷移計畫中的設定，列出要停用的容器服務。例如：

service_list:
- name: disabled-services
  services:
  # Because you used systemServices above to disabled service2 and cron:
  - service2
  - cron

如要日後修改停用的服務清單，請按照下列步驟操作：

• 編輯遷移計畫中的服務清單。
• 執行遷移作業，重新產生遷移構件，包括更新的 blocklist.yaml。

或者，在執行遷移作業產生遷移構件後，您可以直接編輯 blocklist.yaml 檔案，然後使用 Skaffold 建構並部署容器映像檔。

自訂服務端點

遷移計畫包含 endpoints 陣列，用於定義用來建立遷移工作負載所提供 Kubernetes 服務的通訊埠和通訊協定。您可以新增、編輯或刪除端點定義，自訂遷移計畫。

如要擷取端點通訊埠，請檢查監聽通訊埠的程式：

sudo netstat --programs --listening --tcp --udp [--sctp]

針對每個服務端點，在遷移計畫中加入下列定義：

    endpoints:
    - port: PORT_NUMBER
      protocol: PORT_PROTOCOL
      name: PORT_NAME

其中：

• PORT_NUMBER 會指定要將服務要求導向至哪個容器連接埠。
• PORT_PROTOCOL 會指定通訊埠通訊協定，例如 HTTP、HTTPS 或 TCP。如需完整的通訊協定清單，請參閱「支援的通訊協定」。
• PORT_NAME 會指定用於存取服務端點的名稱。「遷移至容器」會為每個產生的端點定義產生一個不重複的 PORT_NAME。

舉例來說，Migrate to Containers 會偵測下列端點：

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 6379
      protocol: TCP
      name: backend-server-redis

如要設定 name 屬性的值，Migrate to Containers 會將來源 VM 名稱 (在本例中為 backend-server) 與服務的程式名稱結合。產生的名稱與 Kubernetes 命名慣例相容，且在遷移計畫中不重複。舉例來說，上述遷移計畫會建立服務，指定通訊埠 80 上的 Nginx，並透過 HTTP 進行。

對於任何重複的名稱，Migrate to Containers 會加上計數器後置字串。舉例來說，如果 Nginx 與兩個通訊埠相關聯，就會在第二個定義的 name 中新增 -2 後置字串：

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 8080
      protocol: HTTPS
      name: backend-server-nginx-2
    - port: 6379
      protocol: TCP
      name: backend-server-redis

執行遷移作業以產生遷移構件時，「遷移至容器」會為每個端點在 deployment_spec.yaml 檔案中建立 Service 定義。

例如，下方顯示 deployment_spec.yaml 檔案中的 Service 定義：

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  name: backend-server-nginx
spec:
  ports:
  - port: 80
    protocol: HTTP
    targetPort: 80
  selector:
    app: backend-server
status:
  loadBalancer: {}

自訂 NFS 掛載

Migrate to Containers 會在產生的遷移計畫中加入 NFS 掛載點。系統會從 fstab 檔案收集這項資訊，並寫入遷移計畫中的 nfsMounts 陣列。您可以新增或編輯 NFS 掛載點定義，自訂遷移計畫。

產生遷移計畫時，Migrate to Containers 會：

• 忽略 /sys 和 /dev 的 NFS 掛接點。
• 忽略 nfs 或 nfs4 以外類型的 NFS 掛載。

遷移計畫中的每個 NFS 掛載點都會以以下格式，提供伺服器的 IP 位址和本機掛載路徑：

    nfsMounts:
    - mountPoint: MOUNT_POINT
      exportedDirectory: DIR_NAME
      nfsServer: IP
      mountOptions:
         - OPTION_1
         - OPTION_2
      enabled: false|true

其中：

• MOUNT_POINT 指定從 fstab 取得的掛接點。
• DIR_NAME 會指定共用目錄的名稱。
• IP 會指定代管掛載點的伺服器 IP 位址。
• OPTION_N 會指定從掛載點的 fstab 中擷取的任何選項。

例如，在 fstab 中使用以下項目：

<file system>       <mount point>   <type>  <options>   <dump>  <pass>
10.49.232.26:/vol1  /mnt/test       nfs     rw,hard     0       0

Migrate to Containers 會在遷移計畫中產生下列項目：

    nfsMounts:
    - mountPoint: /mnt/test
      exportedDirectory: /vol1
      nfsServer: 10.49.232.26
      mountOptions:
         - rw
         - hard
      enabled: false

如要設定 Migrate to Containers 以處理 nfsMounts 陣列中的項目，請將 mountPoint 項目的 enabled 設為 true。您可以啟用一個、部分或所有 mountPoints 項目、編輯項目，或新增自己的項目。

執行遷移作業以產生遷移構件時，「遷移至容器」會為每個已啟用的 NFS 掛載點，在 deployment_spec.yaml 檔案中建立 volumes 和 volumeMounts 定義，以及 PersistentVolume 和 PersistentVolumeClaim 定義。

例如，下方顯示 deployment_spec.yaml 檔案中的 volumeMounts 定義：

    spec:
      containers:
          - image: gcr.io/myimage-1/image-name
            name: some-app
            volumeMounts:
                   - mountPath: /sys/fs/cgroup
                     name: cgroups
                   - mountPath: /mnt/test
                     name: nfs-pv

其中 name 的值是「Migrate to Containers」產生的專屬 ID。

以下是 deployment_spec.yaml 檔案中的 PersistentVolumeClaim 和 PersistentVolume 定義範例：

apiVersion: v1
kind: PersistentVolumeClaim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Mi
  storageClassName: ""
  volumeName: nfs-pv

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  mountOptions:
    - rw
    - hard
  nfs:
    path: /vol1
    server: 10.49.232.26

自訂寫入 Cloud Logging 的記錄資料

一般來說，來源 VM 會將資訊寫入一或多個記錄檔。在遷移 VM 的過程中，您可以設定已遷移的工作負載，將記錄資訊寫入 Cloud Logging。

產生遷移計畫時，「遷移至容器」會自動在來源 VM 上搜尋記錄目的地檔案。Migrate to Containers 接著將這些偵測到的檔案相關資訊寫入遷移計畫的 logPaths 區域：

deployment:
    ...
    logPaths:
    - appName: APP_NAME
      globs:
      - LOG_PATH

例如：

deployment:
    ...
    logPaths:
    - appName: tomcat
      globs:
      - /var/log/tomcat*/catalina.out

產生遷移構件時，Migrate to Containers 會從遷移計畫產生 logs.yaml 檔案。這個檔案包含在來源 VM 上偵測到的記錄檔清單。舉例來說，根據上述 logsPath 定義，logs.yaml 包含：

logs:
  tomcat:
  - /var/log/tomcat*/catalina.out

在這個範例中，部署遷移後的工作負載時，寫入 catalina.out 的記錄資訊會自動寫入 Cloud Logging。

記錄檔中的每個項目會以以下格式顯示在記錄檔的一行中：

DATE TIME APP_NAME LOG_OUTPUT

以下範例說明含有 Tomcat 項目的表單：

2019-09-22 12:43:08.681193976 +0000 UTC tomcat log-output

如要設定記錄，您可以：

• 請先編輯遷移計畫，再產生遷移構件，以便新增、移除或編輯 logPaths 項目。產生遷移構件時，這些編輯會反映在 logs.yaml 檔案中。

• 產生遷移構件後，請編輯 logs.yaml，以便新增、移除或編輯 logs 項目。

編輯遷移計畫的好處是，每次產生構件時，編輯內容都會反映在 logs.yaml 中。如果您直接編輯 logs.yaml，然後基於某些原因重新產生構件，就必須將編輯內容重新套用至 logs.yaml。

設定 Linux v2kServiceManager 健康檢查

您可以在 Tomcat 網路伺服器的遷移計畫中指定探針，監控受管理容器的停機時間和就緒狀態。健康探針監控功能可縮短已遷移容器的停機時間，並提供更完善的監控功能。

不明的健康狀態可能會導致可用性降低、可用性監控出現誤報，以及潛在的資料遺失。如果沒有健康狀態探測，kubelet 只能假設容器的健康狀態，並可能將流量傳送至尚未就緒的容器執行個體。這可能會導致流量流失。Kubelet 也可能不會偵測到處於凍結狀態的容器，並且不會重新啟動這些容器。

健康探針會在容器啟動時執行簡短的指令碼陳述式。指令碼會在每個週期檢查成功的條件，這些條件由所使用的探針類型定義。在遷移計畫中，期間是由 periodSeconds 欄位定義。您可以手動執行或定義這些指令碼。

如要進一步瞭解 kubelet 探測功能，請參閱 Kubernetes 說明文件中的「Configure Liveness, Readiness and Startup Probes」一文。

您可以設定兩種類型的探針，兩者都是在 probe-v1-core 參考資料中定義的 probe-v1-core，並與 container-v1-core 的對應欄位共用相同函式。

• 有效性探測：有效性探測可用於瞭解何時重新啟動容器。

• Readiness 探測：Readiness 探測可用於瞭解容器何時可以開始接收流量。如要只在探測成功時開始將流量傳送至 Pod，請指定 readiness 探測。就行為而言，就緒性探測可能與有效性探測類似，但規格中的就緒性探測表示 Pod 會在未接收任何流量的情況下啟動，並在探測成功後才開始接收流量。

探索完成後，探針設定會新增至遷移計畫。探針可用於預設設定，如以下所示。如要停用探針，請從 yaml 中移除 probes 部分。

deployment:
  probes:
    livenessProbe:
      exec:
        command:
        - /ko-app/service-manager-runtime
        - /probe

    readinessProbe:
      exec:
        command:
        - gamma
        - /probe
      initialDelaySeconds: 60
      periodSeconds: 5

image:
  # Disable system services that do not need to be executed at the migrated workload containers.
  # Enable the 'probed' property to include system services in the container health checks.
  systemServices:
  - enabled: true
    name: apache2
    probed: true
  - enabled: true
    name: atd
    probed: false 

根據預設，系統會停用所有服務探測功能。您必須定義要監控的服務子集。

使用探針檢查容器的方式有四種預先定義方式。每個探測器都必須定義下列四種機制之一：

• exec：在容器內執行指定指令。如果結束狀態碼為 0，則視為執行成功。
• grpc：使用 `gRPC` 執行遠端程序呼叫。`gRPC` 探針是 Alpha 版功能。
• httpGet：針對 Pod 的 IP 位址，在指定的連接埠和路徑上執行 HTTP GET 要求。如果狀態碼大於或等於 200 且小於 400，系統會視為要求成功。
• tcpSocket：針對指定通訊埠上的 Pod IP 位址執行 TCP 檢查。如果通訊埠已開啟，系統會將診斷結果視為成功。

根據預設，遷移計畫會啟用 exec 探測方法。請為遷移計畫使用手動設定，啟用其他方法。

如要為就緒探針新增外部依附元件，並使用預設的活動探針，請定義執行就緒探針和實作邏輯的指令碼。

後續步驟

• 瞭解如何執行遷移作業。