从 Istio 迁移

本页面介绍如何运行脚本以在 GKE 集群上将网格从 Istio 1.7 or 1.8 迁移到 Anthos Service Mesh 1.8.6，该网格包含属于同一 Google Cloud 项目的一个或多个集群。

对于集群位于不同项目中的多集群网格，请参阅 GKE 的多集群/多项目安装和迁移。

本页面介绍了如何从 Istio 迁移到 Anthos Service Mesh。如需了解如何运行脚本以进行新安装和升级，请参阅以下内容：

准备工作

在开始迁移之前，请确保您已执行以下任务：

脚本要求您具有所需的权限，或者添加 --enable_all 或 --enable_gcp_iam_roles 标志以允许脚本为您启用权限。同样，如需使脚本启用所需的 API 并更新集群，请指定 --enable_all 标志或更加细化的启用标志。

准备迁移

请务必查看准备从 Istio 迁移。

如果您自定义了先前的安装，在升级至新的 Anthos Service Mesh 版本或从 Istio 迁移时，需要相同的自定义。如果您通过向 istioctl install 添加 --set values 标志来自定义安装，则必须将这些设置添加到 IstioOperator YAML 文件（称为 叠加文件。您可以在运行脚本时使用 --custom_overlay 选项和文件名来指定叠加文件。脚本将叠加文件传递给 istioctl install。

脚本遵循修订版本升级过程（在 Istio 文档中称为“Canary”升级）。使用基于修订版本的升级时，该脚本会安装新版本的控制平面，与现有控制平面同时存在。安装新版本时，该脚本包含用于标识新控制平面的 revision 标签。

然后您迁移至新版本，方式是在工作负载上设置相同的 revision 标签并执行滚动重启以重新注入代理，以便这些代理使用新的 Anthos Service Mesh 版本和配置。通过这种方法，您可以监控升级对一小部分工作负载的影响。测试应用后，您可以将所有流量迁移到新版本。此方法比执行就地升级更安全，因为新的控制平面组件替换了旧版本。

迁移到 Anthos Service Mesh

  1. 设置选项并指定运行脚本的标志。您应始终包含以下选项：project_id、cluster_name、cluster_location 和 mode。

    以下部分提供了运行脚本的典型示例。请在右侧的导航栏中查看示例列表。如需查看脚本参数的完整说明，请参阅选项和标志。

  2. 要完成 Anthos Service Mesh 的设置，您需要启用自动 Sidecar 注入并部署或重新部署工作负载。

示例

本部分提供了运行迁移脚本的示例以及一些可能有用的其他参数。请在右侧的导航栏中查看示例列表。

仅验证

以下示例展示使用 --only_validate 选项运行脚本。使用此选项时，脚本不会对您的项目或集群进行任何更改，也不会安装 Anthos Service Mesh。如果您指定 --only_validate，则在包括任何 --enable_* 标志的情况下此脚本将失败。

该脚本会验证以下内容：

  • 您的环境拥有所需的工具。
  • 您对指定项目拥有所需权限。
  • 集群符合最低要求。
  • 项目已启用所有必需的 Google API。

默认情况下，该脚本会下载并解压缩安装文件，并将 GitHub 中的 asm 配置软件包下载到临时目录中。在退出之前，该脚本会输出一条消息，提供临时目录的名称。您可以使用 --output_dir DIR_PATH 选项为下载指定现有目录。--output_dir 选项可方便您使用 istioctl 命令行工具（如果需要）。 此外，用于启用可选功能的配置文件包含在 asm/istio/options 目录中。

运行以下命令以验证配置并将安装文件和 asm 软件包下载到 OUTPUT_DIR 目录：

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --output_dir DIR_PATH \
  --only_validate

成功后，脚本将输出以下内容：

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

如果某一个测试未通过验证，脚本将输出错误消息。例如，如果您的项目未启用所有必需的 Google API，您会看到以下错误：

ERROR: One or more APIs are not enabled. Please enable them and retry, or run
the script with the '--enable_gcp_apis' flag to allow the script to enable them
on your behalf.

如果您收到错误消息，其中指出需要使用某个启用标志以运行脚本，则可以添加错误消息中的特定标志，或在不使用 --only_validate 的情况下运行脚本时使用 --enable_all 标志。如《多项目安装指南》中的设置项目和设置集群部分所述，如果您愿意，您可以在运行脚本之前自行更新项目和集群。

使用 Citadel 从 Istio 迁移

如果您是使用 Citadel 作为 CA 从 Istio 迁移，则可以在迁移到 Anthos Service Mesh 后继续使用 Citadel。以下命令会运行脚本以执行迁移，并启用 Citadel 作为 CA。此迁移仅部署控制平面。它不会更改根 CA，也不会干扰现有工作负载。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --option revisioned-istio-ingressgateway \
  --enable_all

使用叠加文件进行迁移

叠加文件是一个 YAML 文件，其中包含您传递给 install_asm 以配置控制平面的 IstioOperator 自定义资源 (CR)。您可以替换默认控制平面配置，并通过将 YAML 文件传递给 install_asm 来启用可选功能。您可以叠加多个文件，每个叠加文件会覆盖之前各层的配置。

如果您在 YAML 文件中指定多个 CR，则 install_asm 会将文件拆分为多个临时 YAML 文件，每个 CR 对应一个临时 YAML 文件。该脚本将 CR 拆分为单独的文件，因为 istioctl install 仅应用包含多个 CR 的 YAML 文件中的第一个 CR。

以下示例会执行迁移，并添加一个叠加文件以自定义控制平面配置。在以下命令中，将 OVERLAY_FILE 更改为 YAML 文件的名称。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --enable_all \
  --option revisioned-istio-ingressgateway \
  --custom_overlay OVERLAY_FILE

通过选项进行迁移

以下示例执行迁移，并纳入了 asm 软件包中的 egressgateways.yaml 文件，该文件可启用出站流量网关。请注意，您没有添加 .yaml 扩展程序。该脚本会为您提取文件，因此您不必先下载 asm 软件包。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --enable_all \
  --option revisioned-istio-ingressgateway \
  --option egressgateways

您可以使用 --option 来启用可选功能。如果您需要对 asm 软件包的 asm/istio/options 目录中的任何文件进行修改，请使用 --custom_overlay 下载 asm 软件包、进行更改并添加文件。

要将 asm 软件包下载到当前工作目录以便修改文件，请执行以下操作：

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.8-asm asm

如果您在指定 --output_dir 选项的位置运行仅验证示例，则配置文件位于 asm/istio/options 下的指定输出目录中。

部署和重新部署工作负载

您需要启用自动边车代理注入（自动注入），才能完成安装。 从 OSS Istio 迁移和升级遵循基于修订版本的升级流程（在 Istio 文档中称为“Canary 升级”）。使用基于修订版本的升级时，新版本的控制平面会与现有控制平面一起安装。然后，您可以将一部分工作负载迁移到新版本，这样，您就可以先通过一小部分工作负载监控升级的影响，然后再将所有流量迁移到新版本。

该脚本在 istiod 上设置格式为 istio.io/rev=asm-186-8 的修订版本标签。要启用自动注入，请向一个或多个命名空间添加匹配的修订版本标签。Sidecar 注入器网络钩子会使用修订版本标签将注入的 Sidecar 与特定 istiod 修订版本相关联。添加标签后，重启命名空间中的 pod 以注入 Sidecar。

该脚本还会创建已修订的 istio-ingressgateway Deployment。这样，您就可以控制何时切换到新版本。

  1. 获取 istiod 和 istio-ingressgateway 上的修订版本标签。

    kubectl get pod -n istio-system -L istio.io/rev

    此命令的输出类似如下所示。

    NAME                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-65d884685d-6hrdk            1/1     Running   0          67m
istio-ingressgateway-65d884685d-94wgz            1/1     Running   0          67m
istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-186-8
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-186-8
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-178-10
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-178-10
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-186-8
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-186-8

    1. 请注意，您是否同时拥有新旧两版 istio-ingressgateway。

      • 如果您在升级时添加了 revisioned-istio-ingressgateway 选项，则已完成 istio-ingressgateway 的 Canary 升级。在这种情况下，您的输出会同时显示新旧两版 istio-ingressgateway。

      • 如果您在升级时未添加 revisioned-istio-ingressgateway，则系统会完成 istio-ingressgateway 的就地升级。在这种情况下，您的输出仅显示新版本。

    2. 在输出中的 REV 列下，记下新版本的修订版标签的值。在此示例中，该值为 asm-186-8。

    3. 另请注意旧版 istiod 的修订版本标签中的值。 将工作负载移至新版本后，您需要使用此值删除旧版本的 istiod。在示例输出中，旧版本的修订版本标签值为 asm-178-10。

  2. 如果您同时拥有新旧两版 istio-ingressgateway，请将 istio-ingressgateway 切换到新修订版本。在以下命令中，将 REVISION 的值更改为新版本修订版本标签的值。

    kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

    预期输出：service/istio-ingressgateway patched

  3. 将修订版本标签添加到命名空间，并移除 istio-injection 标签（如果存在）。在以下命令中，将 REVISION 更改为与 istiod 的新修订版本匹配的值。

    kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

    如果您在输出中看到 "istio-injection not found"，则可以忽略它。这意味着命名空间之前没有 istio-injection 标签。如果命名空间同时具有 istio-injection 和修订版本标签，自动注入将失败，因此 Anthos Service Mesh 文档中的所有 kubectl label 命令都包含移除 istio-injection 标签。

  4. 重启 pod 以触发重新注入。

    kubectl rollout restart deployment -n NAMESPACE

  5. 验证 pod 是否配置为指向新版 istiod。

    kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION

  6. 测试您的应用，验证工作负载是否正常工作。

  7. 如果您的其他命名空间中存在工作负载，请重复上述步骤以标记命名空间并重启 Pod。

  8. 如果您确信应用按预期正常运行，请继续执行转换到新版 istiod 的步骤。如果您的应用出现问题，请按照以下步骤回滚。

  9. 再次运行以下命令，确认您拥有新旧两版 istio-ingressgateway，还是只有新版本。这决定了如何转换到新版本 istio-ingressgateway 或如何回滚到旧版本。

    kubectl get pod -n istio-system -L istio.io/rev

    完成转换

    如果您确信应用按预期正常运行，请移除旧控制平面以完成到新版本的转换。

    1. 切换到 anthos-service-mesh GitHub 代码库中的文件所在的目录。

    2. 配置验证 Webhook 以使用新的控制平面。

      kubectl apply -f asm/istio/istiod-service.yaml

    3. 如果您同时拥有新旧两版 istio-ingressgateway，请删除旧的 istio-ingressgateway Deployment。要运行的命令取决于您是从 Istio 迁移还是从旧版 Anthos Service Mesh 升级：

      迁移

      如果您是从 Istio 迁移，旧的 istio-ingressgateway 没有修订版本标签。

      kubectl delete deploy/istio-ingressgateway -n istio-system

      升级

      如果您是从旧版 Anthos Service Mesh 升级，请在以下命令中将 OLD_REVISION 替换为旧版 istio-ingressgateway 的修订版本标签。

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true

    4. 删除 istiod 的旧版本。要使用的命令取决于您是从 Istio 迁移还是从旧版 Anthos Service Mesh 升级。

      迁移

      如果您是从 Istio 迁移，旧的 istiod 没有修订版本标签。

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

      升级

      如果您是从旧版 Anthos Service Mesh 升级，在以下命令中，请确保 OLD_REVISION 与旧版 istiod 的修订版本标签匹配。

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

    5. 移除旧版 IstioOperator 配置。

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system

      预期输出如下所示：

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

    回滚

    如果您在使用新版 istiod 测试应用时遇到问题，请按照以下步骤回滚到之前的版本：

    1. 切换回旧版 istio-ingressgateway。您使用的命令取决于您同时拥有新旧两版 istio-ingressgateway 还是只有新版本。

      • 如果您同时拥有新旧两版 istio-ingressgateway，请运行 kubectl patch service 命令并将 OLD_REVISION 替换为旧修订版本。

        kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'

      • 如果您只有新版本的 istio-ingressgateway，请运行 kubectl rollout undo 命令。

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

    2. 重新为您的命名空间添加标签，以启用旧版 istiod 的自动注入。使用的命令取决于您在旧版本使用的是修订版本标签还是 istio-injection=enabled。

      • 如果您使用修订版本标签来进行自动注入，请使用以下命令：

        kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite

      • 如果您使用的是 istio-injection=enabled，请使用以下命令：

        kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite

      预期输出：

      namespace/NAMESPACE labeled

    3. 确认命名空间上的修订版本标签与旧版 istiod 的修订版本标签一致：

      kubectl get ns NAMESPACE --show-labels

    4. 重启 pod 以触发重新注入，以使代理具有之前的版本：

      kubectl rollout restart deployment -n NAMESPACE

    5. 如果您同时拥有新旧两版 istio-ingressgateway，请移除新的 istio-ingressgateway Deployment。确保以下命令中的 REVISION 值正确无误。

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true

    6. 移除新版 istiod。确保以下命令中的 REVISION 值正确无误。

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

    7. 移除新版 IstioOperator 配置。

      kubectl delete IstioOperator installed-state-REVISION -n istio-system

      预期输出如下所示：

      istiooperator.install.istio.io "installed-state-REVISION" deleted

    8. 如果您未添加 --disable_canonical_service 标志，则脚本会启用规范化服务控制器。我们建议将其保持启用状态，但如果您需要停用，请参阅启用和停用规范化服务控制器。

查看 Anthos Service Mesh 信息中心

在集群上部署工作负载并注入边车代理后，您可以在 Google Cloud 控制台中探索 Anthos Service Mesh 页面，以了解 Anthos Service Mesh 提供的所有可观测性功能。请注意，部署工作负载后，遥测数据大约需要一两分钟才会显示在 Google Cloud 控制台中。

在 Google Cloud 控制台中访问 Anthos Service Mesh 的权限由 Identity and Access Management (IAM) 控制。如需访问 Anthos Service Mesh 页面，Project Owner 必须为用户授予 Project Editor 或 Viewer 角色，或者授予在 Google Cloud 控制台中控制对 Anthos Service Mesh 的访问权限中所述的限制性更强的角色。

  1. 在 Google Cloud 控制台中，前往 Anthos Service Mesh。

    转到 Anthos Service Mesh

  2. 从菜单栏的下拉列表中选择 Google Cloud 项目。

  3. 如果您有多个服务网格，请从服务网格下拉列表中选择相应网格。

如需了解详情，请参阅在 Google Cloud 控制台中探索 Anthos Service Mesh。

除了 Anthos Service Mesh 页面，系统还会将与服务相关的指标（例如特定服务收到的请求数）发送到 Cloud Monitoring，这些指标显示在 Cloud Monitoring 的 Metrics Explorer 中。

如需查看指标，请执行以下操作：

  1. 在 Google Cloud 控制台中，转到监控页面：

    转到“监控”

  2. 选择资源 > Metrics Explorer。

如需查看指标的完整列表，请参阅 Cloud Monitoring 文档中的 Istio 指标。

后续步骤