Anthos Service Mesh 1.11 已达到服务终止期限，不再受支持。请参阅从早期版本升级。

查看最新文档或选择其他可用版本：

可用版本

1.20（最新）
1.19
1.18
1.17
1.16
1.15
1.14
1.13
{1.18
{1.12
{1.12
{1.12
{1.12）。{/1.12
{1.13
{1.12
{1.12
{1.12
{1.12
）。{/1.12
{1.12

配置代管式 Anthos Service Mesh

概览

托管式 Anthos Service Mesh 是 Google 托管的控制平面，您只需配置一个可选的数据平面。Google 以向后兼容的方式为您处理可靠性、升级、扩缩和安全性问题。本指南介绍如何在单集群或多集群配置中设置或迁移到代管式 Anthos Service Mesh。

如需了解托管式 Anthos Service Mesh 支持的功能和限制，请参阅托管式 Anthos Service Mesh 支持的功能。

前提条件

首先，本指南假定您已完成以下操作：

Cloud 项目。
Cloud Billing 账号。
安装所需工具中指定的安装脚本、kpt 以及其他工具。

使用要求

一个或多个在受支持的 GKE 版本中具有受支持区域的集群。
您的集群必须启用 Workload Identity。如需了解 gcloud 命令，请参阅启用 Workload Identity。
由 Google 管理的数据平面要求您在部署由 Google 管理的控制平面时启用 Istio 容器网络接口 (CNI) 插件，如后文所述页面。

迁移

只有 1.9+ 版（通过 Mesh CA 安装）支持从集群内控制层面直接迁移/升级到 Google 管理的控制层面。
使用 Istio CA 进行的安装必须先迁移到 1.9+ Mesh CA。
支持间接迁移/升级，这意味着您可以遵循每个版本的标准 Anthos Service Mesh 升级路径，直到通过集群内控制层面达到 Anthos Service Mesh 1.11，然后才能迁移到 Google 管理的控制层面。

限制

我们建议您查看代管式 Anthos Service Mesh 支持的功能和限制列表。请特别注意以下几点：

代管式 Anthos Service Mesh 只能在单个 Google Cloud 项目中使用多个 GKE 集群。
IstioOperator API 不受支持。
代管式数据平面限制：
- 代管式数据平面的此预览版本仅适用于代管式控制层面的新部署。如果您之前部署了代管式控制层面，并且想要部署代管式数据层面，则必须重新运行安装脚本，如应用 Google 管理的控制层面。
- 常规和快速发布渠道均提供托管式日期平面。

启用 Workload Identity

如果未启用 Workload Identity，请参阅在集群上启用 Workload Identity，以查看启用 Workload Identity 所需的 IAM 权限和 gcloud CLI。

下载安装脚本

将安装 Anthos Service Mesh 1.11.8 的最新版脚本下载到当前工作目录中：
```
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.11 > install_asm
```
让该脚本可执行：
```
chmod +x install_asm
```

配置每个集群

请按照以下步骤为网格中的每个集群配置代管式 Anthos Service Mesh。

获取集群凭据

检索相应的凭据。以下命令还将 kubectl 上下文指向目标集群。

gcloud container clusters get-credentials  CLUSTER_NAME \
    --zone LOCATION \
    --project PROJECT_ID

应用 Google 管理的控制层面

为将使用代管式 Anthos Service Mesh 的每个集群运行 install_asm 安装脚本。我们建议您在运行 install_asm 时添加以下两个选项：

--option cni-managed此选项会启用 Istio 容器网络接口 (CNI) 插件。CNI 插件使用 CNCF CNI 接口（而不是具有高权限的 init 容器）配置进出 Sidecar 代理的网络流量重定向。
--enable-registration：此标志会将集群注册到“队列”。

如果您还想部署 Google 管理的数据平面，则必须选择这些选项。如需查看选项的完整列表，请参阅 asmcli 参考页面。

  ./install_asm --mode install --managed \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --enable-registration \
      --option cni-managed

该脚本会将用于配置代管式控制层面和安装 Istio 网关以及 istioctl 工具和示例应用的所有文件下载到指定的 --output_dir。本指南中的步骤假定您从安装目录的根目录运行 istioctl（istioctl 存在于安装目录的 /bin 子目录中）。

如果您在同一集群上重新运行 install_asm，则该命令会覆盖现有的控制层面配置。如果要使用相同的配置，请务必指定相同的选项和标志。

请注意，入站流量网关不会自动使用控制层面进行部署。通过分离入站流量网关和控制层面的部署，您可以更轻松地在生产环境中管理网关。如果集群需要入站网关，请参阅安装 Istio 网关。

应用 Google 管理的数据层面

如果您希望 Google 管理代理的升级，请启用 Google 管理的数据平面。如果启用，Sidecar 代理和注入的网关将与代管式控制层面一起自动升级。

在功能预览中，托管式数据平面通过逐出运行旧版代理的 Pod 来升级代理。系统会按照 Pod 中断预算并控制更改速率按顺序执行逐出。

此托管数据平面预览版不管理以下内容：

未注入的 pod。
使用 istioctl kube-inject 手动注入的 pod。
作业
有状态集
DaemonSet

如果您不想使用代管式数据层面或不想为所有命名空间启用该层面，则应该触发代理重启以从最新的代理映像中受益。控制层面会继续使用现有代理。

快速数据和常规发布渠道均支持代管式数据平面。

如需启用 Google 管理的数据层面，请执行以下操作：

启用数据平面管理：
```
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'
```
或者，您可以为特定 Pod 启用 Google 管理的数据平面，只需使用相同的注解为其添加注解即可。当您为特定 Pod 添加注释时，该 Pod 使用 Google 管理的边车代理，而其余工作负载使用非代管式边车代理。
对您希望代管数据平面的每个命名空间重复上一步骤。

在机群中启用 Anthos Service Mesh：

gcloud alpha container hub mesh enable --project=PROJECT_ID

数据平面控制器最多可能需要十分钟才能准备好管理集群中的代理。运行以下命令来检查状态：

if kubectl get dataplanecontrols -o custom-columns=REV:.spec.revision,STATUS:.status.state | grep rapid | grep -v none > /dev/null; then echo "Managed Data Plane is ready."; else echo "Managed Data Plane is NOT ready."; fi

当数据层面控制器准备就绪后，该命令将输出：Managed Data Plane is ready.

如果数据层面控制器在等待超过 10 分钟后仍未变为就绪状态，请参阅代管式数据层面状态中的问题排查提示。

如果您希望停用 Google 管理的数据层面，并还原为自行管理 Sidecar 代理，请更改注解：

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

安装 Istio Gateway（可选）

Anthos Service Mesh 允许您将网关部署和管理为服务网格的一部分。网关描述了在网格边缘运行的负载均衡器，用于接收传入或传出 HTTP/TCP 连接。网关是 Envoy 代理，可让您精确控制进出网格的流量。

我们建议您为网关创建单独的命名空间，这是最佳做法。请勿将网关部署到 istio-system 命名空间。

您可以按照以下步骤在集群中安装一个或多个 Istio Gateway 以处理典型的入站流量：

选择以下两个选项之一来设置要在后续步骤中部署网关的命名空间。
- 启用用于注入的命名空间：
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite
```
OR
- 仅为网关 pod 启用注入，但不对名称空间中的所有 pod 启用注入。此命令会移除所有注入标签，并且稍后会在 pod 上启用注入：
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev-
```

使用以下最小示例为网关创建 Deployment 和 Service：

kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  type: LoadBalancer
  selector:
    istio: ingressgateway
  ports:
  - port: 80
    name: http
  - port: 443
    name: https
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: asm-managed-rapid # This is required only if the namespace is not labeled.
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: istio-ingressgateway-sds
  namespace: GATEWAY_NAMESPACE
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: istio-ingressgateway-sds
  namespace: GATEWAY_NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: istio-ingressgateway-sds
subjects:
- kind: ServiceAccount
  name: default
EOF

创建部署后，验证新服务是否正常运行：

kubectl get pod,service -n GATEWAY_NAMESPACE

验证类似于以下内容的输出：

NAME                                      READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s

NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

您可以选择让托管数据平面控制器像管理服务一样管理网关的代理。如果您部署了管理的数据平面，并且希望管理网关代理，请按照应用 Google 管理的数据平面中的说明，为网关命名空间添加标签和注释。

如果您选择自行管理网关，则需要在发布新版本的 Anthos Service Mesh 时重启 GATEWAY_NAMESPACE 中的 Pod，以便它们选择新的控制层面配置。在重启 pod 之前，您应使用以下命令中提供的 Metrics Explorer 自定义查询来检查控制层面的版本，从而确认新的控制层面已经发布到您的集群：验证控制层面指标。

配置端点发现（仅适用于多集群安装）

Anthos Service Mesh 代管式控制平面支持单项目、单网络多主实例配置，但控制平面未安装在集群中。

在继续操作之前，您应该已经按照上述步骤中的说明在每个集群上运行安装脚本。不需要指明集群是主要集群，这是默认行为。

对于每个集群，通过为网格中的每个其他集群 i=1..N 运行以下命令一次，启用端点发现：

对于每个集群，请确保 kubectl 配置上下文指向当前集群：
```
export CTX=gke_PROJECT_ID_LOCATION_CLUSTER_NAME
```

通过为网格中的每个其他集群 i=1..N 运行以下命令一次，启用端点发现功能：

export CTX_i=gke_PROJECT_ID_LOCATION_i_CLUSTER_NAME_i

./bin/istioctl x create-remote-secret --context=${CTX_i} --name=CLUSTER_NAME_i | \
  kubectl apply -f - --context=${CTX}

运行以下命令来验证是否已创建 Secret：

kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system

验证预期输出：

NAME                                   TYPE     DATA   AGE
istio-remote-secret-CLUSTER_NAME_i   Opaque   1      44s

如果当前集群添加到现有多集群网格，请通过创建与所有其他集群中的当前集群相对应的 Secret，让所有其他集群发现其端点：
```
./bin/istioctl x create-remote-secret --context=${CTX} --name=CLUSTER_NAME | \
  kubectl apply -f - --context=${CTX_i}
```

此外，您还可以验证另一个集群的 Secret：

kubectl get secret istio-remote-secret-CLUSTER_NAME -n istio-system --context ${CTX_i}

验证预期输出：

NAME                            TYPE     DATA   AGE
istio-remote-secret-CLUSTER_NAME   Opaque   1      44s

如需了解详情以及包含两个集群的示例，请参阅启用端点发现功能。

部署应用

在部署应用之前，请从相应命名空间中移除任何以前的 istio-injection 标签，然后改为设置 istio.io/rev:asm-managed-rapid 标签：

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite

此时，您已成功配置 Anthos Service Mesh 代管式控制层面。现在，您可以部署应用，或者部署 Bookinfo 示例应用。

如果您在多集群设置中部署应用，请在所有集群中复制 Kubernetes 和控制层面配置，除非您计划将特定配置限制为部分集群。应用于特定集群的配置是该集群的真实来源。此外，如果集群还在其他命名空间中通过 Mesh CA 运行 Anthos Service Mesh 1.7、1.8 或更高版本，请验证应用可以与集群内控制层面控制的其他应用进行通信。

验证控制层面指标

您可以在 Metrics Explorer 中查看控制平面和数据平面的版本。

如需验证您的配置是否正常运行，请执行以下操作：

在 Google Cloud 控制台中，查看控制平面指标：

转到 Metrics Explorer
选择您的工作区，并使用以下参数添加自定义查询：
- 资源类型：Kubernetes 容器
- 指标：代理客户端
- 过滤条件：container_name="cr-asm-managed-rapid"
- 分组依据：修订版本标签和 proxy_version 标签
- 聚合器：总和
- 时间段：1 分钟
同时将 Anthos Service Mesh 与 Google 管理的控制平面和集群内控制平面一起运行时，您可以根据指标的容器名称来区分指标。例如，代管式指标具有 container_name="cr-asm-managed"，而非代管式指标的值为 container_name="discovery"。如需同时显示这两项的指标，请移除 container_name="cr-asm-managed" 上的过滤条件。
在 Metrics Explorer 中检查以下字段，验证控制平面版本和代理版本：
- revision 字段指示控制平面版本。
- proxy_version 字段指示 proxy_version。
- value 字段指示连接的代理数量。
如需了解当前渠道到 Anthos Service Mesh 版本的映射，请参阅每个渠道的 Anthos Service Mesh 版本。

将应用迁移到代管式 Anthos Service Mesh

托管式 Anthos Service Mesh 仅支持从使用 Mesh CA 的 Anthos Service Mesh 1.9 迁移。

如需迁移到代管式 Anthos Service Mesh，请执行以下步骤：

按照应用 Google 管理的控制平面部分中的说明运行脚本。

如果您同时部署了 Google 管理的控制层面和数据平面：

启用数据平面管理：

kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'

在机群中启用 Anthos Service Mesh：

gcloud alpha container hub mesh enable --project=PROJECT_ID

将当前命名空间标签替换为 istio.io/rev:asm-managed-rapid 标签：

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid \
    --overwrite

对命名空间中的部署执行滚动升级：

kubectl rollout restart deployment -n NAMESPACE

测试您的应用，验证工作负载是否正常工作。
如果您在其他命名空间中存在工作负载，请对每个命名空间重复上述步骤。
如果您在多集群设置中部署应用，请在所有集群中复制 Kubernetes 和 Istio 配置，除非有合适的配置限制只限于部分集群使用。应用于特定集群的配置是该集群的真实来源。
按照验证控制层面指标中的步骤操作，验证指标是否符合预期。

集群可以混合使用修订版本（例如 Anthos Service Mesh 1.7 和 1.8）以及集群控制层面。您可以结合使用不同的 Anthos Service Mesh 控制层面修订版本来混合使用命名空间。

如果您确定应用按预期运行，则在将所有命名空间切换到集群内控制层面后，可以移除集群内 istiod，或将其另存为备份 - istiod 会自动缩减使用的资源。如需将其移除，请跳至删除旧的控制平面。

如果遇到问题，您可以使用解决代管式控制平面问题中的信息识别并解决问题，并在必要时回滚到先前版本。

删除旧的控制平面

安装并确认所有命名空间都使用 Google 管理的控制平面后，您可以删除旧的控制平面。

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

如果您使用的是 istioctl kube-inject（而不是自动注入），或者您安装了其他网关，请检查控制平面的指标，并验证连接的端点数量是否为零。

回滚

如果您需要回滚到先前的控制平面版本，请执行以下步骤：

更新要用旧版控制平面注入的工作负载：在以下命令中，修订版本值 asm-191-1 仅用作示例。将示例值替换为前面的控制平面的修订版本标签。
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
重启 pod 以触发重新注入，以使代理具有之前的版本：
```
kubectl rollout restart deployment -n NAMESPACE
```

代管式控制平面会自动扩容到零，在不使用时不使用任何资源。更改 Webhook 和预配将会保留，不会影响集群行为。

网关现已设置为 asm-managed 修订版本。如需回滚，请重新运行 Anthos Service Mesh 安装命令，该命令会重新部署指回到集群内控制平面的网关：

kubectl -n istio-system rollout undo deploy istio-ingressgateway

成功时预期下列输出：

deployment.apps/istio-ingressgateway rolled back

将网关迁移到 Google 管理的控制层面

使用文档为新版网关创建 Kubernetes Deployment。您必须使用服务配置中的 selector 字段配置现有的 Kubernetes 网关服务以同时选择旧版本和新版本。
使用这些kubectl 规模，逐步扩充新部署，同时还要缩减旧部署，并检查是否有任何服务中断/停机时间。如果迁移成功，您应该在未出现服务中断的情况下访问零个旧实例。

卸载

Google 管理的控制层面在没有被任何命名空间使用时会自动扩容到零，因此不需要卸载。

问题排查

如需在使用代管式控制平面时识别和解决问题，请参阅解决代管式控制平面问题。

后续步骤

了解发布渠道