了解如何迁移 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。
准备工作
您必须满足以下要求:
以下步骤要求将您的 Knative serving on VMware 集群注册到舰队,并显示在 Google Cloud 控制台中:
您安装 Knative serving on VMware 集群运行 Anthos 1.7 或更低版本。
Anthos 1.8 不再支持 Istio。Cloud Service Mesh 版本 您的舰队中必须安装 1.18 版, 您必须先配置 Knative serving,然后才能将该集群升级到 版本:1.8.
请参阅 Cloud Service Mesh 说明,详细了解 在 Google Distributed Cloud 上安装。
请注意,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 文件的路径和文件名。
配置每个用户集群
为用户集群创建以下本地环境变量:
使用用户集群的 kubeconfig 文件的路径创建
USER_KUBECONFIG
环境变量:export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
将 [USER_CLUSTER_KUBECONFIG] 替换为用户集群的 kubeconfig 文件的路径和文件名。
为以下配置创建环境变量:
- 您的 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']}")
从用户集群的
OnPremUserCluster
自定义资源中移除cloudrun
配置:验证在
OnPremUserCluster
中是否设置了cloudRun
:$ kubectl get onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --output=jsonpath="{.spec.cloudRun}"
结果:
{"enabled":true}
从
OnPremUserCluster
中移除cloudRun
:kubectl patch onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --type="merge" \ --patch '{"spec": {"cloudRun": null}}'
通过运行同一
get
命令并确认未返回任何配置,验证是否已成功从OnPremUserCluster
中移除cloudRun
:kubectl get onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --output=jsonpath="{.spec.cloudRun}"
您的终端不应收到任何输出。
更新用户集群的 create-config Secret:
创建 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"
打开刚刚在编辑器中创建的
${CLUSTER_NAME}_create_secret.yaml
文件,然后从spec
下移除cloudrun
字段。使用 Base64 将
${CLUSTER_NAME}_cluster_create_secret.yaml
文件编码为.b64
文件:cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"
在编辑器中,打开刚创建的本地
.b64
文件,然后从data.cfg
特性下复制该字符串,供下一步使用。您必须确保仅复制
cfg
特性中的内容。例如,请勿包含任何换行符 (\n
)。运行以下命令 修改密钥 在您的用户集群上执行以下操作:
kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace "${CLUSTER_NAME}"
在打开的编辑器中,将
data[cfg]
字段替换为您从本地.b64
文件中复制的字符串,然后保存更改。验证您的更改是否已部署到用户集群,以及
cloudrun
特性是否已成功从create-config
Secret 中移除:kubectl get secret create-config \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace ${CLUSTER_NAME} \ --output=jsonpath={.data.cfg} \ | base64 -d
在用户集群中配置
knative-serving
命名空间:从
knative-serving
命名空间中删除cloudrun-operator
运算符:kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operator
在
knative-serving
命名空间中修补config-network
configmap:kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'
从用户集群中移除
cloudrun.enabled
配置 配置文件user-config.yaml
Google Distributed Cloud 安装的工作流。必须从
user-config.yaml
文件中删除以下属性:cloudRun: enabled: true
当您将集群升级到 Anthos 1.8 版时,将部署此配置更改。
如果您有多个用户集群,则必须为每个用户集群重复执行此配置每个用户集群部分中的所有步骤。
配置舰队组件
在舰队中启用 Knative serving 组件:
gcloud container fleet cloudrun enable --project=$PROJECT_ID
如需了解详情和其他选项,请参阅 gcloud container fleet cloudrun enable 参考文档。
可选:验证 Knative serving 功能组件是否 已启用:
控制台
在 Google Cloud 控制台:
命令行
查看
appdevexperience
状态是否为ENABLED
:gcloud container fleet features list --project=$PROJECT_ID
如需了解详情和其他选项,请参阅 gcloud container flee 功能列表参考文档。
结果:
NAME STATE appdevexperience ENABLED
部署要安装的
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 负载均衡器。
您可以通过以下任一方式配置 Cloud Service Mesh 的入站网关 配置新的外部 IP 地址或重复使用现有 IP 地址:
使用您获取的新外部 IP 地址,配置负载 创建负载平衡器 Cloud Service Mesh 文档。
请注意,此选项可确保您的 Knative serving 服务 无中断地重启。
替代方案:按照以下步骤配置 Cloud Service Mesh 您的现有 IP 地址
运行以下命令,将您的服务网关配置为 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}}"
移除当前的 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。例如:对
cluster-local-gateway
进行纵向缩容:kubectl scale deployment cluster-local-gateway --replicas 0 --namespace gke-system
移除了
gke-system
命名空间中的cluster-local-gateway
pod 以及knative-serving
命名空间中的所有工作负载。等待升级过程完成。