将 Apigee Hybrid 升级到 1.8 版

Apigee 入站流量网关简介

从 1.8 版开始，Apigee Hybrid 提供了一种新功能，用于管理 Hybrid 安装的入站流量网关：Apigee 入站流量网关。Anthos Service Mesh 不再是 Hybrid 安装的前提条件。有了 Apigee 入站流量网关，Apigee 无需再向 Anthos Service Mesh 提供路由配置。升级后，您必须将流量迁移到新的 Apigee 入站流量网关，然后才能开始使用该功能。

Apigee 为入站流量网关使用一小部分 Anthos Service Mesh 功能。从 1.8 版开始，Apigee Hybrid 包含入站流量网关，该网关在 Apigee Hybrid 升级过程中安装和升级。因此，您无需围绕 Anthos Service Mesh 构建专业知识来安装、升级和管理 Apigee Hybrid。系统会自动处理有关入站流量网关版本以及与 Apigee Hybrid 版本的兼容性问题。

迁移的两种场景如下：

多集群或多区域迁移（推荐）：
在切换到新的 Ingress for Apigee 之前，请将所有流量从要迁移的集群排空到其他集群或区域。这样，您就有时间测试新的 Apigee 入站流量网关是否按预期工作。然后，将流量迁移回升级后的集群。
就地升级（生产环境中不推荐）：
升级期间，Apigee 会使用指定的 IP 地址启动新的入站流量网关。然后，您可以测试新的 Apigee 入站流量网关是否按预期工作，然后将流量迁移到新的入站流量网关。此升级过程中可能会出现停机。

将 Apigee Hybrid 升级到 1.8 版时，您必须在替换文件中配置 Apigee 入站流量网关。升级后，您可以将注册商处的 A 记录或 CNAME 记录定向到 Apigee 入站流量网关或 Anthos Service Mesh 的 IP 地址，从而控制集群要使用的入站流量网关类型。

升级到 1.8.8 版概览

升级到 Apigee Hybrid 1.8 版可能需要停机。

将 Apigee 控制器升级到 1.8.8 版时，所有 Apigee 部署都将执行滚动式重启。为了最大限度地减少滚动重启期间生产混合环境中的停机时间，请确保您至少（在相同或不同的区域/数据中心）运行两个集群。将所有生产流量转移到单个集群并且让您要升级的集群下线，然后继续执行升级过程。对每个集群重复执行此过程。

Apigee 建议您尽快升级所有集群，以降低影响生产的可能性。第一个集群升级后，其余所有集群必须在何时升级是没有限制的。但是，在所有剩余集群升级之前，以下操作将受到影响：

Cassandra 备份和恢复不能跨越版本。例如，来自 Hybrid 1.7 的备份不能用于恢复 Hybrid 1.8 实例。
Cassandra 数据流无法跨越不同的 Hybrid 版本。因此，Cassandra 集群无法横向扩缩。
区域扩展和停用会受到影响，因为这些操作依赖于 Cassandra 数据流。

以下各部分介绍升级 Apigee Hybrid 的过程：

准备升级。
安装 Hybrid 运行时 1.8.8 版。
对于入站流量网关，请选择以下选项之一：
- （推荐）使用新的 Apigee 入站流量网关，请按照将流量从 Anthos Service Mesh 切换到 Apigee 入站流量网关部分所述步骤操作。
- 继续使用 Anthos Service Mesh 来提供入站流量网关。

前提条件

以下升级说明假定您已安装 Apigee Hybrid 1.7.x 版或更早的 1.8.x 补丁版本，并希望升级到 1.8.8 版。如果您要从更低版本进行更新，请参阅将 Apigee Hybrid 升级到 1.7 版的说明。

如果您希望继续使用 Anthos Service Mesh，则必须确保将 Anthos Service Mesh 升级到受支持的版本。如需了解支持的 Anthos Service Mesh 版本，请参阅支持的平台表。

准备升级到 1.8 版

备份 Hybrid 安装（推荐）

这些说明将环境变量 APIGEECTL_HOME 用于文件系统中已安装 apigeectl 的目录。如果需要，请切换到 apigeectl 目录，然后使用以下命令定义变量：
Linux
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
echo %APIGEECTL_HOME%
```

创建 1.7 版 $APIGEECTL_HOME/ 目录的备份副本。例如：

tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME

按照 Cassandra 备份和恢复中的说明备份 Cassandra 数据库。

将 Cloud Trace Agent 角色添加到 Apigee 运行时的服务账号。（可选）

可选：如果您打算使用 Cloud Trace，并且尚未在 Hybrid v1.7 安装中执行此步骤，请确保 Apigee 运行时服务的服务账号具有 Cloud Trace Agent Google 角色。(roles/cloudtrace.agent)。

对于生产环境，这通常是 apigee-runtime 服务账号。对于非生产环境，这通常是 apigee-non-prod 服务账号。

您可以在 Cloud 控制台 > IAM 和管理 > 服务账号界面中或使用以下命令添加此角色：

使用以下命令获取服务账号的电子邮件地址：
生产
```
gcloud iam service-accounts list --filter "apigee-runtime"
```
如果它与模式 apigee-runtime@$ORG_NAME.iam.gserviceaccount.com 匹配，您可以在下一步中使用该模式。
非生产
```
gcloud iam service-accounts list --filter "apigee-non-prod"
```
如果它与模式 apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com 匹配，您可以在下一步中使用该模式。

将 Cloud Trace Agent 角色分配给服务账号：

生产

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-runtime@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

非生产

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-non-prod@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

示例

gcloud projects add-iam-policy-binding hybrid-example-project \
    --member="serviceAccount:apigee-runtime@hybrid-example-project.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

其中，$PROJECT_ID 是安装了 Apigee Hybrid 的 Google Cloud 项目的名称。

注意：如果安装使用服务账号的自定义名称，请将该命令中的 apigee-runtime 或 apigee-non-prod 替换为该名称。

准备安装 Apigee 入站流量网关

如需在升级过程中安装 Apigee 入站流量网关，您需要将以下 ingressGateways 属性添加到替换文件中。

语法

ingressGateways:
- name: INGRESS_NAME
  replicaCountMin: REPLICAS_MIN
  replicaCountMax: REPLICAS_MAX
  resources:
    requests:
      cpu: CPU_COUNT_REQ
      memory: MEMORY_REQ
    limits:
      cpu: CPU_COUNT_LIMIT
      memory: MEMORY_LIMIT
  svcAnnotations:  # optional. See Known issue 243599452.
    SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE
  svcLoadBalancerIP: SVC_LOAD_BALANCER_IP # optional

示例

ingressGateways:
- name: prod1
  replicaCountMin: 2
  replicaCountMax: 100
  resources:
    requests:
      cpu: 1
      memory: 1Gi
    limits:
      cpu: 2
      memory: 2Gi

INGRESS_NAME 是入站流量部署的名称。该字段可以是满足以下要求的任何名称：
- 长度不得超过 17 个字符
- 只能包含小写字母数字字符、“-”或“.”
- 以字母数字字符开头
- 以字母数字字符结尾
请参阅配置属性参考文档中的 ingressGateways[].name。
REPLICAS_MIN 和 REPLICAS_MAX 是安装中 Apigee 入站流量网关的最小和最大副本数。如需了解详情和默认设置，请参阅配置属性参考文档中的 ingressGateways[].replicaCountMin 和 ingressGateways[].replicaCountMax。
CPU_COUNT_REQ 和 MEMORY_REQ 是安装中每个 Apigee 入站流量网关副本的 CPU 和内存请求。
只有在您先前已为 Anthos Service Mesh 入站流量网关设置了这些属性的情况下（例如在 overlay.yaml 文件中）才设置它们。
如需了解详情和默认设置，请参阅配置属性参考文档中的 ingressGateways[].resources.requests.cpu 和 ingressGateways[].resources.requests.memory。
CPU_COUNT_LIMIT 和 MEMORY_LIMIT：安装中每个 Apigee 入站流量网关副本的 CPU 和内存上限。
只有在您先前已为 Anthos Service Mesh 入站流量网关设置了这些属性的情况下（例如在 overlay.yaml 文件中）才设置它们。
如需了解详情和默认设置，请参阅配置属性参考文档中的 ingressGateways[].resources.limits.cpu 和 ingressGateways[].resources.limits.memory。
SVC_ANNOTATIONS_KEY 和 SVC_ANNOTATIONS_VALUE（可选）：
注意：overrides.yaml 中的 ingressGateways[].svcAnnotations 字段未按预期起作用。请参阅已知问题 243599452
。
这是一个键值对，用于为默认入站流量服务提供注解。云平台会使用注解来帮助您配置 Hybrid 安装，例如将 loadbalancer 类型设置为内部或外部。例如：
```
ingressGateways:
  svcAnnotations:
    networking.gke.io/load-balancer-type: "Internal"
```
注解因平台而异。如需了解必需和建议的注解，请参阅平台文档。

注意：如果您要为入站流量部署创建自己的 Kubernetes 服务，则无需设置 Annotations，如公开 Apigee 入站流量网关中所述。
请参阅配置属性参考文档中的 ingressGateways[].svcAnnotations。
SVC_LOAD_BALANCER_IP（可选）可让您为负载均衡器分配静态 IP 地址。在支持指定负载均衡器 IP 地址的平台上，系统会使用此 IP 地址创建负载均衡器。在不允许指定负载均衡器 IP 地址的平台上，系统会忽略此属性。
如果您没有为负载均衡器分配静态 IP 地址，请将此属性从替换文件中排除。

注意：切勿指定与当前 istio-ingressgateway 相同的 IP 地址。当该服务仍在集群上时，这可能会导致问题。
注意：如果您要为入站流量部署创建自己的 Kubernetes 服务，则无需设置 LoadBalancerIP，如公开 Apigee 入站流量网关中所述。
请参阅配置属性参考文档中的 ingressGateways[].svcLoadBalancerIP。

对替换文件进行其他更改以启用或停用可选的 v1.8 功能

将以下属性添加到 overrides.yaml 文件以在 Hybrid v1.8 中启用新功能。这些功能都是可选功能。

组织级 UDCA 现在会默认启用。使用单个 UDCA 部署来处理所有环境的流量，从而防止 UDCA pod 利用率过低，并为其他 Apigee 组件提高节点资源的可用性。组织级 UDCA 在所有环境中都使用一个服务账号，即 apigee-udca。
如果您要在不同环境中为 UDCA 使用不同的服务账号，请注意 UDCA 现在会使用替换文件中通过 udca:serviceAccountPath 在组织级别指定的服务账号，而不是通过 envs:udca:serviceAccountPath 在环境级别指定的服务账号。

Apigee Hybrid v1.8 支持环境范围的 UDCA。如需保留每种环境的 UDCA，请设置 orgScopedUDCA: false。

注意：未来版本的 Apigee Hybrid 不支持环境范围的 UDCA。
请参阅配置属性参考文档中的 orgScopedUDCA。
启用 validateOrg 以严格要求验证 Apigee 组织和环境是否处于活动状态，并且使用 overrides 文件中指定的 Google Cloud Platform 项目。
```
validateOrg: true
```
注意：Apigee Hybrid 允许不使用严格的组织验证。若要关闭该验证功能，请设置 validateOrg: false。

请参阅配置属性参考文档中的 validateOrg。

安装 Hybrid 1.8.8 运行时

确保您位于 Hybrid 基本目录中（apigeectl 可执行文件所在目录的父级目录）：
```
cd $APIGEECTL_HOME/..
```

使用以下命令下载适用于您的操作系统的软件包版本。请务必在下表中选择您的平台：

Linux

Linux 64 位：

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_linux_64.tar.gz

Mac OS

Mac 64 位：

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_mac_64.tar.gz

Windows

Windows 64 位

curl -LO ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_windows_64.zip

将当前 apigeectl/ 目录重命名为备份目录名称。例如：

Linux

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

Mac OS

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

Windows

rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.7

将下载的 gzip 文件内容解压缩到 Hybrid 基本目录中。 Hybrid 基本目录是重命名后的 apigeectl-v1.7 目录所在的目录：
Linux
```
tar xvzf filename.tar.gz -C ./
```
Mac OS
```
tar xvzf filename.tar.gz -C ./
```
Windows
```
tar xvzf filename.zip -C ./
```
默认情况下，tar 内容会扩展到其名称中包含版本和平台的目录。例如：./apigeectl_1.8.8-xxxxxxx_linux_64。使用以下命令将该目录重命名为 apigeectl：
Linux
```
mv apigeectl_1.8.8-xxxxxxx_linux_64 apigeectl
```
Mac OS
```
mv apigeectl_1.8.8-xxxxxxx_mac_64 apigeectl
```
Windows
```
rename apigeectl_1.8.8-xxxxxxx_windows_64 apigeectl
```
切换到 apigeectl 目录：
```
cd ./apigeectl
```
此目录是 apigeectl 主目录。它是 apigeectl 可执行命令所在的位置。
以下说明将环境变量 $APIGEECTL_HOME 用于文件系统中安装 apigeectl 实用程序的目录。如果需要，请切换到 apigeectl 目录，然后使用以下命令定义变量：
Linux
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
```
```
echo %APIGEECTL_HOME%
```
使用 version 命令验证 apigeectl 的版本：
```
./apigeectl version
```
```
Version: 1.8.8
```
移至 hybrid-base-directory/hybrid-files 目录。hybrid-files 目录是替换文件、证书和服务账号等配置文件所在的位置。例如：
```
cd $APIGEECTL_HOME/../hybrid-files
```
使用以下命令验证 kubectl 是否设置为正确的上下文。当前上下文应设置为您要在其中升级 Apigee Hybrid 的集群。
```
kubectl config get-contexts | grep \*
```
在 hybrid-files 目录中：
1. 将以下符号链接更新为 $APIGEECTL_HOME。这些链接使您可以从 hybrid-files 目录中运行新安装的 apigeectl 命令：
```
ln -nfs $APIGEECTL_HOME/tools tools
ln -nfs $APIGEECTL_HOME/config config
ln -nfs $APIGEECTL_HOME/templates templates
ln -nfs $APIGEECTL_HOME/plugins plugins
```
2. 要检查符号链接是否正确创建，请执行以下命令，并确保链接路径指向正确的位置：
```
ls -l | grep ^l
```
执行试运行初始化以检查是否存在错误：
```
${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client
```
其中，OVERRIDES_FILE 是替换文件的名称，例如 ./overrides/overrides.yaml。

提示：您可以将上述代码示例中的 OVERRIDES_FILE 替换为替换文件的名称和路径，并且此页面上的每个实例都会被替换。
如果没有错误，请初始化 Hybrid 1.8.8。此命令还会安装并配置 Apigee 入站流量网关：
```
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
```
检查初始化状态：
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
成功后，输出会显示 All containers ready.：

已知问题：运行 init 并确认 check-ready 成功后，如果您查看 Pod，则可能会注意到 Cassandra 架构验证处于错误状态。此状态被视为已知问题 (#245664917) 且无害。您可以放心地忽略该错误并继续执行下一步：apigeectl apply。
为了进一步检查，您还可以运行以下命令来检查 ApigeeDataStore 状态：
```
kubectl describe apigeeds -n apigee
```
在输出中，查找 State: running。
使用 --dry-run 标志，通过试运行 apply 命令检查是否存在错误：
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
```
如果没有错误，则应用替换文件。选择生产环境或非生产环境的相关说明并按照这些说明操作，具体取决于您的安装。
在升级过程中，每个组件都会执行滚动式重启。因此，对于生产环境，最好每次将升级应用于一个组件。
生产环境

对于生产环境，您应该单独升级每个 Hybrid 组件，并检查升级后的组件的状态，再继续升级下一个组件。
1. 确保您位于 hybrid-files 目录中。
2. 应用替换文件以升级 Cassandra：
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
3. 检查完成情况：
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  提示：如果 check-ready 失败，您可以使用以下命令获取有关 pod 的更多信息：
  kubectl -n NAMESPACE get pods
  
  其中，NAMESPACE 是您的 Apigee Hybrid 命名空间。
  仅当 Pod 准备就绪后，才继续执行下一步。
4. 应用替换文件以升级遥测组件和检查完成情况：
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
5. 启动 Redis 组件：
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
6. 应用替换文件以升级组织层级组件（MART、Watcher 和 Apigee Connect）并检查完成情况：
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
7. 应用替换文件以升级您的环境。您有以下两种选择：
  - 对每个环境逐一应用：每次将替换文件应用于一个环境，然后检查完成情况。对每个环境重复执行此步骤：
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    
    其中，ENV_NAME 是您要升级的环境的名称。
  - 同时应用于所有环境：将替换文件同时应用于所有环境，然后检查完成情况：
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
8. 应用替换文件以升级 virtualhosts 组件并检查完成情况：
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
非生产

在大多数非生产、演示或实验环境中，您可以将替换文件同时应用于所有组件。如果您的非生产环境大且复杂或非常类似于生产环境，则可能需要使用升级生产环境的说明。
1. 确保您位于 hybrid-files 目录中。
2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
3. 检查状态：
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

升级 Kubernetes 版本

将 Kubernetes 平台升级到 Hybrid 1.8 支持的版本。如需帮助，请参阅该平台的相关文档。

点击即可展开支持的平台列表

	Apigee Hybrid 版本
平台	1.6 ⁽³⁾	1.7 ⁽³⁾	1.8 ⁽³⁾	1.9	1.10
Anthos (Google Cloud - GKE)	1.19.x 1.20.x 1.21.x	1.20.x 1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.21.x ^{(≤ 1.8.3)} 1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
Anthos (AWS)	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.25⁽¹³⁾	1.12.x 1.13.x 1.25⁽¹³⁾	1.13.x 1.25⁽¹³⁾ 1.26⁽¹³⁾
Anthos (Azure)	1.8.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.15.x
Anthos（本地 - VMware）⁽¹⁾	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x ⁽⁴⁾ 1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ 1.12.x ⁽⁴⁾ ⁽⁵⁾ 1.13.x ⁽⁵⁾ 1.14.x ⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
Anthos (Bare Metal)⁽¹⁾	1.7.x 1.8.2+ 1.9.3+ 1.10.x	1.9.x ⁽⁴⁾ 1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ 1.12.x ⁽⁴⁾ ⁽⁵⁾ 1.13.x ⁽⁵⁾ 1.14.x ⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
EKS⁽⁷⁾	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
AKS⁽⁷⁾	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
OpenShift⁽⁷⁾	4.6 4.7 4.8	4.7 4.8	4.8 4.9 4.10	4.10 4.11	4.11 4.12
Rancher Kubernetes Engine (RKE)⁽⁷⁾	不适用	不适用	不适用	1.3.8	v1.26.2+rke2r1
组件	1.6 ⁽³⁾	1.7 ⁽³⁾	1.8	1.9	1.10
Anthos Service Mesh (ASM)	1.9.x 1.10.x 1.12.x 1.13.x	1.10.x 1.11.x 1.12.x 1.13.x ^{(≥ 1.7.2)} 1.14.x 1.15.x ^{(≥ 1.7.6)}	1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	1.17.x⁽¹¹⁾	1.17.x⁽¹¹⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.5.4	1.7.x	1.7.x 1.8.x 1.9.x 1.10.x 1.11.x	1.10.x 1.11.x	1.10.x 1.11.x 1.12.x
Cassandra	3.11.10	3.11.10	3.11.10	3.11.10	3.11.10
⁽¹⁾ 在 Anthos 1.8、1.9 和 1.10 版中，请按照这些文档中的说明操作，以避免与 `cert-manager` 发生冲突： Anthos 1.8.2+：升级到 1.8.2 或更高版本时，与 `cert-manager` 发生冲突。 Anthos 1.9：升级到 1.9.0 或 1.9.1 版时，与 `cert-manager` 发生冲突。 Anthos 1.10+：有冲突的 `cert-manager` 安装。 ⁽²⁾ Apigee Hybrid 1.7.2 版及更高版本提供支持。 ⁽³⁾ Apigee Hybrid 1.8 版及更低版本已达到官方服务终止 (EOL) 日期。定期每月发布的补丁将不再提供。这些版本不再受官方支持，但存在可以继续获得支持的明确的官方例外情况的客户除外。其他客户必须升级。 ⁽⁴⁾ Anthos on Bare Metal 和 VMWare 1.12 版及更低版本不再受支持。请参阅 Anthos on Bare Metal 版本支持政策和 Anthos Clusters on VMware 版本。 ⁽⁵⁾ Anthos on Bare Metal 和 VMWare 需要 ASM 1.14 或更高版本。我们建议您升级到 Hybrid v1.8 并切换到 Apigee 入站流量网关，该网关不再需要您在混合集群上安装 ASM。 ⁽⁶⁾ Apigee Hybrid 1.8.4 版及更高版本提供支持。 ⁽⁷⁾ 对于使用 Apigee 入站流量网关的 Apigee Hybrid v1.8 及更高版本，关联集群不是必需的。 ⁽⁸⁾ Apigee Hybrid 1.8.4 版及更高版本不支持。 ⁽⁹⁾ Apigee Hybrid 1.7.6 版及更高版本提供支持。 ⁽¹⁰⁾ Apigee Hybrid 1.8.5 版及更高版本不支持。 ⁽¹¹⁾ ASM 会自动与 Apigee Hybrid 1.9 及更高版本一起安装。 ⁽¹²⁾ Apigee Hybrid 1.9.2 版及更高版本提供支持。 ⁽¹³⁾ Anthos Clusters on AWS（多云）版本号现在反映了 Kubernetes 版本。请参阅 Anthos 版本和升级支持了解版本详细信息和推荐的补丁。

关联集群简介

对于 Apigee Hybrid 1.7.x 版及更早版本，如果您要在 Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS) 或其他受支持的第三方 Kubernetes 服务提供商的多云环境中运行 Apigee Hybrid，则必须使用 Anthos 关联的集群。集群关联使 Google 可以衡量 Anthos Service Mesh (ASM) 的使用情况。注册第三方集群是可选选项。仅当您希望在 Google Cloud 控制台中查看关联集群时才应注册。如需了解详情，请参阅将第三方 Kubernetes 集群关联到 Google Cloud。

对于 Apigee Hybrid 1.8.x 版，如果您要将 Anthos Service Mesh 用于入站流量网关，则 Anthos 关联的集群是必需的。如果您使用的是 Apigee 入站流量网关，则 Anthos 关联的集群是可选的。

将流量从 Anthos Service Mesh 切换到 Apigee 入站流量网关

如需将流量切换到 Apigee 入站流量网关，请执行以下操作：

公开 Apigee 入站流量网关。按照公开 Apigee 入站流量网关中的步骤操作。
通过调用代理来测试新的入站流量网关。理想情况下，应测试当前已部署的所有关键代理。

如需转移流量，请更新 DNS 记录以指向新的 Apigee 入站流量网关的 IP 地址。您也许可以将流量逐步转移到新端点，具体取决于您的 DNS 提供商。提示：您可以使用以下命令找到 Apigee 入站流量网关的外部 IP 地址：

kubectl get svc -n apigee -l app=apigee-ingressgateway

输出应如下所示：

NAME                                        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
apigee-ingressgateway-prod-hybrid-37a39bd   LoadBalancer   192.0.2.123   233.252.0.123   15021:32049/TCP,80:31624/TCP,443:30723/TCP   16h

监控信息中心，确保所有运行时流量都正常。在确保所有流量都正常后，再继续执行下一步操作。此外，您还需确保没有流量通过旧的入站流量网关 (Anthos Service Mesh)，因为 DNS 更新可能会因 DNS 缓存而传播缓慢。
如需让 Apigee 停止向 Anthos Service Mesh 提供配置，请按照“管理 Apigee 入站流量网关”指南中的停止向 ASM 提供配置部分所述步骤操作。
重新测试和监控 API 代理流量。
按照 Anthos Service Mesh 文档中的说明从集群中卸载 Anthos Service Mesh。

将 Anthos Service Mesh 升级到 1.15 版

按照适合您的平台的 Anthos Service Mesh 文档执行相关步骤：

安装和配置 Anthos Service Mesh 的说明因平台而异。这些平台分为以下几种类别：

GKE：在 Google Cloud 上运行的 Google Kubernetes Engine 集群。
Google Cloud 外部：在以下位置运行的 Anthos 集群：
- Anthos clusters on VMware (GKE on-prem)
- Anthos on Bare Metal
- Anthos clusters on AWS
- Amazon EKS
其他 Kubernetes 平台：在以下平台上创建和运行的合规集群：
- AKS
- EKS
- OpenShift

GKE

为 Hybrid 安装升级到 Anthos Service Mesh 1.13.9 版的顺序如下：

准备升级。
安装新版本的 Anthos Service Mesh。
从当前安装中删除先前 Anthos Service Mesh 版本的部署、服务和 webhook。
升级网关并配置新的网络钩子。

准备将 Anthos Service Mesh 升级到 1.13.9版

查看升级 Anthos Service Mesh 中的要求，但尚不执行升级。
在安装新版本之前，确定当前修订版本。您需要使用此信息从当前安装中删除先前 Anthos Service Mesh 版本的部署、服务和 webhook。使用以下命令将当前 istiod 修订版本存储到环境变量中：
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
输出应类似于 1.12.9-asm.2

注意：如果该命令返回多个值，请将 DELETE_REV 的值设置为最早版本并按照相关步骤删除最早版本，然后重复该过程直到删除所有版本。

创建新的 overlay.yaml 文件，或验证现有 overlay.yaml 是否包含以下内容：

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

按照 Anthos Service Mesh 文档中以下部分的说明操作：
重要提示：请务必按照这些说明使用可选功能升级 Anthos Service Mesh 并添加 overlay.yaml。
1. 下载 asmcli
2. 授予集群管理员权限
3. 验证项目和集群
4. 使用可选功能升级。在开始执行“升级网关”部分之前停止。
切换到新的控制平面：
1. 获取 istiod 上的修订版本标签：
```
kubectl get pod -n istio-system -L istio.io/rev
```
  此命令的输出类似如下所示。
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. 将更新的修订版本标签分配给环境变量。
  在输出中的 REV 列下，记下新版本的修订版本标签的值。在此示例中，该值为 asm-1139-10。
```
export UPGRADE_REV="REVISION_LABEL"
```
3. 将修订版本标签添加到 istio-system 命名空间，并使用以下命令移除 istio-injection 标签（如果存在）。
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV 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 istio-system
```
5. 测试您的应用，验证工作负载是否正常工作。
6. 如果您的其他命名空间中存在工作负载，请重复上述步骤以标记命名空间并重启 Pod。

删除先前的版本：

进入 asmcli 的安装目录。
将 Anthos Service Mesh 安装的输出目录存储在 DIR_PATH 环境变量中。此目录与您在使用可选功能升级过程中指定的目录相同。
```
export DIR_PATH=OUTPUT_DIR
```

创建一个包含以下命令的 Shell 脚本：

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

执行此脚本以删除先前版本。

Google Cloud 外部

下面的说明介绍了如何在以下各项上升级 Anthos Service Mesh：

Anthos clusters on VMware (GKE on-prem)
Anthos on Bare Metal
Anthos clusters on AWS
Amazon EKS

为 Hybrid 安装升级到 Anthos Service Mesh 1.13.9 版的顺序如下：

准备升级。
安装新版本的 Anthos Service Mesh。
从当前安装中删除先前 Anthos Service Mesh 版本的部署、服务和 webhook。
升级网关并配置新的网络钩子。

准备将 Anthos Service Mesh 升级到 1.13.9版

查看升级 Anthos Service Mesh 中的要求，但尚不执行升级。
在安装新版本之前，确定当前修订版本。您需要使用此信息从当前安装中删除先前 Anthos Service Mesh 版本的部署、服务和 webhook。使用以下命令将当前 istiod 修订版本存储到环境变量中：
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
输出应类似于 1.12.9-asm.2

注意：如果该命令返回多个值，请将 DELETE_REV 的值设置为最早版本并按照相关步骤删除最早版本，然后重复该过程直到删除所有版本。

创建新的 overlay.yaml 文件，或验证现有 overlay.yaml 是否包含以下内容：

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:  
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  values:
    gateways:
      istio-ingressgateway:
        runAsRoot: true

  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

按照 Anthos Service Mesh 文档中以下部分的说明操作：
重要提示：请务必按照这些说明使用可选功能升级 Anthos Service Mesh 并添加 overlay.yaml。
1. 下载 asmcli
2. 授予集群管理员权限
3. 验证项目和集群
4. 使用可选功能升级。在开始执行“升级网关”部分之前停止。
切换到新的控制平面：
1. 获取 istiod 上的修订版本标签：
```
kubectl get pod -n istio-system -L istio.io/rev
```
  此命令的输出类似如下所示。
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. 将更新的修订版本标签分配给环境变量。
  在输出中的 REV 列下，记下新版本的修订版本标签的值。在此示例中，该值为 asm-1139-10。
```
export UPGRADE_REV="REVISION_LABEL"
```
3. 将修订版本标签添加到 istio-system 命名空间，并使用以下命令移除 istio-injection 标签（如果存在）。
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV 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 istio-system
```
5. 测试您的应用，验证工作负载是否正常工作。
6. 如果您的其他命名空间中存在工作负载，请重复上述步骤以标记命名空间并重启 Pod。

删除先前的版本：

进入 asmcli 的安装目录。
将 Anthos Service Mesh 安装的输出目录存储在 DIR_PATH 环境变量中。此目录与您在使用可选功能升级过程中指定的目录相同。
```
export DIR_PATH=OUTPUT_DIR
```

创建一个包含以下命令的 Shell 脚本：

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

执行此脚本以删除先前版本。

AKS / EKS

在这些说明中，在 Anthos 关联的集群上升级 Anthos Service Mesh (Anthos Service Mesh) istio-1.13.9-asm.10 版的过程与执行全新安装的过程相同。

准备安装 Anthos Service Mesh

在安装新版本之前，确定当前修订版本。您需要使用此信息从当前 Anthos Service Mesh 安装中删除验证 webhook 和更改 webhook。使用以下命令将当前 istiod 修订版本存储到环境变量中：
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
输出应类似于 1.12.9-asm.2

注意：如果该命令返回多个值，请将 DELETE_REV 的值设置为最早版本并按照相关步骤删除最早版本，然后重复该过程直到删除所有版本。

Linux

将 Anthos Service Mesh 安装文件下载到当前工作目录中：

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz

下载签名文件并使用 OpenSSL 验证签名：

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

将文件内容提取到文件系统上的任意位置。例如，如需将内容提取到当前工作目录，请运行以下命令：

tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

该命令会在当前工作目录中创建一个名为 istio-1.13.9-asm.10 的安装目录，其中包含：

samples 目录中的示例应用。
用于安装 Anthos Service Mesh 的 istioctl 命令行工具位于 bin 目录中。
Anthos Service Mesh 配置文件位于 manifests/profiles 目录中。

确保您位于 Anthos Service Mesh 安装的根目录。

cd istio-1.13.9-asm.10

为方便起见，请将 /bin 目录中的工具添加到 PATH：

export PATH=$PWD/bin:$PATH

Mac OS

将 Anthos Service Mesh 安装文件下载到当前工作目录中：

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz

下载签名文件并使用 OpenSSL 验证签名：

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

将文件内容提取到文件系统上的任意位置。例如，如需将内容提取到当前工作目录，请运行以下命令：

tar xzf istio-1.13.9-asm.10-osx.tar.gz

该命令会在当前工作目录中创建一个名为 istio-1.13.9-asm.10 的安装目录，其中包含：

samples 目录中的示例应用。
用于安装 Anthos Service Mesh 的 istioctl 命令行工具位于 bin 目录中。
Anthos Service Mesh 配置文件位于 manifests/profiles 目录中。

确保您位于 Anthos Service Mesh 安装的根目录。

cd istio-1.13.9-asm.10

为方便起见，请将 /bin 目录中的工具添加到 PATH：

export PATH=$PWD/bin:$PATH

Windows

将 Anthos Service Mesh 安装文件下载到当前工作目录中：

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip

下载签名文件并使用 OpenSSL 验证签名：

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig

openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

将文件内容提取到文件系统上的任意位置。例如，如需将内容提取到当前工作目录，请运行以下命令：

tar xzf istio-1.13.9-asm.10-win.zip

该命令会在当前工作目录中创建一个名为 istio-1.13.9-asm.10 的安装目录，其中包含：

samples 目录中的示例应用。
用于安装 Anthos Service Mesh 的 istioctl 命令行工具位于 bin 目录中。
Anthos Service Mesh 配置文件位于 manifests\profiles 目录中。

确保您位于 Anthos Service Mesh 安装的根目录。

cd istio-1.13.9-asm.10

为方便起见，请将 \bin 目录中的工具添加到 PATH：

set PATH=%CD%\bin:%PATH%

现在，Anthos Service Mesh Istio 已安装，请检查 istioctl 的版本：
```
istioctl version
```
为控制平面组件创建一个名为 istio-system 的命名空间：
```
kubectl create namespace istio-system
```

安装 Anthos Service Mesh

修改 overlay.yaml 文件或创建包含以下内容的新文件：

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        service:
          type: LoadBalancer
          ports:
          - name: status-port
            port: 15021
            targetPort: 15021
          - name: http2
            port: 80
            targetPort: 8080
          - name: https
            port: 443
            targetPort: 8443

使用 asm-multicloud 配置文件，利用 istioctl 来安装 Anthos Service Mesh：

istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1139-10" \
    --filename overlay.yaml

输出应如下所示：

kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s

--set revision 参数会将格式为 istio.io/rev=asm-1139-10 的修订版本标签添加到 istiod。自动边车注入器网络钩子使用修订版本标签将注入的边车与特定 istiod 修订版本相关联。如需为命名空间启用边车自动注入功能，您必须使用一个与 istiod 上的标签匹配的修订版本来为其添加标签。

验证安装是否已完成：

kubectl get svc -n istio-system

输出应如下所示：

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

切换到新的控制平面：
1. 获取 istiod 上的修订版本标签：
```
kubectl get pod -n istio-system -L istio.io/rev
```
  此命令的输出类似如下所示。
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. 将更新的修订版本标签分配给环境变量。
  在输出中的 REV 列下，记下新版本的修订版本标签的值。在此示例中，该值为 asm-1139-10。
```
export UPGRADE_REV="REVISION_LABEL"
```
3. 将修订版本标签添加到 istio-system 命名空间，并使用以下命令移除 istio-injection 标签（如果存在）。
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV 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 istio-system
```
5. 测试您的应用，验证工作负载是否正常工作。
6. 如果您的其他命名空间中存在工作负载，请重复上述步骤以标记命名空间并重启 Pod。

删除先前的版本：

创建一个包含以下命令的 Shell 脚本：

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

执行此脚本以删除先前版本。

OpenShift

在这些说明中，在 Anthos 关联的集群上升级 Anthos Service Mesh (Anthos Service Mesh) istio-1.13.9-asm.10 版的过程与执行全新安装的过程相同。

准备安装 Anthos Service Mesh

在安装新版本之前，确定当前修订版本。您需要使用此信息从当前 Anthos Service Mesh 安装中删除验证 webhook 和更改 webhook。使用以下命令将当前 istiod 修订版本存储到环境变量中：
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
输出应类似于 1.12.9-asm.2

注意：如果该命令返回多个值，请将 DELETE_REV 的值设置为最早版本并按照相关步骤删除最早版本，然后重复该过程直到删除所有版本。

Linux

使用以下 OpenShift CLI (oc) 命令向 istio-system 授予 anyuid 安全上下文限制条件 (SCC)：

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

将 Anthos Service Mesh 安装文件下载到当前工作目录中：

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz

下载签名文件并使用 OpenSSL 验证签名：

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

将文件内容提取到文件系统上的任意位置。例如，如需将内容提取到当前工作目录，请运行以下命令：

tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

该命令会在当前工作目录中创建一个名为 istio-1.13.9-asm.10 的安装目录，其中包含：

samples 目录中的示例应用。
用于安装 Anthos Service Mesh 的 istioctl 命令行工具位于 bin 目录中。
Anthos Service Mesh 配置文件位于 manifests/profiles 目录中。

确保您位于 Anthos Service Mesh 安装的根目录。

cd istio-1.13.9-asm.10

为方便起见，请将 /bin 目录中的工具添加到 PATH：

export PATH=$PWD/bin:$PATH

Mac OS

使用以下 OpenShift CLI (oc) 命令向 istio-system 授予 anyuid 安全上下文限制条件 (SCC)：

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

将 Anthos Service Mesh 安装文件下载到当前工作目录中：

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz

下载签名文件并使用 OpenSSL 验证签名：

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

将文件内容提取到文件系统上的任意位置。例如，如需将内容提取到当前工作目录，请运行以下命令：

tar xzf istio-1.13.9-asm.10-osx.tar.gz

该命令会在当前工作目录中创建一个名为 istio-1.13.9-asm.10 的安装目录，其中包含：

samples 目录中的示例应用。
用于安装 Anthos Service Mesh 的 istioctl 命令行工具位于 bin 目录中。
Anthos Service Mesh 配置文件位于 manifests/profiles 目录中。

确保您位于 Anthos Service Mesh 安装的根目录。

cd istio-1.13.9-asm.10

为方便起见，请将 /bin 目录中的工具添加到 PATH：

export PATH=$PWD/bin:$PATH

Windows

使用以下 OpenShift CLI (oc) 命令向 istio-system 授予 anyuid 安全上下文限制条件 (SCC)：

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

将 Anthos Service Mesh 安装文件下载到当前工作目录中：

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip

下载签名文件并使用 OpenSSL 验证签名：

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig

openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

将文件内容提取到文件系统上的任意位置。例如，如需将内容提取到当前工作目录，请运行以下命令：

tar xzf istio-1.13.9-asm.10-win.zip

该命令会在当前工作目录中创建一个名为 istio-1.13.9-asm.10 的安装目录，其中包含：

samples 目录中的示例应用。
用于安装 Anthos Service Mesh 的 istioctl 命令行工具位于 bin 目录中。
Anthos Service Mesh 配置文件位于 manifests\profiles 目录中。

确保您位于 Anthos Service Mesh 安装的根目录。

cd istio-1.13.9-asm.10

为方便起见，请将 \bin 目录中的工具添加到 PATH：

set PATH=%CD%\bin:%PATH%

现在，Anthos Service Mesh Istio 已安装，请检查 istioctl 的版本：
```
istioctl version
```
为控制平面组件创建一个名为 istio-system 的命名空间：
```
kubectl create namespace istio-system
```

配置验证网络钩子

安装 Anthos Service Mesh 时，您可以在 istiod 上设置修订版本标签。您需要在验证网络钩子上设置相同的修订版本。

创建一个名为 istiod-service.yaml 且包含以下内容的文件：

apiVersion: v1
kind: Service
metadata:
  name: istiod
  namespace: istio-system
  labels:
    istio.io/rev: asm-1139-10
    app: istiod
    istio: pilot
    release: istio
spec:
  ports:
    - port: 15010
      name: grpc-xds # plaintext
      protocol: TCP
    - port: 15012
      name: https-dns # mTLS with k8s-signed cert
      protocol: TCP
    - port: 443
      name: https-webhook # validation and injection
      targetPort: 15017
      protocol: TCP
    - port: 15014
      name: http-monitoring # prometheus stats
      protocol: TCP
  selector:
    app: istiod
    istio.io/rev: asm-1139-10
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

使用 kubectl 应用验证网络钩子配置：
```
kubectl apply -f istiod-service.yaml
```

验证配置是否已应用：

kubectl get svc -n istio-system

响应应如下所示：

NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
istiod   ClusterIP   172.200.18.133   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   22s

安装 Anthos Service Mesh

修改 overlay.yaml 文件或创建包含以下内容的新文件：

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          service:
            type: LoadBalancer
            ports:
            - name: status-port
              port: 15021
              targetPort: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443

使用 asm-multicloud 配置文件，利用 istioctl 来安装 Anthos Service Mesh：

istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1139-10" \
    --filename overlayfile.yaml

输出应如下所示：

kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s

--set revision 参数会将格式为 istio.io/rev=1.6.11-asm.1 的修订版本标签添加到 istiod。自动边车注入器网络钩子使用修订版本标签将注入的边车与特定 istiod 修订版本相关联。如需为命名空间启用边车自动注入功能，您必须使用一个与 istiod 上的标签匹配的修订版本来为其添加标签。

验证安装是否已完成：

kubectl get svc -n istio-system

输出应如下所示：

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

切换到新的控制平面：
1. 获取 istiod 上的修订版本标签：
```
kubectl get pod -n istio-system -L istio.io/rev
```
  此命令的输出类似如下所示。
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. 将更新的修订版本标签分配给环境变量。
  在输出中的 REV 列下，记下新版本的修订版本标签的值。在此示例中，该值为 asm-1139-10。
```
export UPGRADE_REV="REVISION_LABEL"
```
3. 将修订版本标签添加到 istio-system 命名空间，并使用以下命令移除 istio-injection 标签（如果存在）。
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV 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 istio-system
```
5. 测试您的应用，验证工作负载是否正常工作。
6. 如果您的其他命名空间中存在工作负载，请重复上述步骤以标记命名空间并重启 Pod。

删除先前的版本：

创建一个包含以下命令的 Shell 脚本：

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

执行此脚本以删除先前版本。

回滚升级

要回滚以前的升级，请按以下步骤操作：

清理混合运行时命名空间的已完成作业，其中 NAMESPACE 是替换文件中指定的命名空间（如果您指定了命名空间）。如果没有，则默认命名空间为 apigee：
```
kubectl delete job -n NAMESPACE \
  $(kubectl get job -n NAMESPACE \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

为 apigee-system 命名空间清理已完成作业：

kubectl delete job -n apigee-system \
  $(kubectl get job -n apigee-system \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

更改 APIGEECTL_HOME 变量，使其指向包含先前版本 apigeectl 的目录。例如：
```
export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
```
撤消对 overrides 文件的更改：
1. 移除或注释掉 ingressGateways 及其所有属性。
2. 将 virtualhosts.selector.app 的值设置为先前的值，例如：
```
virtualhosts:
  - name: my-env-group
    selector:
      app: istio-ingressgateway
```
3. 移除或注释掉 ao.args.disableIstioConfigInAPIServer。

在要回滚到的安装的根目录中，运行 apigeectl apply，检查 pod 的状态，然后运行 apigeectl init。对于要回滚到的版本，请务必使用原始替换文件：

在 hybrid-files 目录中，运行 apigeectl apply：
```
$APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE
```
其中，ORIGINAL_OVERRIDES_FILE 是先前 Hybrid 安装版本的替换文件的相对路径和文件名，例如 ./overrides/overrides1.7.yaml。
检查您的 Pod 的状态：
```
kubectl -n NAMESPACE get pods
```
其中，NAMESPACE 是您的 Apigee Hybrid 命名空间。

检查 apigeeds 的状态：

kubectl describe apigeeds -n apigee

输出应如下所示：

Status:
  Cassandra Data Replication:
  Cassandra Pod Ips:
    10.8.2.204
  Cassandra Ready Replicas:  1
  Components:
    Cassandra:
      Last Successfully Released Version:
        Revision:  v1-f8aa9a82b9f69613
        Version:   v1
      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  Scaling:
    In Progress:         false
    Operation:
    Requested Replicas:  0
  State:                 running

仅当 apigeeds pod 正在运行时才继续执行下一步。

运行以下命令，记下升级后消息处理器的新副本计数值。如果这些值与您之前设置的值不匹配，请更改替换文件中的值，以与先前的配置匹配。

apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2

输出应如下所示：

      autoScaler:
        minReplicas: 2
        maxReplicas: 10

如果要回滚到 Hybrid v1.8.4 或更低版本，请删除 Hybrid v1.8.5 及更高版本使用的控制器部署：
```
kubectl -n apigee-system delete deploy apigee-controller-manager
```

运行 apigeectl init：

$APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE

删除 Apigee Ingress 网关管理器部署。此组件仅与 Apigee Hybrid 1.8 及更高版本相关。
```
kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager
```
其中，NAMESPACE 是您的 Apigee Hybrid 命名空间。

将 Apigee Hybrid 升级到 1.8 版

Apigee 入站流量网关简介

升级到 1.8.8 版概览

前提条件

准备升级到 1.8 版

备份 Hybrid 安装（推荐）

Linux

Mac OS

Windows

将 Cloud Trace Agent 角色添加到 Apigee 运行时的服务账号。（可选）

生产

非生产

生产

非生产

示例

准备安装 Apigee 入站流量网关

语法

示例

对替换文件进行其他更改以启用或停用可选的 v1.8 功能

安装 Hybrid 1.8.8 运行时

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

生产环境

非生产

升级 Kubernetes 版本

点击即可展开支持的平台列表

平台

组件

关联集群简介

将流量从 Anthos Service Mesh 切换到 Apigee 入站流量网关

将 Anthos Service Mesh 升级到 1.15 版

GKE

准备将 Anthos Service Mesh 升级到 1.13.9版

Google Cloud 外部

准备将 Anthos Service Mesh 升级到 1.13.9版

AKS / EKS

准备安装 Anthos Service Mesh

Linux

Mac OS

Windows

安装 Anthos Service Mesh

OpenShift

准备安装 Anthos Service Mesh

Linux

Mac OS

Windows

配置验证网络钩子

安装 Anthos Service Mesh

回滚升级