本页面介绍如何运行脚本以在 GKE 集群上将网格从 Istio 迁移到 Anthos Service Mesh 1.10.6,该网格包含属于同一 Google Cloud 项目的一个或多个集群。如果您使用的是 Istio 1.6 或更早版本,则必须先升级,然后才能迁移到 Anthos Service Mesh。如果您使用的是 Istio 1.7 或更高版本,则可能可以使用从 Istio 1.7 或更高版本迁移到 Anthos Service Mesh 和 Mesh CA。如果您需要升级,请在适用的 Istio 版本中转到升级 Istio 页面。请注意,在一个步骤中跨多个次要版本(例如 1.6.x 到 1.8.x)升级 Istio 未经过官方测试或推荐。
准备工作
在开始迁移之前,请确保您已执行以下任务:
脚本要求您具有所需的权限,或者添加 --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
设置选项并指定运行脚本的标志。您应始终包含以下选项:
project_id
、cluster_name
、cluster_location
、mode
和ca
。对于ca
,您可以使用以下选项:--ca mesh_ca
:如果要迁移到 Anthos Service Mesh 证书授权机构 (Mesh CA),请指定此选项。--ca citadel
:如果要继续使用 Istio CA,请指定此选项。
如需了解详情,请参阅选择证书授权机构。
注意:您可以使用
--mode install
从 Istio 进行迁移。当您使用--mode install
而不是--mode migrate
时,无论集群上的控制平面版本如何,install_asm
都允许迁移。migrate
标志仅允许从之前的次要版本或之前的补丁程序版本迁移。以下部分提供了运行脚本的典型示例。如需查看脚本参数的完整说明,请参阅选项和标志。
要完成 Anthos Service Mesh 的设置,您需要启用自动 Sidecar 注入并部署或重新部署工作负载。
示例
本部分提供了运行用于从 Istio 迁移的脚本的示例,以及一些可能有用的其他参数。请在右侧的导航栏中查看示例列表。
仅验证
以下示例展示使用 --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 install \ --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
标志。如果您愿意,可以在运行该脚本之前,按照用于在 GKE 上安装 Anthos Service Mesh 的设置所述,自行更新项目和集群。
请注意,install_asm
不允许任何带有 --only_validate
的启用标志。
迁移到 Mesh CA 但有停机
若要从 Istio CA 迁移到 Anthos Service Mesh 证书授权机构 (Mesh CA),需要迁移信任根。在迁移期间,一些工作负载会使用旧的根证书,而另一些会使用新的 Mesh CA 根证书。使用由不同根证书签名的证书的工作负载无法相互进行身份验证。仅当使用新根 CA 证书重新部署控制平面和所有命名空间中的所有工作负载时,整个集群才会完全恢复。
如果您可以安排停机时间,那么这是迁移到使用 Mesh CA 的 Anthos Service Mesh 的最简单方法。以下示例显示了迁移到 Mesh CA 的典型命令行选项。
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --ca mesh_ca \ --output_dir OUTPUT_DIRECTORY --enable_all
迁移到 Mesh CA,无停机或停机时间极少
如果您无法为迁移到 Mesh CA 安排停机时间,则仍然有向 Mesh CA 迁移的路径,但需要执行其他步骤。如需了解详情,请参阅迁移到 Mesh CA。
迁移但继续使用 Istio CA
如果您需要自定义 CA,则可以在迁移到 Anthos Service Mesh 后继续使用 Istio CA。以下命令会运行脚本来进行迁移并启用 Istio CA。(--ca citadel
选项称为“citadel”,因为这是将所有 Istio 组件纳入 istiod
之前的 CA 组件的名称)。此迁移仅部署控制平面和入站流量网关。它不会更改根 CA,也不会干扰现有工作负载。
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --ca citadel \ --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 \ --ca citadel \ --enable_all \ --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 \ --ca citadel \ --enable_all \ --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.10-asm asm
如果您在指定 --output_dir
选项的位置运行仅验证示例,则配置文件位于 asm/istio/options
下的指定输出目录中。
部署和重新部署工作负载
您需要启用自动边车代理注入(自动注入),才能完成安装。 从 OSS Istio 迁移和升级遵循基于修订版本的升级流程(在 Istio 文档中称为“Canary 升级”)。使用基于修订版本的升级时,新版本的控制平面会与现有控制平面一起安装。然后,您可以将一部分工作负载迁移到新版本,这样,您就可以先通过一小部分工作负载监控升级的影响,然后再将所有流量迁移到新版本。
该脚本在 istiod
上设置格式为 istio.io/rev=asm-1106-2
的修订版本标签。要启用自动注入,请向一个或多个命名空间添加匹配的修订版本标签。Sidecar 注入器网络钩子会使用修订版本标签将注入的 Sidecar 与特定 istiod
修订版本相关联。添加标签后,重启命名空间中的 pod 以注入 Sidecar。
获取
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-1106-2 istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2 1/1 Running 0 20s asm-1106-2 istiod-asm-176-1-67998f4b55-lrzpz 1/1 Running 0 68m asm-198-3 istiod-asm-176-1-67998f4b55-r76kr 1/1 Running 0 68m asm-198-3 istiod-asm-182-2-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1106-2 istiod-asm-182-2-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1106-2
在输出中的
REV
列下,记下新版本的修订版标签的值。在此示例中,该值为asm-1106-2
。另请注意旧版
istiod
的修订版本标签中的值。 将工作负载移至新版本后,您需要使用此值删除旧版本的istiod
。在示例输出中,旧版本的修订版本标签值为asm-198-3
。
将
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
将修订版本标签添加到命名空间,并移除
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
标签。重启 pod 以触发重新注入。
kubectl rollout restart deployment -n NAMESPACE
验证 pod 是否配置为指向新版
istiod
。kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
测试您的应用,验证工作负载是否正常工作。
如果您的其他命名空间中存在工作负载,请重复上述步骤以标记命名空间并重启 Pod。
如果您确信应用按预期正常运行,请继续执行转换到新版
istiod
的步骤。如果您的应用出现问题,请按照以下步骤回滚。完成转换
如果您确信应用按预期正常运行,请移除旧控制平面以完成到新版本的转换。
切换到
anthos-service-mesh
GitHub 代码库中的文件所在的目录。配置验证 Webhook 以使用新的控制平面。
kubectl apply -f asm/istio/istiod-service.yaml
删除旧
istio-ingressgateway
部署。要运行的命令取决于您是从 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
删除
istiod
的旧版本。要使用的命令取决于您是从 Istio 迁移还是从旧版 Anthos Service Mesh 升级。迁移
如果您是从 Istio 迁移,旧的
istio-ingressgateway
没有修订版本标签。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
移除旧版
IstioOperator
配置。kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
预期输出如下所示:
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
回滚
如果您在使用新版
istiod
测试应用时遇到问题,请按照以下步骤回滚到之前的版本:切换回旧版
istio-ingressgateway
。在以下命令中,将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"}]'
重新为您的命名空间添加标签,以启用旧版
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
确认命名空间上的修订版本标签与旧版
istiod
的修订版本标签一致:kubectl get ns NAMESPACE --show-labels
重启 pod 以触发重新注入,以使代理具有之前的版本:
kubectl rollout restart deployment -n NAMESPACE
移除新的
istio-ingressgateway
部署。确保以下命令中的REVISION
值正确无误。kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
移除新版
istiod
。确保以下命令中的REVISION
值正确无误。kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
移除新版
IstioOperator
配置。kubectl delete IstioOperator installed-state-REVISION -n istio-system
预期输出如下所示:
istiooperator.install.istio.io "installed-state-REVISION" deleted
如果您未添加
--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 的访问权限中所述的限制性更强的角色。
在 Google Cloud 控制台中,前往 Anthos Service Mesh。
从菜单栏的下拉列表中选择 Google Cloud 项目。
如果您有多个服务网格,请从服务网格下拉列表中选择相应网格。
如需了解详情,请参阅在 Google Cloud 控制台中探索 Anthos Service Mesh。
除了 Anthos Service Mesh 页面,系统还会将与服务相关的指标(例如特定服务收到的请求数)发送到 Cloud Monitoring,这些指标显示在 Cloud Monitoring 的 Metrics Explorer 中。
如需查看指标,请执行以下操作:
在 Google Cloud 控制台中,转到监控页面:
选择资源 > Metrics Explorer。
如需查看指标的完整列表,请参阅 Cloud Monitoring 文档中的 Istio 指标。