將使用者叢集遷移至建議功能

總覽

本頁說明如何將 1.30 以上版本的使用者叢集，遷移至下列建議功能：

• 改用 Dataplane V2 做為容器網路介面 (CNI)。
• 將使用 kubeception 的使用者叢集遷移至 Controlplane V2。

• 遷移負載平衡器設定：

  • 從整合式 F5 BIG-IP 負載平衡器設定到 ManualLB

    或

  • 從隨附的 Seesaw 負載平衡器到 MetalLB。

本頁面適用於負責管理基礎技術基礎架構生命週期的 IT 管理員和操作人員。如要瞭解Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 GKE 使用者角色和工作」。

最佳做法

建議您先遷移最不重要的環境，例如測試環境。確認遷移成功後，請為每個環境重複這項程序，最後再遷移正式環境。這樣一來，您就能先驗證每次遷移是否成功，並確保工作負載正常運作，再遷移至下一個更重要的環境。

建議您建立新的使用者叢集，並啟用 Controlplane V2，瞭解與 kubeception 叢集的架構差異。新叢集不會影響工作負載。不過，在最壞的情況下，如果遷移失敗，您仍有叢集可供工作負載使用。

如要進一步瞭解遷移規劃，請參閱「規劃叢集遷移至建議功能」。

需求條件

這項遷移作業：

• 使用者叢集必須為 1.30 以上版本。
• 所有節點集區的版本必須與使用者叢集相同。
• 如果叢集使用 Seesaw 負載平衡器，請確保您未依賴 Seesaw 保留用戶端 IP，詳情請參閱下一節。

Seesaw 用戶端 IP 保留

警告： 如果您仰賴 Seesaw 保留用戶端 IP 位址，請勿遷移至 MetalLB。具體來說，如果叢集中的 Service 將 spec.externalTrafficPolicy 設為 Local，請勿遷移至 MetalLB。

如要檢查 externalTrafficPolicy，請執行下列指令：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"

如果遇到這個問題，請與 Google 支援團隊聯絡。

預估所需時間並規劃維護期間

更新叢集時，系統預設會同時更新所有節點集區。不過，在每個節點集區中，節點會依序更新。因此，總更新時間取決於最大節點集區中的節點數量。如要粗略估算每次更新的費用，請按照下列步驟操作：

• 如果從 Seesaw 遷移至 MetalLB，請預估 15 分鐘的更新時間，為 MetalLB 負載平衡器選擇節點集區。這項更新只會套用至所選節點集區。
• 對於遷移程序中的任何其他更新，請將 15 分鐘乘以節點集區中的節點數量。

如要估算所需時間，請計算需要更新叢集的次數。以下概略說明何時需要執行 gkectl update cluster 來更新叢集：

1. 如果使用者叢集使用全天候運作的 Secret 加密功能，請停用該功能並執行 gkectl update cluster。
2. 如果使用者叢集的 enableDataplaneV2 未設定或設為 false，請變更設定，然後執行 gkectl update cluster，遷移至 Dataplane V2。

3. 準備遷移負載平衡器和控制層：

   1. 如果管理員叢集已啟用自動修復功能，請停用該功能。接著執行 gkectl update admin。這項更新不會重新建立管理員叢集節點，因此很快就會完成。
   2. 如果使用者叢集使用 Seesaw，請選擇要用於 MetalLB 負載平衡器的節點集區，然後執行 gkectl update cluster。這項更新只會更新所選節點集區中的節點。

4. 請完成所有必要的設定變更，更新負載平衡器並遷移至 Controlplane V2。然後執行 gkectl update cluster。

5. 遷移後，如果您停用了隨時可用的密鑰加密功能，請重新啟用該功能並執行 gkectl update cluster。

遷移作業的總時間取決於您必須執行 gkectl cluster update 的次數，而這取決於您的設定。舉例來說，假設您要遷移至 Dataplane V2、ControlPlane V2 和 MetalLB。另外假設最大節點集區有 10 個節點，MetalLB 將使用的節點集區有 3 個節點。如要計算預估遷移時間，請加上以下項目：

• 150 分鐘，因為 15 分鐘 * 最大集區中的 10 個節點 = 150 分鐘。
• MetalLB 使用的節點集區需要 45 分鐘，因為 15 分鐘 * 該節點集區中的 3 個節點 = 45 分鐘。
• Controlplane V2 和 MetalLB 更新作業需要 150 分鐘，因為 15 分鐘 * 最大集區中的 10 個節點 = 150 分鐘。

遷移作業總共需要約 345 分鐘，也就是 5 小時 45 分鐘。

如有需要，您可以分階段進行遷移。以上述例子來說，您可以在一個維護期間內遷移至 Dataplane V2，並在一或兩個維護期間內完成其餘遷移作業。

規劃遷移期間的停機時間

規劃遷移作業時，請考量下列停機時間類型：

• 控制層停機時間：遷移期間，Kubernetes API 伺服器的存取權會受到影響。如果遷移至 Controlplane V2，kubeception 使用者叢集的控制層會因 loadBalancer.vips.controlPlaneVIP 遷移而停機。停機時間通常不超過 10 分鐘，但實際長度取決於您的基礎架構。
• 工作負載停機時間：LoadBalancer 類型的 Service 使用的虛擬 IP (VIP) 無法使用。只有在從 Seesaw 遷移至 MetalLB 時，才會發生這種情況。MetalLB 遷移程序會停止使用者叢集中所有 VIP 的網路連線，以便處理 LoadBalancer 類型的 Kubernetes Service，時間約為 2 到 10 分鐘。遷移完成後，連線就會恢復運作。

下表說明遷移作業的影響：

寄件者	收件者	Kubernetes API 存取權	使用者工作負載
使用 Calico 的 Kubeception 叢集，其 enableDataplaneV2 未設定或設為 false	採用 Dataplane V2 的 Kubeception 叢集	不受影響	不受影響
Kubeception 叢集，其 enableControlplaneV2 未設定或設為 false，並具有 MetalLB 或 ManualLB	Controlplane V2 叢集，使用相同類型的負載平衡器	受影響	不受影響
含有 loadBalancer.kind: "F5BigIP" 的 Kubeception 叢集	Controlplane V2 叢集，採用手動負載平衡器設定	受影響	不受影響
含有 loadBalancer.kind: "Seesaw" 的 Kubeception 叢集	採用 MetalLB 的 Controlplane V2 叢集	受影響	受影響

• 受影響：遷移期間服務明顯中斷。
• 不受影響：服務未中斷，或幾乎察覺不到。

為遷移作業做好準備

為確保遷移作業順利完成，請按照下列各節的步驟操作。

分配新的 IP 位址

如要遷移至 Controlplane V2，請在與 worker 節點 (節點集區中的節點) 相同的 VLAN 中，分配新的靜態 IP 位址。

• loadBalancer.vips.controlPlaneVIP 需要一個 IP 位址。

• 為每個控制層節點分配一個 IP 位址。您需要分配的 IP 位址數量，取決於使用者叢集是否具備高可用性 (HA)。

  • 非高可用性：一個 IP 位址
  • 高可用性：三個 IP 位址

更新防火牆規則

如果您要遷移至 Controlplane V2，請更新使用者叢集的防火牆規則。確保使用者叢集上控制層節點新分配的 IP 位址，可以連到所有必要的 API 和其他目的地，詳情請參閱「防火牆規則使用者叢集節點」。

檢查叢集和節點集區版本

確認所有節點集區使用的版本與使用者叢集相同，且必須是 1.30 以上版本。如果不是，請先將節點集區升級至使用者叢集設定檔中的 gkeOnPremVersion，再繼續遷移。如要檢查版本，請執行下列指令：

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

將 ADMIN_CLUSTER_KUBECONFIG 替換為管理員叢集 kubeconfig 檔案的路徑。

檢查叢集健康狀態

檢查叢集健康狀態，並修正 gkectl diagnose cluster 指令回報的所有問題：

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name USER_CLUSTER_NAME

更改下列內容：

• ADMIN_CLUSTER_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑。
• USER_CLUSTER_NAME：使用者叢集的名稱。

停用管理員叢集的自動修復功能

如果您要將使用者叢集遷移至 Controlplane V2，且管理員叢集已啟用自動修復功能，請停用自動修復功能。請查看管理員叢集設定檔的 autoRepair.enabled 欄位。如果該欄位未設定或設為 true，請執行下列步驟：

1. 在管理員叢集設定檔中，將 autoRepair.enabled 設為 false。例如：

   autoRepair:
     enabled: false
   

2. 更新管理員叢集：

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config ADMIN_CLUSTER_CONFIG
   

更改下列內容：

• ADMIN_CLUSTER_KUBECONFIG：管理員叢集的 kubeconfig 檔案路徑。
• ADMIN_CLUSTER_CONFIG：管理員叢集設定檔的路徑。

遷移完成後，請務必重新啟用管理員叢集的自動修復功能。

檢查全天候運作的 Secret 加密功能是否有問題

如果您要將使用者叢集遷移至 Controlplane V2，請檢查一律啟用的 Secret 加密功能是否有問題。

如果使用者叢集曾啟用全天候運作的 Secret 加密功能，您必須先完成「停用全天候運作的 Secret 加密功能並解密 Secret」一節中的步驟，才能開始遷移。否則，新的 Controlplane V2 叢集將無法解密 Secret。

開始遷移前，請執行下列指令，確認是否曾啟用一律啟用 Secret 加密功能：

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

如果上述指令的輸出內容空白，表示一律啟用的 Secret 加密功能從未啟用。您可以開始遷移。

如果上述指令的輸出內容並非空白，表示先前已啟用一律啟用的 Secret 加密功能。遷移前，請務必完成下一節的步驟，確保新的 Controlplane V2 叢集可以解密 Secret。

以下範例顯示非空白輸出：

{"generatedKeyVersions":{"keyVersions":[1]}}

警告： 如果您已開始遷移，但尚未完成下一節的步驟，請向 Google 尋求支援。

停用一律啟用的 Secret 加密功能，並視需要解密 Secret

如要停用一律啟用的 Secret 加密功能並解密 Secret，請按照下列步驟操作：

1. 如要停用隨時可用的 Secret 加密功能，請在使用者叢集設定檔的 secretsEncryption 區段中新增 disabled: true 欄位：

   secretsEncryption:
       mode: GeneratedKey
       generatedKey:
           keyVersion: KEY_VERSION
           disabled: true
   

2. 更新叢集：

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config USER_CLUSTER_CONFIG
   

   更改下列內容：

   • ADMIN_CLUSTER_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑
   • USER_CLUSTER_CONFIG：使用者叢集設定檔的路徑

3. 對特定 DaemonSet 執行滾動式更新，如下所示：

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     rollout restart statefulsets kube-apiserver \
     -n USER_CLUSTER_NAME

4. 以 YAML 格式取得使用者叢集中所有 Secret 的資訊清單：

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
     get secrets -A -o yaml > SECRETS_MANIFEST.yaml

5. 為確保所有 Secret 都以明文形式儲存在 etcd 中，請重新套用使用者叢集中的所有 Secret：

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
     apply -f SECRETS_MANIFEST.yaml

   現在可以開始遷移至 Controlplane V2。遷移完成後，您可以重新啟用叢集的全天候運作 Secret 加密功能。

檢查工作負載 Webhook 設定錯誤的問題

如果您要將使用者叢集遷移至 Controlplane V2，請檢查工作負載 Webhook 設定是否正確。

如果 Webhook 包含 kube-system 命名空間中的系統 Pod，請新增 namespaceSelector，篩除 kube-system 命名空間。

例如：

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

啟用節點集區，供 MetalLB 使用

如果您是從套裝 Seesaw 負載平衡器遷移至 MetalLB，請執行本節中的步驟。如果使用者叢集設定檔中有 loadBalancer.kind: Seesaw，表示叢集正在使用 Seesaw。如要遷移整合式 F5 BIG-IP 設定，請跳至下一節「遷移至 Dataplane V2」。

選擇節點集區，並啟用 MetalLB。遷移作業會在該節點集區的節點上部署 MetalLB。

警告： 請確認您啟用供 MetalLB 使用的節點集區，不含網路位址轉譯 (NAT) 輸入量高的 Service IP 位址。這可能導致工作負載記憶體不足。請改用其他現有節點集區，或建立新的節點集區供 MetalLB 使用。

1. 在使用者叢集設定檔的 nodePools 區段中，選擇節點集區或新增節點集區，然後將 enableLoadBalancer 設為 true。例如：

   nodePools:
     - name: pool-1
       replicas: 3
       enableLoadBalancer: true
   

2. 更新叢集：

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config USER_CLUSTER_CONFIG
   

如要進一步瞭解 MetalLB，請參閱「使用 MetalLB 隨附的負載平衡功能」。

遷移至 Dataplane V2

遷移前，請執行下列指令，檢查叢集是否已啟用 DataPlane V2：

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -o yaml | grep enableDataplaneV2

如果已啟用 Dataplane V2：

• 如果叢集原本建立時已啟用 Dataplane V2，請跳至「準備遷移負載平衡器」。
• 如果叢集先前已從 Calico 遷移至 Dataplane V2 (例如在升級至 1.31 版期間)，請跳至「移除休眠的 Calico DaemonSet」。

如要遷移至 Dataplane V2，可以選擇下列做法：

• 將叢集升級至 1.31。如需詳細步驟，請參閱「啟用 Dataplane V2」。

• 更新 1.30 叢集。

無論是哪一種情況，您都必須暫時移除 NetworkPolicy 規格，如下列步驟所述。

如要遷移至 Dataplane V2，請按照下列步驟操作。如果對暫時移除 NetworkPolicy 規格有疑慮，請與 Google 支援團隊聯絡。

如果叢集使用 NetworkPolicy，請暫時從叢集移除其規格，如下所示：

1. 檢查叢集是否套用了任何非系統 NetworkPolicy：

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system
   

2. 如果上一個步驟的輸出內容並非空白，請將每個 NetworkPolicy 規格儲存至檔案，以便在更新叢集後重新套用規格。

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
   

   更改下列內容：

   • NETWORK_POLICY_NAME：要儲存的 NetworkPolicy 名稱。
   • NETWORK_POLICY_NAMESPACE：NetworkPolicy 的命名空間。

3. 使用下列指令刪除 NetworkPolicy：

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE
   

請按照下列步驟遷移至 Dataplane V2：

1. 在使用者叢集設定檔中，將 enableDataplaneV2 設為 true。

2. 如要啟用 DataPlane V2，請更新叢集：

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
   --config USER_CLUSTER_CONFIG
   

3. 如果您在先前步驟中移除了任何非系統 NetworkPolicy 規格，請在更新完成後，使用下列指令重新套用這些規格：

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
   

您已啟用 Dataplane V2。

移除閒置的 Calico DaemonSet

將管理員叢集或使用者叢集從 Calico 遷移至 Dataplane V2 後，calico-node 和 calico-route-daemon DaemonSet 會在 kube-system 命名空間中保持休眠狀態，以保留復原功能。在資源調度或升級叢集之前，請先為每個遷移的叢集移除 features.onprem.cluster.gke.io/dpv2-migration 註解一次，讓叢集控制器永久刪除閒置的 Calico DaemonSet，並防止這些 DaemonSet 在新節點上初始化 (請參閱將叢集從 Calico 遷移至 Dataplane V2 後，升級或資源調度後間歇性連線逾時已知問題)。如果叢集建立時已啟用 Dataplane V2，則不必執行這些步驟。

注意： 請務必在所有節點都完成 Dataplane V2 遷移作業後，再移除這個註解。如果叢集仍在使用 Calico 或正在遷移，移除這個標籤會將 Calico 從現有節點中剔除，並中斷 Pod 網路。

1. 確認 Dataplane V2 遷移作業已完成，且叢集中的所有節點都有 networking.gke.io/cni-type: cilium 標籤：

   kubectl --kubeconfig CLUSTER_KUBECONFIG get nodes -L networking.gke.io/cni-type
   

   將 CLUSTER_KUBECONFIG 替換為使用者叢集或管理員叢集 kubeconfig 檔案的路徑。

2. 確認 Dataplane V2 已在所有節點上執行，且不再需要復原至 Calico 後，請從 OnPremUserCluster 自訂資源中移除 features.onprem.cluster.gke.io/dpv2-migration 註解 (如果管理員叢集是在從 1.29 版升級至 1.30 版期間從 Calico 遷移，則也請從 OnPremAdminCluster 中移除)：

   # For a user cluster:
   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG annotate onpremusercluster USER_CLUSTER_NAME \
       -n USER_CLUSTER_NAME-gke-onprem-mgmt \
       features.onprem.cluster.gke.io/dpv2-migration-
   
   # For an admin cluster:
   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG annotate onpremadmincluster ADMIN_CLUSTER_NAME \
       -n kube-system \
       features.onprem.cluster.gke.io/dpv2-migration-
   

   更改下列內容：

   • ADMIN_CLUSTER_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑。
   • USER_CLUSTER_NAME：使用者叢集的名稱。
   • ADMIN_CLUSTER_NAME：管理員叢集的名稱 (您可以執行 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremadmincluster -n kube-system 來查看)。
   注意： 請勿使用 kubectl delete daemonset 手動刪除 DaemonSet，因為叢集控制器會在更新和升級期間協調外掛程式套件，並重新建立 DaemonSet，除非您移除 features.onprem.cluster.gke.io/dpv2-migration 註解。

3. 確認控制器已刪除 calico-node 和 calico-route-daemon DaemonSet (兩者都會傳回 NotFound)：

   kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-system get daemonset calico-node calico-route-daemon
   

接下來，請準備將叢集遷移至建議的負載平衡器和 Controlplane V2。

準備遷移負載平衡器

如果使用者叢集使用 Seesaw 負載平衡器或整合式 F5 BIG-IP，請按照本節中的步驟，對使用者叢集設定檔進行必要變更。否則，請跳至下一節「準備遷移至 Controlplane V2」。

F5 BIG-IP

如果叢集使用整合式 F5 BIG-IP 設定，請對使用者叢集設定檔進行下列變更，為遷移至 ManualLB 做好準備：

1. 將 loadBalancer.kind 變更為 "ManualLB"。
2. loadBalancer.vips.ingressVIP 欄位的值保持不變。
3. 如要遷移至 Controlplane V2，請將 loadBalancer.vips.controlPlaneVIP 欄位的值變更為您分配的 IP 位址。否則，您可以保留相同的值。
4. 刪除整個 loadBalancer.f5BigIP 區段。

以下使用者叢集設定檔範例顯示了這些變更：

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.5
  ingressVIP: 198.51.100.20
kind: "f5BigIP" "ManualLB"
f5BigIP:
  address: "203.0.113.2"
  credentials:
  fileRef:
    path: "my-config-folder/user-creds.yaml"
    entry: "f5-creds"
  partition: "my-f5-user-partition"

Seesaw

如果使用者叢集使用 Seesaw 負載平衡器，請按照下列各節的步驟操作，為遷移至 MetalLB 做好準備。

指定位址集區

MetalLB 控制器會為 Service 指派 IP 位址。應用程式開發人員在使用者叢集中建立 LoadBalancer 類型的 Service 時，MetalLB 控制器會自動為 Service 指派 IP 位址。MetalLB 控制器會從您指定的位址集區中選取 IP 位址。

為確保使用者叢集有足夠的 IP 位址，請考量可能處於運作中狀態的 LoadBalancer 服務數量上限。然後在使用者叢集設定檔的 loadBalancer.metalLB.addressPools 區段中指定足夠的 IP 位址。

重點： 由於 LoadBalancer 類型的 Service 會公開輸入 Proxy，因此您必須在其中一個位址集區中加入使用者叢集的輸入 VIP。

集區中的位址必須採用 CIDR 格式或範圍格式。如要指定個別位址，請使用 /32 CIDR。例如：

addresses:
  -   "192.0.2.0/26"
  -   "192.0.2.64-192.0.2.72"
  -   "192.0.2.75/32"

排除用於其他用途的 IP 位址

請勿在任何位址集區中加入下列 IP 位址：

• 控制層 VIP：

  • 管理員叢集
  • 使用者叢集

• 控制層節點 IP 位址：

  • 管理員叢集
  • 使用者叢集

• 閘道 IP 位址：

  • 管理員叢集
  • 使用者叢集

• Service 的 IP 位址：

  • 管理員叢集
  • 使用者叢集

• Pod 的 IP 位址：

  • 管理員叢集
  • 使用者叢集

• 使用者叢集worker 節點 IP 位址

• vCenter 伺服器、DNS 伺服器、NTP 伺服器和管理員工作站的 IP 位址

更新叢集設定檔

更新叢集設定檔，移除 Seesaw 區段並新增 MetalLB 區段，如下所示：

1. 將 loadBalancer.kind 設為 "MetalLB"。
2. loadBalancer.vips.ingressVIP 欄位的值可以保持不變。
3. 將 Ingress VIP 新增至 MetalLB 位址集區。
4. 如要遷移至 Controlplane V2，請將 loadBalancer.vips.controlPlaneVIP 欄位的值變更為您分配的 IP 位址。否則，您可以保留相同的值。
5. 移除 loadBalancer.seesaw 部分。
6. 新增 loadBalancer.metalLB 區段。

以下使用者叢集設定檔部分顯示了這些變更，以及 MetalLB 設定：

• MetalLB 控制器可從中選擇並指派給 LoadBalancer 類型 Service 的位址集區。Ingress VIP (在本範例中為 198.51.100.10) 位於這個集區中，以範圍格式標記法 198.51.100.10/32 表示。
• 為使用者叢集的 Kubernetes API 伺服器指定的 VIP。
• 您為 Ingress Proxy 設定的 Ingress VIP。
• 已啟用 MetalLB 的節點集區。遷移作業會在這個節點集區的節點上部署 MetalLB。

loadBalancer:
  vips:
    controlPlaneVIP: "198.51.100.50"
    ingressVIP: "198.51.100.10"
  kind: "MetalLB" "Seesaw"
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
      - name: "address-pool-1"
        addresses:
        - "198.51.100.10/32"
        - "198.51.100.80 - 198.51.100.89"

準備遷移至 Controlplane V2

如果叢集未啟用 Controlplane V2：

• 更新使用者叢集設定檔。
• 如果叢集使用手動負載平衡 (loadBalancer.kind: "ManualLB")，請一併更新負載平衡器的設定。

以下各節將說明這些步驟。

如果叢集已啟用 Controlplane V2，請跳至「遷移使用者叢集」一節。

更新使用者叢集設定檔

對現有的使用者叢集設定檔進行下列變更：

1. 將 enableControlplaneV2 設為 true。
2. 您可以選擇將 Controlplane V2 使用者叢集的控制層設為高可用性 (HA)。如要從非高可用性叢集變更為高可用性叢集，請將 masterNode.replicas 從 1 變更為 3。
3. 將使用者叢集控制層節點的靜態 IP 位址新增至 network.controlPlaneIPBlock.ips 區段。控制層節點的 IP 位址必須與 worker 節點位於相同的 VLAN。必須提供主機名稱。
4. 在 network.controlPlaneIPBlock 區段中填入 netmask 和 gateway。
5. 如果 network.hostConfig 區段空白，請填寫內容。
6. 確認 loadBalancer.vips.controlPlaneVIP 欄位含有控制層虛擬 IP 的新 IP 位址。IP 位址必須與控制層節點 IP 位於相同的 VLAN。
7. 如果使用者叢集採用手動負載平衡，請將 loadBalancer.manualLB.controlPlaneNodePort 和 loadBalancer.manualLB.konnectivityServerNodePort 設為 0。啟用 Controlplane V2 時，不一定要提供這些欄位，但值必須為 0。
8. 如果使用者叢集採用手動負載平衡，請按照下一節的說明設定負載平衡器。

注意： 請務必仔細檢查所有設定。除了更新叢集以進行遷移時，上述所有欄位都不可變更。

視需要調整負載平衡器中的對應

如果使用者叢集已使用手動負載平衡，您必須在負載平衡器上設定一些對應。如果您是從整合式 F5 BIG-IP 設定遷移至手動負載平衡，則不需要變更負載平衡器的設定，可以直接跳到下一節「遷移使用者叢集」。

針對您在 network.controlPlaneIPBlock 區段中指定的每個 IP 位址，請在負載平衡器中為控制層節點設定下列對應：

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPSNodePort)

使用者叢集中的所有節點 (包括控制層節點和 worker 節點) 都需要這些對應。由於 NodePort 是在叢集上設定，Kubernetes 會在所有叢集節點上開啟 NodePort，因此叢集中的任何節點都能處理資料層流量。

設定對應後，負載平衡器會監聽您為使用者叢集輸入 VIP 設定的 IP 位址，監聽標準 HTTP 和 HTTPS 通訊埠上的流量。負載平衡器會將要求轉送至叢集中的任何節點。要求轉送至其中一個叢集節點後，Kubernetes 內部網路會將要求轉送至目的地 Pod。

遷移使用者叢集

首先，請仔細檢查您對使用者叢集設定檔所做的所有變更。除了更新叢集以進行遷移，所有負載平衡器和 Controlplane V2 設定都無法變更。

如要更新叢集，請執行下列指令：

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Controlplane V2 遷移

在 Controlplane V2 遷移期間，更新作業會執行下列動作：

1. 建立新叢集的控制層，並啟用 ControlPlane V2。
2. 停止 kubeception 叢集的 Kubernetes 控制層。
3. 建立 kubeception 叢集的 etcd 快照。
4. 關閉 kubeception 叢集的使用者叢集控制層節點。在遷移完成前，節點不會刪除，因為這樣才能復原至該 kubeception 叢集，以便復原失敗。
5. 使用先前步驟建立的 etcd 快照，在新控制層中還原叢集資料。
6. 將 kubeception 叢集的節點集區節點連線至新的控制層，可透過新的 controlPlaneVIP 存取。
7. 協調還原的使用者叢集，以符合已啟用 ControlPlane V2 的叢集最終狀態。

注意事項：

• 遷移期間，使用者叢集工作負載不會停機。
• 遷移期間，使用者叢集控制層會停機一段時間。具體來說，在停止 kubeception 叢集的 Kubernetes 控制層，到 kubeception 叢集的節點集區節點連線至新控制層之間，控制層無法使用。(在測試中，這段停機時間不到 7 分鐘，但實際長度取決於您的基礎架構)。
• 遷移作業結束時，kubeception 叢集的使用者叢集控制層節點會遭到刪除。如果管理員叢集的 network.ipMode.type 設為 "static"，您可以回收部分未使用的靜態 IP 位址。您可以使用 kubectl get nodes -o wide 列出管理員叢集節點物件，查看正在使用的 IP 位址。如要回收這些 IP 位址，請從管理員叢集設定檔中移除這些位址，然後執行 gkectl update admin。
• 遷移作業結束時，worker 節點會進行滾動式更新。請等待所有節點準備就緒，再繼續執行下一節的遷移後步驟。
• 遷移後，舊的控制層 VIP 位址仍可運作，但並不穩定。請勿依賴這項功能。請盡快更新舊 VIP 位址的所有依附元件，改用新 VIP 位址。

遷移之後

更新完成後，請按照下列步驟操作：

1. 確認使用者叢集正在運作：

   kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG
   

   輸出結果會與下列內容相似：

   cp-vm-1       Ready    control-plane,master   18m
   cp-vm-2       Ready    control-plane,master   18m
   cp-vm-3       Ready    control-plane,master   18m
   worker-vm-1   Ready                           6m7s
   worker-vm-2   Ready                           6m6s
   worker-vm-3   Ready                           6m14s
   

2. 如果您已遷移至 Controlplane V2，請更新管理員叢集的防火牆規則，移除 kubeception 使用者叢集的控制層節點。

3. 如果停用了 Secret 永久加密功能，請重新啟用。

   1. 在使用者叢集設定檔中，移除 disabled: true 欄位。

   2. 更新使用者叢集：

      gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          --config USER_CLUSTER_CONFIG
      

4. 如果您在管理員叢集中停用自動修復功能，請重新啟用。

   1. 在管理員叢集設定檔中，將 autoRepair.enabled 設為 true。

   2. 更新叢集：

      gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          --config ADMIN_CLUSTER_CONFIG
      

負載平衡器遷移

如果您已遷移負載平衡器，請確認負載平衡器元件是否成功運作。

MetalLB 遷移

如果您已遷移至 MetalLB，請確認 MetalLB 元件是否成功執行：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

輸出內容會顯示 MetalLB 控制器和揚聲器的 Pod。例如：

metallb-controller-744884bf7b-rznr9   1/1     Running
metallb-speaker-6n8ws                 1/1     Running
metallb-speaker-nb52z                 1/1     Running
metallb-speaker-rq4pp                 1/1     Running

遷移成功後，請刪除使用者叢集中已關機的 Seesaw VM。您可以在設定目錄中 seesaw-for-[USERCLUSTERNAME].yaml 檔案的 vmnames 區段找到 Seesaw VM 名稱。

F5 BIG-IP 遷移

遷移至手動負載平衡後，叢集的流量不會中斷。這是因為現有的 F5 資源仍然存在，您可以執行下列指令來查看：

kubectl --kubeconfig CLUSTER_KUBECONFIG \
api-resources --verbs=list -o name | xargs -n 1 kubectl --kubeconfig
CLUSTER_KUBECONFIG get --show-kind --ignore-not-found
--selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

預期輸出內容大致如下：

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-sspwrd   Opaque   4      14h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         14h
kube-system   serviceaccount/load-balancer-f5   0         14h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           14h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           14h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         14h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   14h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T05:16:40Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T05:16:41Z