版本 1.10

配置 Google 管理的控制层面

概览

Anthos Service Mesh Google 管理的控制层面是 Google Cloud 代管式服务,您只需要进行配置,而 Google 会以向后兼容的方式为您处理其可靠性、升级、扩缩和安全性。本指南介绍如何在单集群或多集群配置中设置应用或将应用迁移到 Google 管理的控制层面。

您可以为单个 Google Cloud 项目中的多个 GKE 集群使用单个 Google 管理的控制层面。

如需了解 Anthos Service Mesh 代管式控制层面支持的功能和限制,请参阅 Anthos Service Mesh Google 管理的控制层面功能

前提条件

本指南假定您具备:

如果未启用 Workload Identity,可以使用以下命令启用它:

gcloud container clusters update CLUSTER_NAME \
    --zone LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog

下载安装脚本

  1. 将安装 Anthos Service Mesh 1.10.4 的最新版脚本下载到当前工作目录中:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.10 > install_asm
    
  2. 将文件的 SHA-256 下载到当前工作目录:

    curl https://storage.googleapis.com/csm-artifacts/asm/ > install_asm.sha256
    
  3. 在这两个文件位于同一目录的情况下,验证下载:

    sha256sum -c --ignore-missing install_asm.sha256
    

    如果验证成功,则该命令会输出 install_asm: OK

    为了确保兼容性,install_asm.sha256 文件包含两次校验和,以允许将脚本的任何版本重命名为 install_asm。如果出现 --ignore-missing 不存在的错误,请重新运行上一个命令,但不使用 --ignore-missing 标志。

  4. 让该脚本可执行:

    chmod +x install_asm
    

配置每个集群

请按照以下步骤为网格中的每个集群配置 Google 管理的控制层面。

获取集群凭据

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

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

应用 Google 管理的控制层面

为将使用 Google 管理的控制层面的每个集群运行安装脚本:

如果您不需要 Istio 容器网络接口 (CNI),请忽略 install_asm 命令上的 --option cni-managed 标志,如以下示例所示。CNI 可供 Google 管理的控制层面使用 CNCF CNI 接口(而不是使用高权限 init 容器)配置 Istio 拦截和低层级网络。

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

该脚本会将用于配置代管式控制层面和安装 Istio 网关以及 Istioctl 工具和示例应用的所有文件下载到指定的 --output_dir

安装 Istio Gateway(可选)

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

  1. 选择以下两个选项之一来设置要在后续步骤中部署网关的命名空间。

    • 启用用于注入的命名空间:
      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-
      
  2. 使用以下最小示例为网关创建 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
    
  3. 创建部署后,验证新服务是否正常运行:

    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

配置端点发现(仅适用于多集群安装)

Anthos Service Mesh 代管式控制层面支持单项目、单网络多主实例配置,但控制层面未安装在集群中。多主配置意味着,每个集群配置了对所有其他集群的 Secret,从而使每个集群能够发现所有其他集群的端点。

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

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

  1. 对于每个集群,请确保 kubectl 配置上下文指向当前集群:

    export CTX=gke_PROJECT_ID_LOCATION_CLUSTER_NAME
    
  2. 通过为网格中的每个其他集群 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}
    
  3. 运行以下命令来验证是否已创建 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
    
  4. 如果当前集群添加到现有多集群网格,请通过创建与所有其他集群中的当前集群相对应的 Secret,让所有其他集群发现其端点:

    ./bin/istioctl x create-remote-secret --context=${CTX} --name=CLUSTER_NAME | \
      kubectl apply -f - --context=${CTX_i}
    
  5. 此外,您还可以验证另一个集群的 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 或更高版本,请验证应用可以与集群内控制层面控制的其他应用进行通信。

验证控制层面指标

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

  1. 在 Cloud Console 中,查看控制层面指标:

    转到 Metrics Explorer

  2. 选择您的工作区,并使用以下参数添加自定义查询:

    • 资源类型: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" 上的过滤条件。

  3. 在 Metrics Explorer 中检查以下字段,验证控制层面版本和代理版本:

    • revision 字段指示控制层面版本。
    • proxy_version 字段指示 proxy_version
    • value 字段指示连接的代理数量。

将应用迁移到 Google 管理的控制层面

Anthos Service Mesh Google 管理的控制层面仅支持从使用 Mesh CA 的 Anthos Service Mesh 1.9 进行迁移。

如需迁移到 Google 管理的控制层面,请执行以下步骤:

  1. 按照安装控制层面部分中的说明运行脚本。

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

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid \
        --overwrite
    
  3. 对命名空间中的部署执行滚动升级:

    kubectl rollout restart deployment -n NAMESPACE
    
  4. 测试您的应用,验证工作负载是否正常工作。

  5. 如果您在其他命名空间中存在工作负载,请对每个命名空间重复上述步骤。

  6. 如果您在多集群设置中部署应用,请在所有集群中复制 Kubernetes 和 Istio 配置,除非有合适的配置限制只限于部分集群使用。应用于特定集群的配置是该集群的真实来源。

  7. 按照验证控制层面指标中的步骤操作,验证指标是否符合预期。

集群可以混合使用修订版本(例如 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(而不是自动注入),或者您安装了其他网关,请检查控制层面的指标,并验证连接的端点数量是否为零。

回滚

如果您需要回滚到先前的控制层面版本,请执行以下步骤:

  1. 更新要用旧版控制层面注入的工作负载:在以下命令中,修订版本值 asm-191-1 仅用作示例。将示例值替换为前面的控制层面的修订版本标签。

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
    
  2. 重启 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 管理的控制层面

  1. 使用文档为新版网关创建 Kubernetes Deployment。您必须使用服务配置中的 selector 字段配置现有的 Kubernetes 网关服务以同时选择旧版本和新版本。

  2. 使用这些kubectl 规模,逐步扩充新部署,同时还要缩减旧部署,并检查是否有任何服务中断/停机时间。如果迁移成功,您应该在未出现服务中断的情况下访问零个旧实例。

卸载

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

问题排查

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

后续步骤