在 GKE 上安装 Anthos Service Mesh

本指南介绍如何为位于同一项目中的一个或多个 GKE 集群所在的网格安装、迁移到或升级到 Anthos Service Mesh 版本 1.7.8。您将使用 Google 提供的脚本，该脚本配置项目和集群，然后安装 Anthos Service Mesh。

本指南和脚本适用于以下使用场景：

  • 新安装 Anthos Service Mesh。

  • 从 Anthos Service Mesh 1.6 或 1.7 补丁程序版本升级。不支持从更早版本升级。

  • 从开源 Istio 1.6 或 1.7 迁移到 Anthos Service Mesh。不支持从更早版本的 Istio 迁移。

  • 从 1.6 版本的 Istio on GKE 插件迁移到 Anthos Service Mesh。在迁移到 Anthos Service Mesh 之前，您需要使用 Operator 升级到 Istio 1.6。如需查看从该插件迁移的完整步骤，请参阅 Istio on GKE 文档中的迁移到 Anthos Service Mesh。

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

准备工作

本指南假定您具备以下各项：

如果您是从 Istio 迁移，请务必查看准备从 Istio 迁移。

Anthos 与 Anthos Service Mesh 的差异

  • GKE Enterprise 订阅者务必启用 GKE Enterprise API。

    启用该 API

  • 如果您不是 GKE Enterprise 订阅者，您仍然可以安装 Anthos Service Mesh，但 Google Cloud 控制台中的某些界面元素和功能仅供 GKE Enterprise 订阅者使用。如需了解订阅者和非订阅者可以使用的内容，请参阅 GKE Enterprise 和 Anthos Service Mesh 界面差异。如需了解非订阅者的 Anthos Service Mesh 价格，请参阅价格。

脚本会为您启用所有其他必需的 Google API。

要求

  • 您的 GKE 集群必须满足以下要求：

    • 具有至少四个 vCPU 的机器类型，例如 e2-standard-4。如果集群的机器类型没有至少四个 vCPU，请按照将工作负载迁移到不同的机器类型中所述更改机器类型。

    • 最小节点数取决于您的机器类型。Anthos Service Mesh 至少需要八个 vCPU。如果机器类型有四个 vCPU，则您的集群必须至少有两个节点。如果机器类型有八个 vCPU，则集群只需要一个节点。如果需要添加节点，请参阅调整集群大小。

    • 该脚本会在集群上启用 Workload Identity。建议使用 Workload Identity 来调用 Google API。如 Workload Identity 限制所述，启用 Workload Identity 会更改从工作负载到 Google API 的调用方式。

    • （可选，但建议执行）在发布版本中注册集群。我们建议您在常规发布版本中注册集群，因为其他发布版本可能基于 Anthos Service Mesh 1.7.8 不支持的 GKE 版本。如需了解详情，请参阅支持的环境。如果您拥有静态 GKE 版本，请按照在发布渠道中注册现有集群中的说明操作。

  • 如需将服务端口纳入服务网格，必须为服务端口命名，并且名称必须包含以下语法的端口协议：name: protocol[-suffix]，其中方括号表示必须以短划线开头的可选后缀。如需了解详情，请参阅为服务端口命名。

  • 如果您要在专用集群上安装 Anthos Service Mesh，则必须在防火墙中打开端口 15017，以获取与自动 Sidecar 注入搭配使用的网络钩子，以便正常运行。如需了解详情，请参阅在专用集群上打开端口。

  • 如果您在组织中创建了服务边界，则可能需要将 Mesh CA 服务添加到边界。如需了解详情，请参阅将 Mesh CA 添加到服务边界。

  • 对于迁移，istiod 必须安装在 istio-system 命名空间中（通常都是这样）。

限制

一个 Google Cloud 项目只能关联一个网格。

选择证书授权机构

对于新安装和迁移，您可以使用 Anthos Service Mesh 证书授权机构 (Mesh CA) 或 Citadel（现已包含在 istiod 中）作为颁发双向 TLS (mTLS) 证书的证书授权机构 (CA)。

基于以下原因，我们通常建议您使用 Mesh CA：

  • Mesh CA 是一项高度可靠的可扩缩服务，针对 Google Cloud 上动态扩缩的工作负载进行了优化。
  • 通过 Mesh CA，Google 负责管理 CA 后端的安全性和可用性。
  • Mesh CA 让您可在集群中依赖单个信任根。
对于新安装的 Anthos Service Mesh，默认情况下，脚本会启用 Mesh CA。

不过，在某些情况下，您可能会考虑使用 Citadel，例如：

  • 如果您拥有自定义 CA。

  • 如果您要从 Istio 迁移。

    如果您选择 Citadel，则不存在任何停机时间，因为 mTLS 流量在迁移期间不会中断。如果您选择 Mesh CA，则需要为迁移安排停机时间，因为信任根从 Citadel 更改为 Mesh CA。如需完成迁移到 Mesh CA 信任根，您需要重启所有命名空间中的所有 Pod。在此过程中，旧 Pod 无法与新 Pod 建立 mTLS 连接。

来自 Mesh CA 的证书包含有关应用的服务的以下数据：

  • Google Cloud 项目 ID
  • GKE 命名空间
  • GKE 服务账号名称

为迁移或升级进行准备

如果您是从 Istio 迁移，请务必查看准备从 Istio 迁移。

如果您自定义了先前的安装，则在迁移或升级到 Anthos Service Mesh 时需要相同的自定义内容。如果您是通过添加 --set values 标志自定义安装，我们建议您将这些设置添加到 IstioOperator 配置文件。在运行脚本时，您可以通过将 --custom_overlay 与配置文件搭配使用来指定配置文件。

安装所需的工具

您可以在 Cloud Shell 或运行 Linux 的本地机器上运行该脚本。

要在本地运行脚本，请执行以下操作：

  1. 请确保已安装以下工具：

  2. 使用 gcloud CLI 进行身份验证：

    gcloud auth login

  3. 更新组件：

    gcloud components update

  4. 请确保 git 位于您的路径中，以便 kpt 能够找到它。

  5. 下载所需的 kpt 版本。

运行脚本

本部分介绍如何下载脚本、设置必需参数和可选参数，以及如何运行脚本。如需详细了解脚本的功能，请参阅了解脚本。

  1. 将安装 Anthos Service Mesh 1.7.8 的脚本下载到当前工作目录中：

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7 > install_asm

    虽然您可以从安全的 Cloud Source Repositories 位置下载脚本，但 GitHub 上的 anthos-service-mesh-packages 代码库中也提供了该脚本，因此您可以在下载前查看它所执行的操作。release-1.7-asm 分支上 install_asm 脚本的版本会安装 Anthos Service Mesh 1.7.8。

  2. 将文件的 SHA-256 下载到当前工作目录：

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7.sha256 > 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

  5. 设置选项并指定运行脚本的标志。您应始终包含以下选项：project_id、cluster_name、cluster_location 和 mode。根据 mode，可能需要包含 ca 选项。

    • project_id、cluster_name 和 cluster_location 选项标识要安装 Anthos Service Mesh 的集群。
    • mode 为 install、migrate 或 upgrade。
    • ca 将证书授权机构指定为 mesh_ca 或 citadel。

    以下部分提供了运行脚本的典型示例。如需查看脚本参数的完整说明，请参阅选项和标志。

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

示例

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

仅验证

以下示例展示使用 --only_validate 选项运行脚本。使用此选项时，脚本不会对您的集群进行任何更改，也不会安装 Anthos Service Mesh。该脚本会验证以下内容：

  • 您的环境拥有所需的工具。
  • 您对指定项目拥有所需权限。
  • 集群符合最低要求。
  • 项目已启用所有必需的 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 install \
  --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
re-run the script with the '--enable_apis' flag to allow the script to enable
them on your behalf.

安装

以下命令运行新安装的脚本，启用 Mesh CA（新安装的默认 CA，因此在此情况下不需要使用 ca 选项），并允许脚本启用所需的 Google API。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis

使用 Citadel 作为 CA 进行安装

本节介绍如何执行以下操作：

  • 生成 Anthos Service Mesh 用于签署工作负载的证书和密钥。
  • 运行脚本进行安装，并启用 Citadel 作为 CA。

建议仅在需要自定义 CA 时才将 Citadel 用作 CA。

为了获得最佳安全性，我们强烈建议您维护离线根 CA，并使用从属 CA 为每个集群颁发 CA。如需了解详情，请参阅插入 CA 证书。在此配置中，服务网格中的所有工作负载都使用同一个根 CA。每个 Anthos Service Mesh CA 使用中间 CA 签名密钥和证书（由根 CA 签名）。当网格中存在多个 CA 时，这会建立 CA 间的信任层次结构。您可以重复这些步骤，为任意数量的证书授权机构预配证书和密钥。

  1. 为证书和密钥创建一个目录：

    mkdir -p certs && \
pushd certs

  2. 生成根证书和密钥：

    make -f ../tools/certs/Makefile.selfsigned.mk root-ca

    这会生成以下文件：

    • root-cert.pem：根证书
    • root-key.pem：根密钥
    • root-ca.conf：openssl 用于生成根证书的配置
    • root-cert.csr：根证书的 CSR

  3. 生成中间证书和密钥：

    make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts

    此操作会在名为 cluster1 的目录中生成以下文件：

    • ca-cert.pem：中间证书
    • ca-key.pem：中间密钥
    • cert-chain.pem：istiod 使用的证书链
    • root-cert.pem：根证书

    如果您使用离线计算机执行这些步骤，请将生成的目录复制到运行脚本的计算机。

  4. 运行脚本并添加之前为证书和密钥生成的文件。

    ./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH \
  --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 install \
  --enable_apis \
  --custom_overlay OVERLAY_FILE

使用选项进行安装

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

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis \
  --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.7-asm asm

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

从 Istio 迁移

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

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m migrate \
  -c citadel \
  --enable_apis

使用叠加文件进行迁移

叠加文件是一个 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 \
  --custom_overlay OVERLAY_FILE

升级

以下命令可运行脚本以进行升级。此脚本不允许您切换到另一个 CA，因此您无需添加 ca 选项。

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m upgrade \
  --enable_apis

使用叠加文件升级

叠加层文件是一个 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 upgrade \
  --enable_all \
  --custom_overlay OVERLAY_FILE

选项和标志

本部分介绍了脚本的可用参数。

选项

-p|--project_id CLUSTER_PROJECT_ID
在其中创建集群的项目的 ID。
-n|--cluster_name CLUSTER_NAME
集群的名称。
-l|--cluster_location CLUSTER_LOCATION
在其中创建集群的区域（对于单区域集群）或地区（对于地区级集群）。
-m|--mode {install|migrate|upgrade}
如果您要安装 Anthos Service Mesh，请输入 install。如果您是从 Istio 迁移，请输入 migrate。输入 upgrade 可将现有的 Anthos Service Mesh 安装升级到新版本。
-c|--ca {mesh_ca|citadel}
对于安装，如果您要使用 Mesh CA，则无需添加此选项，因为脚本会默认为 Mesh CA。对于升级，您无需添加此选项，因为脚本不允许您更改 CA。对于迁移，请指定 citadel 或 mesh_ca。如果您可以为迁移安排停机时间，我们建议您使用 mesh_ca。如需详细了解应使用哪个 CA，请参阅选择证书授权机构。如需了解使用 Citadel 时必须指定的其他选项，请参阅 Citadel 的自定义证书选项。
--co|--custom_overlay YAML_FILE
IstioOperator 自定义资源 (CR) YAML 文件的名称，用于启用默认情况下未启用的功能。该脚本必须能够找到该 YAML 文件，因此该文件必须与该脚本位于同一目录中，您也可以指定相对路径。如需添加多个文件，请指定 --co|--custom_overlay 和文件名，例如：--co overlay_file1.yaml --co overlay_file2.yaml --co overlay_file3.yaml
-o|--option OPTION_FILE
YAML 文件名来自 anthos-service-mesh 软件包，其包含 IstioOperator CR，可启用可选功能。添加其中某个文件时，您无需先下载 anthos-service-mesh 软件包，也无需指定 .yaml 扩展名。如需修改任何文件，请下载 anthos-service-mesh 软件包、进行更改，然后使用 --custom_overlay 选项。如需添加多个文件，请指定 -o|--option 和文件名，例如：-o option_file1 -o option_file2 -o option_file3
-s|--service_account ACCOUNT
用于安装 Anthos Service Mesh 的服务账号的名称。如果未指定，则使用当前 gcloud 配置中的活动用户账号。如果您需要更改活跃用户账号，请运行 gcloud auth login。
-k|--key_file FILE_PATH
服务账号的密钥文件。如果您未使用服务账号，请忽略此选项。
-D|--output_dir DIR_PATH
如果未指定，脚本将创建一个临时目录，用于下载安装 Anthos Service Mesh 所需的文件和配置。指定 --output-dir 标志以改为指定使用现有目录。完成后，指定的目录包含 asm 和 istio-1.7.8-asm.10 子目录。asm 目录包含安装的配置。istio-1.7.8-asm.10 目录包含安装文件的解压缩内容，其中包含 istioctl、示例和清单。

标志

-e|--enable_apis
允许该脚本启用 Anthos Service Mesh 所需的 Google API。未使用此标志的情况下，如果所需的 API 尚未启用，则脚本将退出。如需查看脚本启用的 API 列表，请参阅 set_up_project。
-v|--verbose
在执行前后输出命令。
--dry_run
输出命令，但不执行这些命令。
--only_validate
运行验证，但不安装 Anthos Service Mesh。
--print_config
请将所有已编译的 YAML 输出到标准输出 (stdout)，而不是安装 Anthos Service Mesh。所有其他输出都会写入标准错误 (stderr)，即使它通常会转到 stdout 也是如此。当您指定此标志时，该脚本会跳过所有验证和设置操作。
--disable_canonical_service
默认情况下，该脚本会将规范化服务控制器部署到您的集群。如果您不希望脚本部署该控制器，请指定 --disable_canonical_service。如需了解详情，请参阅启用和停用规范化服务控制器。
-h|--help
显示描述选项和标志的帮助消息并退出。
--version
打印 install_asm 版本并退出。如果命令未输出版本，请下载最新版本的 install_asm_1.7。

Citadel 的自定义证书的选项

如果指定了 citadel 并且您使用的是自定义 CA，请添加以下选项：

  • --ca_cert FILE_PATH：中间证书
  • --ca_key FILE_PATH：中间证书的密钥
  • --root_cert FILE_PATH：根证书
  • --cert_chain FILE_PATH：证书链

如需了解详情，请参阅在现有 CA 证书中插入。

部署和重新部署工作负载

您需要启用自动边车代理注入（自动注入），才能完成安装。

  • 对于新安装，在安装 Anthos Service Mesh 之前，您需要为集群上运行的所有工作负载启用自动注入和重启 pod。

  • 迁移和升级遵循双控制层面升级过程（在 Istio 文档中称为 Canary 版升级）。借助双控制层面升级，该脚本将同时安装新版 istiod 以及现有 istiod。然后，您再将部分工作负载移至新版本。利用此过程，您可以通过一小部分工作负载监控新版本的影响，然后再将所有流量迁移到新版本。

  • 在部署新工作负载之前，请务必启用自动注入，以便 Anthos Service Mesh 可以监控和保护流量。

要启用自动注入，您需要获取脚本应用于 istiod 的修订版本标签，并使用该修订版本标签为命名空间添加标签。以下部分将作详细介绍。

获取修订版本标签

脚本会将格式为 istio.io/rev=asm-178-10 的修订版本标签添加到 istiod。要启用自动注入，请向一个或多个命名空间添加匹配的修订版本标签。Sidecar 注入器网络钩子会使用修订版本标签将注入的 Sidecar 与特定 istiod 修订版本相关联。添加标签后，必须重启命名空间中的任何现有 pod，才能注入 Sidecar。

  1. 设置 kubectl 的当前上下文：

    gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID

  2. 显示 istiod 上的标签，以获取脚本设置的修订版本标签：

    kubectl -n istio-system get pods -l app=istiod --show-labels

    此命令的输出类似如下所示。请注意，新安装、迁移和升级的输出略有不同。以下示例输出来自迁移。

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
istiod-asm-178-10-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-178-10-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7

    在输出中的 LABELS 列下，记下 istiod 修订版本标签的值，该值位于前缀 istio.io/rev= 之后。在此示例中，该值为 asm-178-10，但您的值可能会不同。

    对于升级和迁移，还请记下旧版 istiod 的修订版本标签中的值。完成迁移或升级后，您需要使用此值来删除旧版本的 istiod。在示例输出中，旧 istiod 版本的修订版本标签中的值为 default，但您的值可能会不同。

启用自动注入

按照适用于新安装、迁移和升级的以下步骤进行操作，以启用自动注入。

  1. 获取 istiod 的修订版本标签中的值。

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

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

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

    kubectl rollout restart deployment -n NAMESPACE

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

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

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

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

对于迁移和升级：

  • 如果您确信应用按预期正常运行，请继续进行下一部分以完成转换从而转换到新版本的 istiod。

  • 如果应用出现问题，请按照回滚到先前版本中的步骤操作。

完成转换

对于迁移和升级，您需要移除旧版 istiod。如果您确信应用按预期正常运行，请移除旧控制层面以完成到新版本的转换。

  1. 获取 istiod 的旧版本的版本标签中的值。

  2. 删除 istiod 的旧版本。在以下命令中，将 OLD_REVISION 替换为上一步中获得的修订版本。

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

回滚到先前版本

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

  1. 重新为您的命名空间添加标签，以启用旧版 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

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

    kubectl rollout restart deployment -n NAMESPACE

  3. 重新部署旧版 istio-ingressgateway：

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

  4. 移除新的 istiod：

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

  5. 如果您未添加 --disable_canonical_service 标志，则脚本会启用规范化服务控制器。按照启用和停用规范化服务控制器中的步骤操作以将其停用。

重新安装同一版本

install_asm 脚本会调用 istioctl install 来部署 Anthos Service Mesh 控制层面组件（istiod 和 istio-ingressgateway），以用于安装、升级和 Istio 迁移。由于该脚本使用 istioctl install，如果您需要自定义 Anthos Service Mesh 以启用可选功能，则必须使用新配置重新安装控制层面中。

install_asm 脚本已发生了更改，因此您可以重新安装相同版本的 Anthos Service Mesh。当您重新安装同一版本以启用可选功能时，现有的控制层面配置会被覆盖。因此，如果您自定义了现有安装，则需要添加先前安装中使用的相同 --option 和/或 --custom_overlay 选项以及添加 --option 和/或 --custom_overlay 选项，以启用您需要的新功能。

请注意，如果您要启用 Cloud Trace 或更改跟踪设置，则还需要重新部署工作负载，以便 Sidecar 代理会重新注入更新后的控制层面配置。

重新安装同一版本时，请指定 --mode install（就像安装一样）。如需了解如何使用脚本进行安装，请参阅安装 Anthos Service Mesh。

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

查看 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 指标。

注册您的集群

您必须向项目的队列注册集群，才能获取对 Google Cloud 控制台中的统一界面的访问权限。队列提供一种统一方法来查看和管理集群及其工作负载，包括 Google Cloud 之外的集群。

如需了解如何注册集群，请参阅向舰队注册集群。

了解脚本

虽然您可以从安全的 Cloud Source Repositories 位置下载该脚本，但 GitHub 上也提供了该脚本，因此您可以在下载前查看它所执行的操作。该脚本会验证您的集群是否满足要求，并且会自动执行您在 GKE 上安装 Anthos Service Mesh 时需要手动执行的所有步骤。

通过 Anthos Service Mesh 1.7.8，您可以在 release-1.7-asm 分支上使用 install_asm 脚本的版本。如需查看版本控制和发布流程的说明，请参阅版本控制/发布。

validate_args 和 validate_dependencies

validate_args() {
  if [[ "${MODE}" == "install" && -z "${CA}" ]]; then
    CA="mesh_ca"
  fi

  local MISSING_ARGS=0
  while read -r REQUIRED_ARG; do
    if [[ -z "${!REQUIRED_ARG}" ]]; then
      MISSING_ARGS=1
      warn "Missing value for ${REQUIRED_ARG}"
    fi
    readonly "${REQUIRED_ARG}"
  done <<EOF
 
validate_dependencies() {
  validate_cli_dependencies
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi

  validate_gcp_resources
  # configure kubectl does have side effects but we've generated a temprorary
  # kubeconfig so we're not breaking the promise that --only_validate gives
  configure_kubectl
  validate_k8s
  validate_expected_control_plane

  if [[ "${MODE}" = "migrate" ]]; then
    validate_istio_version
  elif [[ "${MODE}" = "upgrade" ]]; then
    validate_asm_version
    validate_ca_consistency
  fi

  if [[ "${ENABLE_APIS}" -eq 0 || "${ONLY_VALIDATE}" -eq 1 ]]; then
    exit_if_apis_not_enabled
  fi
}

validate_args 和 validate_dependencies 函数：

  • 检查是否安装了所有必需的工具。
  • 验证您作为参数值输入的项目 ID、集群名称和集群位置是否有效。
  • 确保集群满足机器类型和节点数的最低要求。

set_up_project

如果您添加了 --enable_apis 标志，则 set_up_project 函数会启用所需的 API：

required_apis() {
    cat << EOF
container.googleapis.com
compute.googleapis.com
monitoring.googleapis.com
logging.googleapis.com
cloudtrace.googleapis.com
meshca.googleapis.com
meshtelemetry.googleapis.com
meshconfig.googleapis.com
iamcredentials.googleapis.com
gkeconnect.googleapis.com
gkehub.googleapis.com
cloudresourcemanager.googleapis.com
stackdriver.googleapis.com
EOF
}

set_up_cluster

set_up_cluster(){
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi
  add_cluster_labels
  enable_workload_identity

  init_meshconfig

  enable_stackdriver_kubernetes
  bind_user_to_cluster_admin
  ensure_istio_namespace_exists
}

set_up_cluster 函数会对您的集群进行以下更新：

  • 启用 Workload Identity，这是从 GKE 应用安全访问 Google Cloud 服务的推荐方法。

  • 启用 GKE 上的 Cloud Monitoring 和 Cloud Logging。

  • 在集群上设置 mesh_id 标签，该标签对于在 Google Cloud 控制台中的 Anthos Service Mesh 页面上显示指标必不可少。

  • 设置像 asmv=asm-178-10 这样的标签，以分辨脚本是否已修改集群。

  • 将运行脚本的 GCP 用户或服务账号绑定到集群上的集群管理员角色。

install_asm

install_asm() {

  local PARAMS
  PARAMS="-f ${OPERATOR_MANIFEST} -f ${MULTICLUSTER_MANIFEST}"
  while read -d ',' -r yaml_file; do
    PARAMS="${PARAMS} -f ${yaml_file}"
  done <<EOF

install_asm 函数

  • 将 kpt 软件包下载到临时目录。
  • 运行 kpt setter 以配置 istio-operator.yaml 文件。
  • 安装 Anthos Service Mesh。

后续步骤