就地 CA 迁移

注意：本指南介绍如何使用基于 bash 的工具以最短停机时间迁移证书授权机构 (CA)，而无需将工作负载迁移到新的控制平面（就地）。如需使用基于 Canary 版的方法从 Istio CA 迁移到 Mesh CA（该方法可实现最短停机时间或无停机时间），请参阅使用基于 Canary 版的方法迁移到 Mesh CA。

如果您的网格中有多个集群带有向其他集群上的工作负载发送请求的工作负载，请为所有集群执行本指南中的所有步骤。

对于以下使用场景，请按照本指南中的步骤操作：

• 将使用 Mesh CA 的集群内 Anthos Service Mesh v1.13 或更高版本的控制平面迁移到 Certificate Authority Service。
• 将使用 Mesh CA 并且发布渠道映射到 v1.13 或更高版本的代管式 Anthos Service Mesh 控制平面迁移到 Certificate Authority Service。

限制

只有 Anthos Service Mesh v1.13 或更高版本支持就地 CA 迁移和升级。对于代管式控制平面迁移，请确保所选渠道映射到 v1.13 或更高版本。

前提条件

在执行本指南中的步骤之前，请确保已完成以下任务：

• 授予集群管理员权限
• 配置 gcloud

此外，请确保您当前使用的是 Anthos Service Mesh v1.13 或更高版本。

所需工具

在迁移期间，您将运行 Google 提供的工具 migrate_ca。此工具具有以下依赖项：

• awk
• grep
• jq
• kubectl
• head
• sed
• tr
• yq

在下载 migrate_ca 工具之前，请按照为迁移做好准备中的步骤操作。

迁移概览

在迁移过程中，身份验证和授权可在使用旧 CA 的工作负载与使用新 CA 的工作负载之间完全正常运行。

migrate_ca 迁移工具将创建一个 Kubernetes 配置映射，以跟踪每个安装的 Anthos Service Mesh 修订版本/渠道的 CA 迁移状态。这是安装在 istio-system 命名空间中的特权资源。

apiVersion: v1
kind: ConfigMap
metadata:
  Name: asm-ca-migration-<revision>
Data:
  revision:
  start_time:
  state_update_time:
  current_state: TRUSTANCHOR_INJECT | MIGRATE_CA | ROLLBACK
  old_ca:
  target_ca:

迁移工具将在修改 Istio MeshConfig 配置映射之前备份该映射，并尽可能使用 ProxyConfig CRD 迁移 CA 配置。

以下是 CA 迁移的概要步骤：

注意：您必须对网格中的每个集群执行迁移步骤。

1. 为迁移做好准备。

2. 初始化新 CA。

3. 为舰队中的所有集群添加网格级信任锚。

4. 迁移 CA。

5. 执行回滚。

为迁移做好准备

1. 下载 migrate_ca bash 工具：

   curl  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/ca-migration/migrate_ca > migrate_ca
   

2. 将该工具设置为可执行工具：

   chmod +x migrate_ca
   

3. 设置工作目录：

   ./migrate_ca setup --output_dir OUTPUT_DIR
   

   注意：如果您未指定工作目录，则系统会创建一个临时目录。它将被用作所有后续步骤的工作目录。

4. 将工作目录更改为上一步中指定的 OUTPUT_DIR

   cd OUTPUT_DIR
   

5. 运行以下命令以确保满足所有前提条件：

   ./migrate_ca check-prerequisites
   

6. 记下与要迁移的旧 CA 关联的控制平面的修订版本 (ASM_REVISION)。所需的步骤取决于控制平面的类型（集群内或代管式）。

   集群内

   asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \
    "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")
   

   代管式

   请参阅已安装的渠道。

7. 由于就地 CA 迁移需要重启工作负载，因此请确保正确配置 Pod 中断预算以及需要迁移 CA 的所有应用有多个正在运行的 Pod。

8. 确保该集群已注册到舰队，并且集群上已启用 Workload-Identity。然后，记下舰队 ID (FLEET_ID)，以供后续步骤使用。

9. 该工具接受 kubeConfig 和 kubeContext 以选择执行操作的集群。如果未传入这些参数，则使用默认上下文/配置。

   • 如需将 GKE 集群的凭据添加到 kubeConfig，请使用以下命令：

     gcloud container clusters get-credentials CLUSTER_NAME
     

   • 如需更改当前 kubectl 上下文或将上下文传递给该工具，请使用以下命令：

     kubectl config get-contexts
     kubectl config use-context CLUSTER_NAME
     

初始化新 CA

1. 初始化新 CA 所需的步骤取决于您要迁移到的新 CA。请在要迁移 CA 的每个舰队集群中执行这些步骤。

   Mesh CA

   调用实用程序工具 initialize 子命令。

   如果要指定自定义 Kubernetes 配置，请添加以下内容：

    ./migrate_ca initialize --kubeconfig KUBECONFIG --kubecontext KUBECONTEXT --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
   

   否则：

    ./migrate_ca initialize --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
    ```
   

   CA Service

   a. 按照初始化 Certificate Authority Service 所需的步骤操作。记下 CA_POOL。

   b. 调用实用程序工具 initialize 子命令：

   如果要指定自定义 Kubernetes 配置，请添加以下内容：

    ./migrate_ca initialize --kubeconfig KUBECONFIG --context KUBECONTEXT --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
    --fleet-id FLEET_ID --revision ASM_REVISION
   

   否则：

     ./migrate_ca initialize --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
     --fleet-id FLEET_ID --revision ASM_REVISION
   

为舰队中的所有集群添加网格级信任锚

1. 对舰队中所有集群的新 CA 和旧 CA 重复执行以下步骤。

2. 下载 CA 的信任锚：

   Mesh CA

   ./migrate_ca download-trust-anchor --ca mesh_ca --ca_cert ROOT_CERT.pem
   

   CA Service

   将 CA 证书存储在一个文件中：

   gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pem
   

3. 添加 CA 的信任锚：

   ./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
   

4. 验证舰队中的所有工作负载都已收到信任锚。在命名空间参数中，传入工作负载部署到的所有命名空间：

   ./migrate-ca check-trust-anchor --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   预期输出：

   Check the CA cert in namespace nsa-1-24232
   a-v1-597f875788-52c5t.nsa-1-24232 trusts root-cert.pem
   

迁移 CA

1. 迁移 CA 配置。所需的命令取决于您要迁移到的新 CA。

   Mesh CA

   ./migrate_ca migrate-ca --ca mesh_ca
   

   CA Service

   ./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
   

2. 重启所有工作负载。

   注意：如果您已安装代管式数据平面，则此步骤是可选的。这是因为 Google 会管理代理生命周期，并在代管式升级期间自动执行此步骤。

   为了将 TLS 流量中断的风险降至最低，此步骤应首先影响尽可能少的工作负载。仅重启与控制平面修订版本 ASM_REVISION 关联的工作负载。例如，如果 kubernetes 命名空间 NAMESPACE 中的所有工作负载都与相同的 Anthos Service Mesh 控制平面关联。

   kubectl rollout restart deployment -n NAMESPACE
   

3. 在对所有命名空间和属于该舰队的所有集群重复步骤 1 和 2 之前，验证重启的命名空间中的工作负载与其他工作负载之间的 mTLS 连接有效。如果新工作负载启动，并且网格流量未中断，请对属于舰队的所有命名空间和集群重复第 1 步和第 2 步。否则，请执行回滚，以回滚较新的 CA 配置。

4. 验证所有工作负载都在使用新的 CA 配置：

   ./migrate_ca verify-ca --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   预期输出：

   Check the CA configuration in namespace nsb-2-76095
   b-v1-8ff557759-pds69.nsb-2-76095 is signed by root-cert.pem
   

执行回滚

1. 回滚 CA 配置并移除新配置的信任锚：

   ./migrate-ca rollback
   

2. 重启所有工作负载。确保仅重启与控制平面修订版本 ASM_REVISION 关联的工作负载。例如，如果 kubernetes 命名空间 NAMESPACES 中的所有工作负载都与相同的 Anthos Service Mesh 控制平面关联。

   kubectl rollout restart deployment -n NAMESPACES
   

3. （可选）验证所有工作负载都在使用旧的 CA 配置。

   ./migrate-ca verify-ca --ca_cert older-root-cert.pem
   

4. 对其中的工作负载使用 ASM_REVISION 控制平面的舰队中的所有集群重复步骤 1 至 3。

恭喜！您已成功执行就地 CA 迁移。