从集群内规范化服务控制器迁移到代管式规范化服务控制器

注意:Cloud Service Mesh 1.6.8 及更高版本会自动支持规范化服务。

本指南介绍了从集群内规范化服务控制器迁移到托管式规范化服务控制器的步骤。

集群内规范化服务控制器已被弃用,不会再收到更新。虽然集群内控制器的现有部署将继续运行,但我们强烈建议迁移到托管的 Canonical Service Controller,以确保与未来版本兼容、能够使用最新功能并获得持续支持。从版本 1.25 开始,使用 asmcli 安装的所有 Cloud Service Mesh 都将预配代管式规范化服务控制器。

1. 启用 Cloud Service Mesh 舰队功能

代管式规范化服务控制器是 Cloud Service Mesh 舰队功能的一部分,您可以使用以下命令启用该功能:

  gcloud container fleet mesh enable --project FLEET_PROJECT_ID
  

FLEET_PROJECT_ID 替换为您的舰队宿主项目的 ID。通常,FLEET_PROJECT_ID 与项目名称相同。

请注意,如果您计划注册多个集群,则启用 Cloud Service Mesh 是在舰队级层进行的,因此您只需运行一次此命令。

向 Cloud Service Mesh 服务账号授予权限

如果集群的项目与舰队宿主项目不同,则您必须允许舰队项目中的 Cloud Service Mesh 服务账号访问集群项目。

您只需为每个集群项目执行一次此操作。如果您之前为此集群项目和舰队项目的组合配置了代管式 Cloud Service Mesh,则这些更改已应用生效,您无需再运行以下命令。

向舰队项目中的服务账号授予访问集群项目的权限:

  gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent

CLUSTER_PROJECT_ID 替换为集群的项目 ID,将 FLEET_PROJECT_NUMBER 替换为车队的项目编号。

如需确定车队的项目编号,请参阅 Google Cloud 项目文档中的说明。

2. 停用集群内规范化服务控制器

代管式规范化服务控制器无法与集群内规范化服务控制器一起运行。因此,您必须停用集群内控制器。

  1. 检查集群内控制器:验证集群内规范化控制器是否存在。

    kubectl get deployment canonical-service-controller-manager -n asm-system
    
  2. 删除集群内控制器:如果找到该部署,您可以通过运行以下命令将其(以及整个 asm-system 命名空间)删除:

    kubectl delete namespace asm-system
    

3. 验证代管式规范化控制器是否正常运行

代管式规范化服务控制器会在功能状态中报告其状态,因此您可以通过检查功能状态来确认安装是否正常运行:

  1. 检查功能状态:使用以下命令检索功能状态:

    gcloud container fleet mesh describe --project FLEET_PROJECT_ID
    
  2. 验证状态:检查集群的状态,并验证 state.code 是否为 OK

    • 重要提示:状态最长可能需要 15 分钟才能转换为 OK。请等待片刻,然后重新运行该命令。
    • 仅当 state.codeOK 时,才继续执行下一步。
    • 如果 state.code 在 15 分钟后未变为 OK,请参阅解决代管式规范化服务控制器问题,获取问题排查指南。

    输出示例:

    membershipStates:
        projects/<project-number>/locations/<location>/memberships/<membership-name>:
          state:
            code: OK
            description:
              Revision(s) ready for use: istiod-asm-183-2.
    
  3. 检查代管式规范化控制器是否正常运行:通过部署注入了边车的 Pod 来验证代管式规范化控制器是否正常运行,并检查控制器是否会自动创建相应的规范化服务。

    1. 创建一个启用了自动 Sidecar 注入的命名空间:

      kubectl create namespace NAMESPACE_NAME
      

      按照启用自动 Sidecar 注入部分中的说明,在新创建的命名空间中启用自动 Sidecar 注入。

    2. 创建一个名为 simple_pod.yaml 的 YAML 文件,其中包含以下内容:

          apiVersion: v1
          kind: Pod
          metadata:
            name: simple-pod
            labels:
              app: my-app
          spec:
            containers:
            - name: my-container
              image: nginx:latest
              ports:
              - containerPort: 80
      

      app 标签决定了规范化服务的名称。如需了解详情,请参阅定义规范化服务

    3. 使用以下命令部署 pod。将 NAMESPACE_NAME 替换为您启用了自动 Sidecar 注入的命名空间的名称。

      kubectl apply -f simple_pod.yaml -n NAMESPACE_NAME
      
    4. 确认 Pod 已创建:

      kubectl get pods -n NAMESPACE_NAME
      

      输出示例:

      NAME                             READY   STATUS    RESTARTS   AGE
      simple-pod                       2/2     Running   0          9s
      

      Note:确认“READY”列显示 2/2。这表示主容器和边车代理均正常运行。如果您看到的值不同,则可能是因为该命名空间未启用自动 Sidecar 注入。

    5. 验证规范化服务的创建:运行以下命令可列出命名空间中的所有规范化服务。验证是否已创建规范化服务 my-app

      kubectl get canonicalservices -n NAMESPACE_NAME
      

      输出示例:

        NAME          AGE
        my-app        3s
      
    6. 清理:删除 pod、规范化服务和命名空间:

      kubectl delete -f simple_pod.yaml -n NAMESPACE_NAME
      kubectl delete canonicalservices my-app -n NAMESPACE_NAME
      kubectl delete namespace NAMESPACE_NAME
      

    问题排查

恢复使用集群内规范化服务控制器

如果您遇到代管式规范化服务控制器问题,可以使用以下命令重新安装集群内控制器:

  kubectl apply -f \
  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/release-1.25/asm/canonical-service/controller.yaml

后续步骤

了解: