将 Knative serving on VMware 升级到舰队

了解如何将 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 服务器在此迁移期间不受影响。

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

准备工作

您必须满足以下要求：

  • 以下步骤要求 Knative serving on VMware cluster 集群注册到舰队，并显示在 Google Cloud 控制台中：

    转到 GKE 集群

  • Knative serving on VMware 安装位于运行 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 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. 从 Google Distributed Cloud 安装的用户集群配置文件 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 组件：

    前往 Feature Manager

    命令行

    查看 appdevexperience 状态是否为 ENABLED：

    gcloud container fleet features list --project=$PROJECT_ID

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

    结果：

    NAME               STATE
appdevexperience   ENABLED

  3. 部署 CloudRun 自定义资源以在每个用户集群上安装 Knative serving on VMware。默认情况下，系统会部署 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 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. 等待升级过程完成。

详细了解如何扩缩部署。