將 VMware 上的 Knative Serving 升級至 Fleet

瞭解如何遷移 VMware 上的 Knative Serving，改用 Fleet，以便升級至 Anthos 1.8 版。

Knative serving 現在已從代管 Cloud Run 產品中獨立出來，並以叢集中的車隊元件形式提供。在 VMware 功能上安裝 Knative serving 做為機群元件，可讓您獨立管理及升級安裝項目，不必擔心影響其他機群元件。

如要將 VMware 安裝的 Knative Serving 遷移至車隊，您必須：

  • 設定 VMware 安裝的 Knative serving，以符合機群需求。
  • 在機群中啟用 Knative serving 功能元件。

請注意，Kubernetes API 伺服器不會在遷移期間受到影響。

如要瞭解如何在 VMware 上全新安裝 Knative serving，請參閱「在 VMware 上安裝 Knative serving」。

事前準備

你必須符合下列條件：

  • 如要完成這些步驟，您必須向機群註冊 VMware 叢集上的 Knative 服務，並在 Google Cloud 控制台中查看：

    前往 GKE 叢集

  • 您在 VMware 中安裝的 Knative Serving 位於執行 Anthos 1.7 版或更早版本的叢集。

  • Anthos 1.8 不再支援 Istio。您必須先在機群中安裝 Cloud Service Mesh 1.18 版，並設定 Knative serving 安裝作業，才能將叢集升級至 1.8 版。

    如要瞭解如何在 Google Distributed Cloud 上安裝，請參閱 Cloud Service Mesh 操作說明。

    請注意，Cloud Service Mesh 規定叢集必須使用至少有四個 vCPU 的機器類型，例如 e2-standard-4。如要變更叢集的機器類型，請參閱「將工作負載遷移至不同的機器類型」。

  • 您可以透過下列兩種方式，將 Knative 服務遷移至 Cloud Service Mesh：

    • 取得新的外部 IP 位址，並設定負載平衡器。

    • 重複使用現有的負載平衡器 IP 位址。

  • 確認指令列環境已設定完成並為最新版本。

遷移至機群

如要將 Anthos 升級至 1.8 版，請先執行下列步驟，確保現有的 VMware 安裝項目上的 Knative Serving 已遷移至使用機群元件。

存取管理員叢集

取得管理員叢集 kubeconfig 檔案的路徑和檔案名稱，然後建立 ADMIN_KUBECONFIG 環境變數：

export ADMIN_KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]

請將 [ADMIN_CLUSTER_KUBECONFIG] 替換為管理員叢集的 kubeconfig 檔案路徑和檔案名稱。

設定每個使用者叢集

  1. 為使用者叢集建立下列本機環境變數：

    1. 使用使用者叢集 kubeconfig 檔案的路徑建立 USER_KUBECONFIG 環境變數：

      export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]

      將 [USER_CLUSTER_KUBECONFIG] 替換為使用者叢集 kubeconfig 檔案的路徑和檔案名稱。

    2. 為下列設定建立環境變數：

      • Google Cloud 專案的 ID。
      • Google Cloud 資源的位置。
      • 使用者叢集名稱。
      export PROJECT_ID=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-project-id']}")
export CLUSTER_LOCATION=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-gcp-location']}")
export CLUSTER_NAME=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-cluster-name']}")

  2. 從使用者叢集的 OnPremUserCluster 自訂資源中移除 cloudrun 設定：

    1. 確認 cloudRun 已在 OnPremUserCluster 中設定：

      $ kubectl get onpremusercluster \
  "${CLUSTER_NAME}" \
  --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --output=jsonpath="{.spec.cloudRun}"

      結果：

      {"enabled":true}

    2. 從 OnPremUserCluster 移除 cloudRun：

      kubectl patch onpremusercluster \
  "${CLUSTER_NAME}" \
  --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --type="merge" \
  --patch '{"spec": {"cloudRun": null}}'

    3. 執行相同的 get 指令，並確認未傳回任何設定，藉此驗證 cloudRun 是否已從 OnPremUserCluster 中成功移除：

      kubectl get onpremusercluster \
  "${CLUSTER_NAME}" \
  --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --output=jsonpath="{.spec.cloudRun}"

      終端機不應有任何輸出內容。

  3. 更新使用者叢集的 create-config 密鑰：

    1. 建立 create-config 檔案的本機 YAML 副本：

      kubectl get secret create-config \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --namespace "${CLUSTER_NAME}" \
  --output=jsonpath={.data.cfg} \
  | base64 -d > "${CLUSTER_NAME}_create_secret.yaml"

    2. 在編輯器中開啟剛建立的 ${CLUSTER_NAME}_create_secret.yaml 檔案，然後從 spec 底下移除 cloudrun 欄位。

    3. 將 ${CLUSTER_NAME}_cluster_create_secret.yaml 檔案 Base64 編碼為 .b64 檔案：

      cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"

    4. 在編輯器中開啟您剛建立的本機 .b64 檔案，然後複製 data.cfg 屬性下方的字串，以用於下一個步驟。

      請務必只複製 cfg 屬性的內容。 舉例來說，請勿加入任何換行符 (\n)。

    5. 執行下列指令，編輯使用者叢集中的密鑰：

      kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \
  --namespace "${CLUSTER_NAME}"

    6. 在開啟的編輯器中，將 data[cfg] 欄位替換為從本機 .b64 檔案複製的字串，然後儲存變更。

    7. 確認變更已部署至使用者叢集，且 cloudrun 屬性已從 create-config 密碼中成功移除：

      kubectl get secret create-config \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --namespace ${CLUSTER_NAME} \
  --output=jsonpath={.data.cfg} \
  | base64 -d

  4. 在使用者叢集中設定 knative-serving 命名空間：

    1. 從 knative-serving 命名空間刪除 cloudrun-operator 運算子：

      kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operator

    2. 修補 knative-serving 命名空間中的 config-network configmap：

      kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'

  5. 從使用者叢集的設定檔 user-config.yaml 中，移除 Google Distributed Cloud 安裝作業的 cloudrun.enabled 設定。

    您必須從 user-config.yaml 檔案中刪除下列屬性：

    cloudRun:
  enabled: true

    將叢集升級至 Anthos 1.8 版時，這項設定變更就會部署完成。

  6. 如果您有多個使用者叢集，必須為每個使用者叢集重複執行「設定每個使用者叢集」一節中的所有步驟。

設定機群元件

  1. 在機群中啟用 Knative serving 元件：

    gcloud container fleet cloudrun enable --project=$PROJECT_ID

    如需詳細資料和其他選項，請參閱 gcloud container fleet cloudrun enable 參考資料。

  2. 選用：確認 Knative serving 功能元件已啟用：

    控制台

    在Google Cloud 控制台中查看 Knative serving 元件是否已啟用：

    前往功能管理工具

    指令列

    查看 appdevexperience 狀態是否為 ENABLED：

    gcloud container fleet features list --project=$PROJECT_ID

    如需詳細資料和其他選項，請參閱 gcloud container fleet features list 參考資料。

    結果：

    NAME               STATE
appdevexperience   ENABLED

  3. 部署 CloudRun 自訂資源，在每個使用者叢集上安裝 VMware 中的 Knative Serving。根據預設，系統會部署 Knative serving 的 latest 版本。

    執行下列 kubectl apply 指令，部署 CloudRun 自訂資源的預設設定：

    cat <<EOF | kubectl apply -f -
apiVersion: operator.run.cloud.google.com/v1alpha1
kind: CloudRun
metadata:
  name: cloud-run
spec:
  metricscollector:
    stackdriver:
      projectid: $PROJECT_ID
      gcpzone: $CLUSTER_LOCATION
      clustername: $CLUSTER_NAME
      secretname: "stackdriver-service-account-key"
      secretkey: "key.json"
EOF

設定 Cloud Service Mesh

為每個使用者叢集設定 Cloud Service Mesh 負載平衡器。

您可以設定新的外部 IP 位址，或重複使用現有的 IP 位址，藉此設定 Cloud Service Mesh 的 Ingress 閘道：

  • 取得新的外部 IP 位址後，請按照 Cloud Service Mesh 說明文件中的步驟設定負載平衡器。

    請注意，這個選項可確保 Knative 服務重新啟動時不會中斷。

  • 替代做法：按照下列步驟，將 Cloud Service Mesh 負載平衡器設定為現有的 IP 位址。

    1. 執行下列指令，將服務的閘道設定為 Cloud Service Mesh：

      export CURRENT_INGRESS_IP=$(kubectl get service --namespace gke-system istio-ingress --output jsonpath='{.spec.loadBalancerIP}')
kubectl patch service --namespace istio-system istio-ingressgateway --patch "{\"spec\":{\"loadBalancerIP\": \"$CURRENT_INGRESS_IP\"}}"
kubectl patch service --namespace gke-system istio-ingress --patch "{\"spec\":{\"loadBalancerIP\": null}}"

    2. 移除目前的 Istio 設定：

      kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"local-gateway.cluster-local-gateway": null}}'
kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"gateway.gke-system-gateway": null}}'

驗證遷移作業

您可以檢查 appdevexperience-operator 是否正常運作，確認 VMware 上的 Knative 服務已成功遷移至機群。

針對每個使用者叢集，執行下列指令：

 kubectl get deployment -n appdevexperience appdevexperience-operator

appdevexperience-operator 運算子 應顯示 1/1 為就緒狀態，例如：

 NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
 appdevexperience-operator   1/1     1            1           1h

如果運算子無法達到就緒狀態，您可以在 Google Cloud 控制台中查看叢集的工作負載頁面，找出資源問題：

前往 Google Kubernetes Engine 工作負載

升級叢集

您已將 VMware 安裝的 Knative serving 遷移至使用機群元件，現在可以將叢集升級至 Anthos 1.8 版。請按照「升級 GKE On-Prem」中的詳細說明操作。

疑難排解

使用者叢集的升級程序無法完成

gke-system 命名空間中的 cluster-local-gateway Pod 可能會導致使用者叢集無法完成升級至 Anthos 1.8 版。現在已不需要 cluster-local-gateway Pod，可以安全地移除。

如要手動輔助升級程序，您可以將部署作業副本縮減至 0，藉此手動移除 cluster-local-gateway Pod。例如：

  1. 縮減 cluster-local-gateway：

    kubectl scale deployment cluster-local-gateway --replicas 0 --namespace gke-system

    系統會移除 gke-system 命名空間中的 cluster-local-gateway Pod，以及 knative-serving 命名空間中的所有工作負載。

  2. 等待升級程序完成。

進一步瞭解如何調度部署作業。