将 VMware 上的 Knative serving 升级到舰队

了解如何迁移 Knative serving on VMware 以使用舰队，以便升级到 Anthos 版本 1.8。

现在，Knative serving 是与托管式 Cloud Run 产品分开的体验，并且现在作为集群中的舰队组件提供。将 Knative serving on VMware 功能作为舰队的组件安装后，您可以独立于其他舰队组件管理和升级安装。

概括来讲，如需迁移 Knative serving on VMware 安装以使用舰队，您必须执行以下操作：

  • 配置 Knative serving on VMware 安装以满足舰队要求。
  • 在舰队中启用 Knative serving 功能组件。

请注意，Kubernetes API 服务器在此迁移期间不受影响。

如需详细了解如何在 VMware 上执行新安装 Knative serving，请参阅在 VMware 上安装 Knative serving。

准备工作

您必须满足以下要求：

  • 以下步骤要求您在 GKE Enterprise 中注册 VMware 集群上的 Knative serving：

    转到 GKE Enterprise 集群

    了解如何注册集群。

  • 您在 VMware 上安装的 Knative serving on VMware 运行 Anthos 1.7 或更低版本的集群上。

  • Anthos 1.8 不再支持 Istio。必须在舰队中安装 Cloud Service Mesh 1.18 版，并且必须先配置 Knative serving 的安装，然后才能将该集群升级到版本 1.8。

    如需详细了解如何在 GKE on VMware 上安装，请参阅 Cloud Service Mesh 说明。

    请注意，Cloud Service Mesh 要求集群使用至少具有四个 vCPU 的机器类型，例如 e2-standard-4。如果您需要更改集群的机器类型，请参阅将工作负载迁移到不同的机器类型。

  • 您可以通过以下两种方式将 Knative serving 迁移到 Cloud Service Mesh：

    • 获取将负载均衡器配置为的新外部 IP 地址。

    • 也可以重用现有负载均衡器的 IP 地址。

  • 确保命令行环境已配置并且为最新状态。

迁移到舰队

为了将 Anthos 升级到版本 1.8，您必须先执行以下步骤，以确保现有的 Knative serving on VMware 安装迁移到使用舰队组件。

访问管理员集群

获取管理员集群的 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. 验证在 OnPremUserCluster 中是否设置了 cloudRun：

      $ 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 命令并确认未返回任何配置，验证是否已成功从 OnPremUserCluster 中移除 cloudRun：

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

      您的终端不应收到任何输出。

  3. 更新用户集群的 create-config Secret：

    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. 使用 Base64 将 ${CLUSTER_NAME}_cluster_create_secret.yaml 文件编码为 .b64 文件：

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

    4. 在编辑器中，打开刚创建的本地 .b64 文件，然后从 data.cfg 特性下复制该字符串，供下一步使用。

      您必须确保仅复制 cfg 特性中的内容。例如，请勿包含任何换行符 (\n)。

    5. 运行以下命令，以在用户集群上修改 Secret：

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

    6. 在打开的编辑器中，将 data[cfg] 字段替换为您从本地 .b64 文件中复制的字符串，然后保存更改。

    7. 验证您的更改是否已部署到用户集群，以及 cloudrun 特性是否已成功从 create-config Secret 中移除：

      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. 从 GKE on VMware 安装的用户集群的配置文件 user-config.yaml 中移除 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 组件是否处于已启用状态：

    转到 GKE Enterprise 功能

    命令行

    查看 appdevexperience 状态是否为 ENABLED：

    gcloud container fleet features list --project=$PROJECT_ID

    如需了解详情和其他选项，请参阅 gcloud container flee 功能列表参考文档。

    结果：

    NAME               STATE
appdevexperience   ENABLED

  3. 部署 CloudRun 自定义资源，以在每个用户集群上安装 VMware 上的 Knative serving。默认情况下，系统会部署 latest 版本的 Knative serving。

    运行以下 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 的入站网关：

  • 使用您获取的新外部 IP 地址，您可以按照 Cloud Service Mesh 文档中的步骤配置负载平衡器。

    请注意，此选项可确保您的 Knative serving 服务在不中断的情况下重启。

  • 替代方案：按照以下步骤将 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 是否已启动并运行，以验证 Knative serving on VMware 是否已成功迁移到您的舰队。

对于每个用户集群，运行以下命令：

 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 工作负载

升级集群

现在，您已迁移 Knative serving on VMware 安装以使用舰队组件，接下来您可以将集群升级到 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. 等待升级过程完成。

详细了解如何扩缩部署。