您正在查看旧版 v1.19 Service Mesh 文档。

可用版本

Cloud Service Mesh
1.22 归档
 1.21 归档
 1.20 归档
 1.19 归档
 1.18 归档

此页面由 Cloud Translation API 翻译。

从 Istio on GKE 迁移到 Cloud Service Mesh

本指南介绍了如何使用 Google Kubernetes Engine (Istio on GKE) 1.4 或 1.6 版（Beta 版）将 Google Kubernetes Engine (GKE) 集群升级到代管式 Cloud Service Mesh，其中包含 Google 管理的控制平面和 Cloud Service Mesh 证书授权机构。

前提条件

您必须满足以下前提条件才能完成本指南：

已启用 Istio on GKE 的 GKE 集群。如果您有多个 GKE 集群，请对所有集群执行相同步骤。
Istio on GKE 必须是 1.4 或 1.6 版。
确保您运行的是 GKE 1.17.17-gke.3100+、1.18.16-gke.1600+、1.19.8-gke.1600+ 或更高版本。
GKE 集群必须在这些位置之一运行。
运行此脚本的用户或服务账号需要设置项目中记录的 IAM 权限。
本指南在 Cloud Shell 上进行了测试，因此我们建议您使用 Cloud Shell 执行本指南中的步骤。

目标

在常规渠道部署 Cloud Service Mesh Google 管理的控制平面。本指南针对常规渠道，稳定渠道或快速渠道的说明需要略加修改。如需详细了解发布渠道，请访问此链接。
将 Istio 配置迁移到 Cloud Service Mesh。
配置 Cloud Service Mesh 证书授权机构。
将应用迁移到 Cloud Service Mesh。
将 istio-ingressgateway 从 Istio on GKE 升级到 Cloud Service Mesh。
完成 Cloud Service Mesh 迁移或回滚到 GKE 上的 Istio。

设置环境

如需设置您的环境，请按以下步骤操作：

在 Google Cloud 控制台中，激活 Cloud Shell。

激活 Cloud Shell

在 Google Cloud 控制台页面底部，有一个 Cloud Shell 并显示命令行提示符。Cloud Shell 是与 Google Cloud CLI 和 Google Cloud CLI 以及已为当前项目设置的值。该会话可能需要几秒钟来完成初始化。
注意：该脚本不适用于 macOS。该脚本仅在 Cloud Shell 上经过测试。该脚本需要以下应用（默认情况下，这些应用全部包含在 Cloud Shell 中）：
- gcloud（346.0.0 版和更高版本）
- kubectl（客户端 1.21 和更高版本）
- jq
- sed
- curl
- awk

创建本指南中使用的环境变量：

# Enter your project ID
export PROJECT_ID=PROJECT_ID

# Copy and paste the following
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_1=GKE_CLUSTER_NAME
export CLUSTER_1_LOCATION=GKE_CLUSTER_REGION_OR_ZONE
export SHELL_IP=$(curl ifconfig.me) # This is required for private clusters with `master-authorized-networks` enabled.

创建 WORKDIR 文件夹与本指南关联的所有文件都最终位于 WORKDIR 中，因此您可以在完成后删除 WORKDIR。
```
mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`
```
为本指南创建一个 KUBECONFIG 文件：您还可以使用现有 KUBECONFIG 文件，其中包含要迁移到 Cloud Service Mesh 的 GKE 集群。
```
touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig
```

获取 GKE 集群的凭据，并将上下文存储在变量中：

区域级集群

gcloud container clusters get-credentials ${CLUSTER_1} \
  --zone=${CLUSTER_1_LOCATION}

export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}

区域级集群

gcloud container clusters get-credentials ${CLUSTER_1} \
  --region=${CLUSTER_1_LOCATION}

export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}

集群必须注册到舰队。此步骤可以在安装之前单独完成，也可以在安装过程中通过传递 --fleet-id 标志外加 --enable-all 或 --enable-registration 标志来完成。
项目必须启用服务网格功能。您可以在安装过程中通过传递 --enable-all 或 --enable-registration 标志之一来启用它，也可以在安装之前通过运行以下命令来启用它：
```
  gcloud container hub mesh enable --project=FLEET_PROJECT_ID
```
其中，FLEET_PROJECT_ID 是舰队宿主项目的 ID。

可选的步骤

如果集群是专用集群（启用了 master-authorized-networks），请将 $SHELL_IP 添加到 master-authorized-networks 许可名单。如果您已有集群访问权限，则不需要执行此步骤。

区域级集群

export SHELL_IP=$(curl ifconfig.me)

gcloud container clusters update ${CLUSTER_1} \
    --zone=${CLUSTER_1_LOCATION} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP}/32

区域级集群

export SHELL_IP=$(curl ifconfig.me)

gcloud container clusters update ${CLUSTER_1} \
    --region=${CLUSTER_1_LOCATION} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP}/32

安装 Cloud Service Mesh

在本部分中，您将使用 GKE 集群上的常规渠道的 Google 管理的控制平面来部署 Cloud Service Mesh。此控制平面最初作为第二个（或 Canary 版）控制平面一起部署。

将安装 Cloud Service Mesh 的最新版脚本下载到当前工作目录，并使脚本可执行：
```
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
chmod +x asmcli
```

如需配置 GKE 集群，请运行安装脚本通过常规渠道的 Google 管理的控制平面安装 Cloud Service Mesh：

./asmcli install \
-p ${PROJECT_ID} \
-l ${CLUSTER_1_LOCATION} \
-n ${CLUSTER_1} \
--fleet_id ${FLEET_PROJECT_ID} \
--managed \
--verbose \
--output_dir ${CLUSTER_1} \
--enable-all \
--channel regular

此步骤可能需要几分钟时间才能完成。

验证 Google 管理的控制平面

将 istioctl 复制到 WORKDIR 文件夹：

cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.

在下一部分中，您将下载并运行 migrate_addon 脚本来帮助如何迁移到 Cloud Service Meshistioctl 命令行实用程序需要与 migrate_addon 脚本位于同一文件夹中。您可以使用 WORKDIR 文件夹作为 istioctl 命令行实用程序和 migrate_addon 脚本。

将配置迁移到 Cloud Service Mesh

在本部分中，您将 Istio on GKE 配置迁移到 Cloud Service Mesh。引导式脚本确定可以和不能迁移哪些配置。

下载迁移工具并使其可执行：

curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon
chmod +x ${WORKDIR}/migrate_addon

停用 Galley 验证网络钩子。此步骤将迁移部分 1.4 配置到 Cloud Service Mesh。回答Y针对这两个问题：

${WORKDIR}/migrate_addon -d tmpdir --command disable-galley-webhook

输出内容类似如下：

tmpdir directory not present. Create directory? Continue? [Y/n] Y

Disabling the Istio validation webhook... Continue? [Y/n] Y
Running: kubectl get clusterrole istio-galley-istio-system -n istio-system -o yaml
Running: kubectl patch clusterrole -n istio-system istio-galley-istio-system --type=json -p=[{"op": "replace", "path": "/rules/2/verbs/0", "value": "get"}]
clusterrole.rbac.authorization.k8s.io/istio-galley-istio-system patched
Running: kubectl get ValidatingWebhookConfiguration istio-galley --ignore-not-found
Running: kubectl delete ValidatingWebhookConfiguration istio-galley --ignore-not-found
validatingwebhookconfiguration.admissionregistration.k8s.io "istio-galley" deleted

验证并手动迁移配置。此步骤有助于识别在将工作负载迁移到 Google 管理的控制层面之前需要手动迁移的一些配置。

${WORKDIR}/migrate_addon -d tmpdir --command config-check

输出内容类似如下：

Installing the authentication CR migration tool...
OK

Checking for configurations that will need to be explicitly migrated...
No resources found

迁移自定义配置

在迁移到 Cloud Service Mesh 之前，您可能需要手动迁移自定义配置。上述脚本可识别自定义配置，并输出所需内容的相关信息。这些自定义项如下所示：

Cloud Service Mesh 不支持检测到的自定义 Envoy 过滤条件。请尽可能移除这些项。Google 管理的控制平面目前不支持 Envoy 过滤器。
检测到的自定义插件证书。插件证书不会迁移到 Cloud Service Mesh。如果插件证书与 Istio on GKE 配合使用，则这些证书不使用在工作负载迁移到 Google 管理的控制平面之后。所有工作负载使用由 Google Cloud Service Mesh 证书授权机构签名的证书。Cloud Service Mesh 证书授权机构不支持插件证书。此消息为参考信息，无需执行任何操作。
检测到无法迁移的安全政策。<Error reason>。这通常失败，因为 Alpha 版 AuthZ 政策需要手动迁移。如需了解有关如何迁移政策的更多上下文和信息，请参阅将 Istio 1.4 Alpha 版之前的安全政策迁移到当前 API。如需详细了解错误消息，请参阅 security-policy-migrate。
检测到可能不兼容的 VirtualService 配置。<Specific deprecated config>。您需要更新以下内容VirtualServiceconfiguration：
- 不支持使用 appendHeaders。请改用 spec.http.headers。
- 不需要使用 websocketUpgrade。该功能默认处于启用状态。
- 将字段 abort.percent 替换为 abort.percentage。
检测到无法迁移的 Mixer 资源的自定义安装。需要手动迁移到 telemetryv2。如果除了默认 Istio on GKE 安装之外还配置了自定义 Mixer 政策，则需要手动将这些政策迁移到遥测 v2。如需详细了解如何执行此操作，请参阅自定义 Istio 指标。
部署 <deploymentName> 可以是自定义网关。手动迁移此文件。您需要手动迁移除 istio-ingressgateway（默认安装）以外的所有网关 Deployment。如需了解如何升级 Google 管理的控制层面的网关，请参阅配置 Google 管理的控制层面。

如需迁移配置，请按以下步骤操作：

手动迁移所有自定义配置（列出的最后一个配置除外），然后再继续执行第 2 步。

使用迁移工具迁移可以自动迁移（或忽略）的配置。

${WORKDIR}/migrate_addon -d tmpdir --command migrate-configs

输出类似于以下内容：

Converting authentication CRs...
2021/06/25 20:44:58 found root namespace: istio-system
2021/06/25 20:44:59 SUCCESS converting policy /default
Running: kubectl apply --dry-run=client -f beta-policy.yaml
peerauthentication.security.istio.io/default created (dry run)

Applying converted security policies in tmpdir/beta-policy.yaml... Continue? [Y/n] Y
Running: kubectl apply -f beta-policy.yaml
peerauthentication.security.istio.io/default created
OK

应用 Cloud Service Mesh 证书授权机构根信任。这样，您就可以从当前 Citadel CA 迁移到 Cloud Service Mesh 证书授权机构，而不会造成任何停机应用

${WORKDIR}/migrate_addon -d tmpdir --command configure-mesh-ca

输出类似于以下内容：

Configuring Istio on GKE to trust Anthos Service Mesh... Continue? [Y/n] Y
Running: kubectl get cm -n istio-system istio-asm-managed -oyaml
Running: kubectl -n istio-system apply -f -
secret/meshca-root created
Running: kubectl get cm istio -n istio-system -o yaml
Running: kubectl get cm istio -n istio-system -o yaml
Running: kubectl replace -f -
configmap/istio replaced
Running: kubectl get deploy istio-pilot -n istio-system -o yaml
Running: kubectl patch deploy istio-pilot -n istio-system -p={"spec":{"template":{"spec":{"containers":[{
    "name":"discovery",
    "image":"gcr.io/gke-release/istio/pilot:1.4.10-gke.12",
    "env":[{"name":"PILOT_SKIP_VALIDATE_TRUST_DOMAIN","value":"true"}]
  }]}}}}
deployment.apps/istio-pilot patched
Running: kubectl get deploy istio-citadel -n istio-system -o yaml
Running: kubectl patch deploy istio-citadel -n istio-system -p={"spec":{"template":{"spec":{
    "containers":[{
      "name":"citadel",
      "args": ["--append-dns-names=true", "--grpc-port=8060", "--citadel-storage-namespace=istio-system", "--custom-dns-names=istio-pilot-service-account.istio-system:istio-pilot.istio-system", "--monitoring-port=15014", "--self-signed-ca=true", "--workload-cert-ttl=2160h", "--root-cert=/var/run/root-certs/meshca-root.pem"],
      "volumeMounts": [{"mountPath": "/var/run/root-certs", "name": "meshca-root", "readOnly": true}]
    }],
    "volumes": [{"name": "meshca-root", "secret":{"secretName": "meshca-root"}}]
  }}}}
deployment.apps/istio-citadel patched
OK

Waiting for root certificate to distribute to all pods. This will take a few minutes...
ASM root certificate not distributed to asm-system, trying again later
ASM root certificate not distributed to asm-system, trying again later
ASM root certificate distributed to namespace asm-system
ASM root certificate distributed to namespace default
ASM root certificate distributed to namespace istio-operator
ASM root certificate not distributed to istio-system, trying again later
ASM root certificate not distributed to istio-system, trying again later
ASM root certificate distributed to namespace istio-system
ASM root certificate distributed to namespace kube-node-lease
ASM root certificate distributed to namespace kube-public
ASM root certificate distributed to namespace kube-system
ASM root certificate distributed to namespace online-boutique
Waiting for proxies to pick up the new root certificate...
OK

Configuring Istio Addon 1.6 to trust Anthos Service Mesh...
Running: kubectl get cm -n istio-system env-asm-managed -ojsonpath={.data.TRUST_DOMAIN} --ignore-not-found
Running: kubectl get cm istio-istio-1611 -n istio-system -o yaml
Running: kubectl replace -f -
configmap/istio-istio-1611 replaced
Running: kubectl patch -n istio-system istiooperators.install.istio.io istio-1-6-11-gke-0 --type=merge
istiooperator.install.istio.io/istio-1-6-11-gke-0 patched
Running: kubectl -n istio-system get secret istio-ca-secret -ojsonpath={.data.ca-cert\.pem}
Running: kubectl -n istio-system patch secret istio-ca-secret
secret/istio-ca-secret patched
Running: kubectl patch deploy istiod-istio-1611 -n istio-system
deployment.apps/istiod-istio-1611 patched
Running: kubectl rollout status -w deployment/istiod-istio-1611 -n istio-system
Waiting for deployment "istiod-istio-1611" rollout to finish: 1 old replicas are pending termination...
deployment "istiod-istio-1611" successfully rolled out
Running: kubectl apply -f - -n istio-system
envoyfilter.networking.istio.io/trigger-root-cert created
Waiting for proxies to pick up the new root certificate...
Running: kubectl delete envoyfilter trigger-root-cert -n istio-system
OK

对于 Cloud Service Mesh 根证书，此步骤需要几分钟时间分发到所有命名空间等待脚本完成并显示 OK 消息。

上一步会执行以下操作：

为集群中的所有工作负载安装 Cloud Service Mesh 证书颁发机构信任根。
更改控制层面 Deployment istio-pilot、istiod 和 istio-citadel 的配置。这些更改包括：
- 将映像升级到最新构建。
- 通过设置 PILOT_SKIP_VALIDATE_TRUST_DOMAIN=true 停用 trust-domain 验证。
- 将 Cloud Service Mesh 证书授权机构信任根添加到 istio-citadel，以将 ConfigMap 分发到所有命名空间。
- 将 Cloud Service Mesh 证书授权机构信任根添加到 istio-ca-secret 以分发根证书。
将较旧的配置清单存储在 tmpdir 中。
提供回滚函数的步骤（稍后记录）。

将工作负载迁移到 Cloud Service Mesh

在本部分中，您需要将在 Istio on GKE 上运行的工作负载迁移到 Cloud Service Mesh。迁移后，您需要验证每个 pod 中是否注入了正确的 Sidecar 代理 (Cloud Service Mesh)，并且应用是否按预期运行。

如果要在现有集群上执行此过程，请选择要迁移的命名空间。

将命名空间定义为变量；该命名空间将迁移到 Cloud Service Mesh：
```
export NAMESPACE=NAMESPACE_NAME
```
如需将工作负载迁移到 Cloud Service Mesh，您必须为 Cloud Service Mesh 重新添加命名空间。为命名空间添加标签可允许 Cloud Service Mesh 自动将 Sidecar 注入所有工作负载。如需为命名空间添加标签，请运行以下命令，将标签设置为 asm-managed：
```
kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwrite
```

对命名空间中的所有 Deployment 执行滚动重启：

kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}

输出内容类似如下：

deployment.apps/deploymentName1 restarted
deployment.apps/deploymentName2 restarted
...

确保所有 pod 都重启并为每个 pod 运行两个容器：

kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods

输出内容类似如下：

NAME                        READY   STATUS    RESTARTS   AGE
deploymentName1-PodName     2/2     Running   0          101s
deploymentName2-PodName     2/2     Running   2          100s
...

验证此步骤的好方法是查看 Pod 的 AGE。请确保该值很短，例如几分钟。

从命名空间中的任何 Deployment 的任何一个 Pod 检查 Sidecar Envoy 代理版本，以确认您现已部署 Cloud Service Mesh Envoy 代理：

export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE
kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'

输出类似于以下内容：

"gcr.io/gke-release/asm/proxyv2:1.11.5-asm.3"
"appContainerImage"

重启后验证并验证您的应用。

kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

（可选）如果您希望 Google 管理代理的升级，请启用 Google 管理的数据平面

查看迁移状态

运行以下命令查看迁移的状态：

kubectl get cm/asm-addon-migration-state -n istio-system -ojsonpath={.data}

输出指示迁移是已完成、待处理还是已失败：

{"migrationStatus":"SUCCESS"}

{"migrationStatus":"PENDING"}

{"migrationStatus":"MIGRATION_CONFIG_ERROR"}

{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}

如果 migrationStatus 输出 SUCCESS，则表示控制平面已成功升级到 Cloud Service Mesh。如需手动更新数据平面，请完成迁移工作负载中的步骤。

如果 migrationStatus 输出除 SUCCESS 以外的任何状态，您可以选择执行以下任一操作：

如果迁移错误不会影响现有的 Istio on GKE 工作负载，则无需执行任何额外操作。否则，请根据需要回滚。
如果 migrationStatus 显示 MIGRATION_CONFIG_ERROR，请更新集群中的自定义配置并重新手动运行迁移。

您可以在成功迁移后在 Metrics Explorer 中查看控制平面指标，请参阅 verify_control_plane_metrics

访问 Cloud Service Mesh 信息中心

在本部分中，您将前往 Cloud Service Mesh 信息中心，表示您正在接收所有服务的黄金信号。您还应能够查看应用拓扑。

在 Google Cloud 控制台中，前往 Cloud Service Mesh 页面。

转到 Cloud Service Mesh
您应该能够查看 Service 的指标和拓扑。

如需详细了解 Cloud Service Mesh 信息中心，请参阅在 Google Cloud 控制台中探索 Cloud Service Mesh。

成功完成迁移

在本部分中，您将完成 Istio on GKE， Cloud Service Mesh 迁移。在继续本部分之前，请确保您要继续使用 Cloud Service Mesh。本部分还可帮助您清理 Istio on GKE 工件。如果要回滚到 Istio on GKE，请继续阅读下一部分。

将 istio-ingressgateway（GKE 上的标准 Istio 的一部分）替换为 Google 管理的控制层面版本控制网关：

${WORKDIR}/migrate_addon -d tmpdir --command replace-gateway

输出内容类似如下：

Replacing the ingress gateway with an Anthos Service Mesh gateway... Continue? [Y/n] Y
Running: kubectl label namespace istio-system istio-injection- istio.io/rev- --overwrite
label "istio.io/rev" not found.
namespace/istio-system labeled
Running: kubectl apply -f -
serviceaccount/asm-ingressgateway created
deployment.apps/asm-ingressgateway created
role.rbac.authorization.k8s.io/asm-ingressgateway created
rolebinding.rbac.authorization.k8s.io/asm-ingressgateway created
Running: kubectl wait --for=condition=available --timeout=600s deployment/asm-ingressgateway -n istio-system
deployment.apps/asm-ingressgateway condition met

Scaling the Istio ingress gateway to zero replicas... Continue? [Y/n] Y
Running: kubectl -n istio-system patch hpa istio-ingressgateway --patch {"spec":{"minReplicas":1}}
horizontalpodautoscaler.autoscaling/istio-ingressgateway patched (no change)
Running: kubectl -n istio-system scale deployment istio-ingressgateway --replicas=0
deployment.apps/istio-ingressgateway scaled
OK

重新配置网络钩子以使用 Google 管理的控制平面：所有工作负载首先使用 Google 管理的控制平面：

${WORKDIR}/migrate_addon -d tmpdir --command replace-webhook

输出类似于以下内容：

Configuring sidecar injection to use Anthos Service Mesh by default... Continue? [Y/n] Y
Running: kubectl patch mutatingwebhookconfigurations istio-sidecar-injector --type=json -p=[{"op": "replace", "path": "/webhooks"}]
mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector patched
Revision tag "default" created, referencing control plane revision "asm-managed". To enable injection using this
revision tag, use 'kubectl label namespace <NAMESPACE> istio.io/rev=default'
OK

使用 Cloud Service Mesh 标签重新标记所有命名空间，并执行所有工作负载的滚动重启，使其在 Google 管理的控制平面上：
```
export NAMESPACE=NAMESPACE_NAME \
    kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE}
    istio.io/rev=asm-managed istio-injection- --overwrite`

    kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n
${NAMESPACE}
```
您可以忽略输出中的 "istio-injection not found" 消息。这意味着命名空间之前 istio-injection 标签，在新的安装 Cloud Service Mesh 或新部署。如果命名空间同时具有 istio-injection 和修订版本标签，自动注入将失败，因此 Istio on GKE 文档中的所有 kubectl label 命令都包含移除 istio-injection 标签。

通过运行以下命令完成迁移：

${WORKDIR}/migrate_addon -d tmpdir --command write-marker

输出内容类似如下：

Current migration state: SUCCESS
Running: kubectl apply -f -
configmap/asm-addon-migration-state created
OK

通过运行以下命令停用 Istio on GKE：

区域级集群

gcloud beta container clusters update ${CLUSTER_1} \
    --project=$PROJECT_ID \
    --zone=${CLUSTER_1_LOCATION} \
    --update-addons=Istio=DISABLED

区域级集群

gcloud beta container clusters update ${CLUSTER_1} \
    --project=$PROJECT_ID \
    --region=${CLUSTER_1_LOCATION} \
    --update-addons=Istio=DISABLED

通过运行以下命令清理配置：

${WORKDIR}/migrate_addon -d tmpdir --command cleanup

输出内容类似如下：

Cleaning up old resources...
Running: kubectl get cm -n istio-system asm-addon-migration-state -ojsonpath={.data.migrationStatus}
Will delete IstioOperator/istio-1-6-11-gke-0.istio-system
Will delete ServiceAccount/istio-citadel-service-account.istio-system
...
Will delete DestinationRule/istio-policy.istio-system
Will delete DestinationRule/istio-telemetry.istio-system
Will delete Secret/istio-ca-secret.istio-system

Deleting resources previously listed... Continue? [Y/n] Y
Running: kubectl delete IstioOperator istio-1-6-11-gke-0 -n istio-system --ignore-not-found
istiooperator.install.istio.io "istio-1-6-11-gke-0" deleted
Running: kubectl delete ServiceAccount istio-citadel-service-account -n istio-system --ignore-not-found
serviceaccount "istio-citadel-service-account" deleted-ingressgateway -n istio-system --ignore-not-found
...
Running: kubectl delete Secret istio-ca-secret -n istio-system --ignore-not-found
secret "istio-ca-secret" deleted
Running: kubectl delete -n istio-system jobs -lk8s-app=istio,app=security
job.batch "istio-security-post-install-1.4.10-gke.8" deleted

确保已成功从集群中移除 Istio on GKE 部署和服务：

kubectl --context=${CLUSTER_1_CTX} -n istio-system get deployments,services

输出类似于以下内容：

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/asm-ingressgateway   1/1     1            1           10m

NAME                           TYPE           CLUSTER-IP    EXTERNAL-IP      AGE   PORT(S)
service/istio-ingressgateway   LoadBalancer   10.64.5.208   34.139.100.237   95m   15020:31959/TCP,80:30971/TCP,443:31688/TCP,31400:31664/TCP,15029:32493/TCP,15030:31722/TCP,15031:30198/TCP,15032:31910/TCP,15443:31222/TCP

您只能看到 Cloud Service Mesh 入站流量网关 Service 和 Deployment。

恭喜！您已成功借助 Google 管理的控制平面和 Cloud Service Mesh 证书授权机构，在不发生任何应用停机的情况下从 Istio on GKE 迁移到 Cloud Service Mesh。

回滚更改

在本部分中，如果您不想继续使用 Cloud Service Mesh，可以回滚 Cloud Service Mesh 更改。完成本部分后，您的工作负载会移回 Istio on GKE。

回滚变更网络钩子更改：

${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhook

通过运行以下命令，为命名空间重新添加标签以使用 Istio on GKE Sidecar 注入而不是 Cloud Service Mesh：

对于具有 1.4 版工作负载的命名空间：

export NAMESPACE=NAMESPACE_NAME
kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite

对于具有 1.6 版工作负载的命名空间：

export NAMESPACE=NAMESPACE_NAME
kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=istio-1611 --overwrite

对命名空间中的所有 Deployment 执行滚动重启：

kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}

等待几分钟，并确保所有 Pod 都在运行：

kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods

输出内容类似如下：

NAME                       READY   STATUS    RESTARTS   AGE
deploymentName1-PodName    2/2     Running   0          101s
deploymentName2-PodName    2/2     Running   2          100s
...

从任一 Pod 验证 Sidecar Envoy 代理版本，以确认您部署了 Istio on GKE v1.4 Envoy 代理：

export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE
kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'

输出类似于以下内容：

"gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
"appContainerImage"

或

"gke.gcr.io/istio/proxyv2:1.6.14-gke.4"
"appContainerImage"

重启后验证并验证您的应用。

回滚 Cloud Service Mesh 证书授权机构更改：

${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-ca

重新启用 Istio Galley 网络钩子：

${WORKDIR}/migrate_addon -d tmpdir --command enable-galley-webhook

您已成功回滚对 Istio on GKE 的更改。

部署 Online Boutique

在本部分中，您需要将名为 Online Boutique 的基于微服务的示例应用部署到 GKE 集群。Online Boutique 部署在启用了 Istio 的命名空间中。您需要验证应用是否正常工作，以及 Istio on GKE 是否正在向每个 Pod 注入 Sidecar 代理。

如果您已有具有应用的现有集群，则可以跳过创建新命名空间和部署 Online Boutique。您可以按照相同的流程所有命名空间中将工作负载迁移到 Cloud Service Mesh 部分。

将 Online Boutique 部署到 GKE 集群：

kpt pkg get \
https://github.com/GoogleCloudPlatform/microservices-demo.git/release \
online-boutique

kubectl --context=${CLUSTER_1_CTX} create namespace online-boutique
kubectl --context=${CLUSTER_1_CTX} label namespace online-boutique istio-injection=enabled

kubectl --context=${CLUSTER_1_CTX} -n online-boutique apply -f online-boutique

等待所有 Deployment 准备就绪：

kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment recommendationservice

确保每个 Pod 有两个容器：应用容器和 Istio on GKE 自动注入 Pod 的 Istio Sidecar 代理：

kubectl --context=${CLUSTER_1_CTX} -n online-boutique get pods

输出内容类似如下：

NAME                                     READY   STATUS    RESTARTS   AGE
adservice-7cbc9bd9-t92k4                 2/2     Running   0          3m21s
cartservice-d7db78c66-5qfmt              2/2     Running   1          3m23s
checkoutservice-784bfc794f-j8rl5         2/2     Running   0          3m26s
currencyservice-5898885559-lkwg4         2/2     Running   0          3m23s
emailservice-6bd8b47657-llvgv            2/2     Running   0          3m27s
frontend-764c5c755f-9wf97                2/2     Running   0          3m25s
loadgenerator-84cbcd768c-5pdbr           2/2     Running   3          3m23s
paymentservice-6c676df669-s779c          2/2     Running   0          3m25s
productcatalogservice-7fcf4f8cc-hvf5x    2/2     Running   0          3m24s
recommendationservice-79f5f4bbf5-6st24   2/2     Running   0          3m26s
redis-cart-74594bd569-pfhkz              2/2     Running   0          3m22s
shippingservice-b5879cdbf-5z7m5          2/2     Running   0          3m22s

您还可以从任一 Pod 中查看 Sidecar Envoy 代理版本，以确认您部署了 Istio on GKE v1.4 Envoy 代理：

export FRONTEND_POD=$(kubectl get pod -n online-boutique -l app=frontend --context=${CLUSTER_1_CTX} -o jsonpath='{.items[0].metadata.name}')
kubectl --context=${CLUSTER_1_CTX} get pods ${FRONTEND_POD} -n online-boutique -o json | jq '.status.containerStatuses[].image'

输出内容类似如下：

"gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
"gcr.io/google-samples/microservices-demo/frontend:v0.3.4"

通过导航到 istio-ingressgateway Service IP 地址的 IP 地址来访问应用：

kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

常见问题解答

这一部分的常见问题及相关解答从 GKE 上的 Istio 迁移到 Cloud Service Mesh

为什么我要从 GKE 上的 Istio 迁移到 Cloud Service Mesh？

Google Kubernetes Engine 上的 Istio 是一项测试版功能，用于在 Google Kubernetes Engine (GKE) 集群上部署由 Google 管理的 Istio。Istio on GKE 部署了不受支持的版本（Istio 1.4 版）。为了向您提供最新的服务网格功能和支持的服务网格实现，我们正在将所有 Istio on GKE 用户升级到 Cloud Service Mesh。

Cloud Service Mesh 是 Google 支持的代管式服务网格产品由 Istio API 提供支持。Cloud Service Mesh 与 Istio 的关系类似于 Google Kubernetes Engine (GKE) 与 Kubernetes 的关系。Cloud Service Mesh 基于 Istio API，因此您可以迁移到 Cloud Shell 时 Cloud Service Mesh。此外，不存在专有供应商锁定。

Cloud Service Mesh 具有以下优势：

Google 管理和 Google 支持的服务网格。
无供应商锁定的 Istio API。
开箱即用的遥测信息中心和 SLO 管理功能，无需管理其他第三方解决方案。
Google 托管的证书授权机构选项。
与 Google Cloud 网络和 Identity-Aware Proxy (IAP) 集成。
混合云和多云平台支持。

如需详细了解 Cloud Service Mesh 的特性和功能，请参阅由 Google 管理的控制平面支持的功能。

迁移是否会导致停机？

迁移脚本旨在避免停机。脚本会安装 Cloud Service Mesh Canary 控制平面现有的 Istio 控制平面istio-ingressgateway 已就地升级。然后为已启用 Istio 的命名空间重新添加标签，搭配使用 Cloud Service Mesh 和 Cloud Service Mesh 证书授权机构。

确保您已经 PodDisruptionBudgets 避免在应用运行时避免任何应用停机虽然您可以避免停机，但如果您自行执行此迁移，我们建议您在计划维护期执行此迁移。Google 驱动的迁移在 GKE 维护期执行。确保您的 GKE 集群已配置维护期。

使用 Cloud Service Mesh 需要付费吗？

您可以通过以下两种方法在 GKE 上使用 Cloud Service Mesh：

如果您是 GKE Enterprise 订阅者，则 Cloud Service Mesh 包含在您的 GKE Enterprise 订阅中。
如果您不是 GKE Enterprise 订阅者，则可以使用 Cloud Service Mesh 作为 GKE 上的独立产品（ Google Cloud）。如需了解详情，请参阅 Cloud Service Mesh 价格详情。

是否有任何最新版本或 Cloud Service Mesh 不支持的功能或配置？

该脚本会检查所有 Istio 配置并将其迁移到最新配置 Cloud Service Mesh 版本。某些配置可能需要执行其他步骤，以便从 Istio 1.4 版迁移到 Cloud Service Mesh 1.10 版。该脚本会执行配置检查，并在任何配置需要其他步骤时通知您。

迁移是否会更改我当前的 Istio 配置？

不会，您的 Istio 配置可以在 Cloud Service Mesh 中使用，无需进行任何更改。

迁移到 Cloud Service Mesh 后，我可以迁移回 Istio 吗？

是的，Cloud Service Mesh 没有使用承诺。您可以随时卸载 Cloud Service Mesh 并重新安装 Istio。

如果迁移失败，是否可以回滚？

可以，该脚本可让您回滚到先前的 Istio on GKE 版本。

我可以使用此脚本迁移哪个 Istio 版本？

该脚本可帮助您从 Istio on GKE 1.4 版迁移到 Cloud Service Mesh 1.10 版。脚本会在迁移前阶段验证您的 Istio 版本，并告知您 Istio 版本是否可以迁移。

如何获取关于此次迁移的更多帮助？

我们的支持团队很乐意提供帮助。您可以打开一个支持请求 Google Cloud 控制台如需了解详情，请参阅管理支持请求。

如果我不迁移到 Cloud Service Mesh，会怎么样？

您的 Istio 组件可以继续运行，但 Google 不再管理您的 Istio 安装。您将不再收到自动更新，也不能保证安装作为 Kubernetes 集群版本更新。

如需了解详情，请参阅 Istio 支持。