使用 Operator 升级到 Istio 1.6

从 1.6 版开始，Istio on Google Kubernetes Engine 插件使用 Istio 运算符进行安装和配置。Istio Operator 遵循 Kubernetes Operator 模式。Istio Operator 可让您通过为 Istio 安装定义 Kubernetes 自定义资源定义 (CRD) 来配置 Istio。然后，Istio Operator 使用控制器更改安装，以匹配自定义资源。

当您将集群升级到 1.17.9-gke.6300 或更高版本时，Istio 1.6 Operator 和控制层面将与现有的 1.4.x Istio 控制层面一起安装。升级需要用户操作，并按照双重控制层面升级过程（在 Istio 文档中称为 Canary 升级）操作。借助双重控制层面升级，您可以将工作负载上的标签设置为指向新的控制层面并执行滚动式重启，从而迁移到 1.6 版。

我们不会发布 1.5 版 Istio on GKE 插件。1.6 版是我们在 1.4.10 之后发布的版本。

将集群升级到 GKE 1.17 及更高版本会导致内置 Ingress 网关在升级过程中大约 5 分钟内无法使用，并且用户对 Ingress 部署进行的任何修改都将丢失。为避免此问题，我们建议安装和管理单独的用户定义的网关，如添加网关中所述。
注意：从 GKE 1.16 升级到 1.17 以及低于 R33 的 1.18 版时存在一个已知问题。在 1.17.12-gke.1501 版或更高版本以及 1.18.9-gke.1501 版或更高版本中提供了修复。该问题会导致您在 istio-system 命名空间中创建的所有自定义资源在升级期间均被删除。您必须手动重新创建这些资源。确保您只升级到受影响的版本。该问题只会在升级期间发生，因此新集群不受影响。

Istio Operator 的优势

Istio Operator 可提高安装的配置性。在 1.6 之前的插件版本中，GKE 插件管理器会协调对 Istio 清单进行的任何更改，并阻止进行大部分类型的配置更改。Istio Operator 没有此限制。Istio Operator 根据您在安装期间提供的 IstioOperator 自定义资源 (CR) 生成 Istio 控制层面安装清单。该 CR 完全由您掌控，且永不进行协调。

使用 Operator 升级到 Istio 1.6 后，您可以从 Istio on GKE 插件迁移到 Istio 的开源版本。

使用 Operator 升级到 Istio 1.6

您只需执行这些步骤一次即可转换到该 Operator。后续升级将按照双重控制层面升级过程进行。

选择包含 Istio 1.6 的 GKE 版本（1.17.7-gke.8+、1.17.8-gke.6+），然后升级您的集群。

请注意，使用 Istio 1.6 的 Istio on Google Kubernetes Engine 插件会安装两个 Istio 版本：
- 由插件管理器控制的静态清单版本（在升级集群后有效）。
- 由 Operator 控制的 1.6 版（在启用之后有效）。已停用的 1.6 版不会连接到任何代理，且消耗的集群资源可以忽略不计。
如果当前安装的 Istio 版本与目标静态清单中的版本不同，则升级集群可能也会就地升级 Istio。例如，如果您的集群当前正在运行 Istio 1.4.6-gke.0，并且选择 GKE 集群版本 1.17.7-gke.8，则在升级过程中 Istio 控制层面会升级到 1.4.10-gke.0（或更高版本）。

检查 1.6 版的 Istio 是否已安装且正在运行：

kubectl get pods -n istio-system

您应该会看到处于“正在运行”状态的 istiod pod 以及 1.4 控制层面组件，例如：

NAME                                             READY   STATUS      RESTARTS   AGE
istio-citadel-78b9b5b589-52cqg                   1/1     Running     0          4m16s
istio-galley-79bd448645-zxfjm                    1/1     Running     0          4m16s
istio-ingressgateway-b4f8986c4-dbr6c             1/1     Running     0          4m27s
istio-pilot-dc558d859-cnrqt                      2/2     Running     1          4m16s
istio-policy-8664dd6c4-m42xs                     2/2     Running     1          4m15s
istio-security-post-install-1.4.10-gke.4-255r6   0/1     Completed   0          4m15s
istio-sidecar-injector-7f85d7f7c4-vt2x9          1/1     Running     0          4m15s
istio-telemetry-69b6477c5f-4pr6v                 2/2     Running     2          4m15s
<b>istiod-istio-163-5fccfcf4dd-2p9c8                1/1     Running     0          3m31s</b>
prometheus-7d9f49d945-4nps2                      2/2     Running     0          3m17s
promsd-696bcc5b96-ln2s8                          2/2     Running     1          4m15s

确保您已迁移任何不受支持的 v1alpha1 安全政策配置对象。如需了解详情，请参阅 Istio 升级说明。
在 1.4.x 控制层面中停用配置验证功能：
1. 修改 Galley ClusterRole 资源：
```
kubectl edit clusterrole -n istio-system istio-galley-istio-system
```
2. 在以下列表条目中将 '*' 值更改为 get：
```
- apiGroups:
  - admissionregistration.k8s.io
  resources:
  - validatingwebhookconfigurations
  verbs:
  - '*' # change this to get
```
  更新完成后，您的代码应类似如下所示：
```
- apiGroups:
  - admissionregistration.k8s.io
  resources:
  - validatingwebhookconfigurations
  verbs:
  - get
```
3. 删除 Galley ValidatingWebhookConfiguration：
```
kubectl delete ValidatingWebhookConfiguration istio-galley -n istio-system
```
  注意：这样做会停用 1.4 的 Galley 用户配置验证功能。如果您需要从 1.6 回滚到 1.4，可以通过修改上一步中显示的 ClusterRole 资源并将 get 更改回 '*'，从而恢复成 1.4 验证。此操作会使 Galley 重新创建 ValidatingWebhookConfiguration。

将命名空间迁移到 1.6

安装新版本对现有 Sidecar 代理没有影响。如需升级这些代理，您必须将其配置为指向新控制层面。这会在 Sidecar 注入期间根据命名空间标签 istio.io/rev 进行控制。

找到确切的 Istio 1.6 版本号：

kubectl -n istio-system get pods -lapp=istiod --show-labels

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

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-istio-163-5fccfcf4dd-2p9c8   1/1     Running   0          22h   app=istiod,istio.io/rev=istio-163,istio=istiod,pod-template-hash=5fccfcf4dd

在本示例中，版本为：istio-163

为您希望回滚到 1.6 的工作负载所在的命名空间重新添加标签。版本标签必须与控制层面的版本匹配。在以下命令中，将 VERSION 替换为上一个命令中的版本，例如：istio-163
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=VERSION --overwrite
```

对所选工作负载执行滚动式重启：

kubectl rollout restart deployment DEPLOYMENT -n NAMESPACE

列出命名空间中的 Pod：
```
kubectl get pods -n NAMESPACE
```

选择某个 Pod 以检查工作负载是否已注入 1.6 版 Sidecar 代理：

kubectl describe pod -n NAMESPACE YOUR_SELECTED_POD

输出应在 1.6 版本中显示代理容器，例如：

...
istio-proxy:
  Container ID:  docker://22f62020ddcc6f8e02d800b5614e02aae2d082ce991c9e3eab9846d9f2cf90f5
  Image:         gcr.io/gke-release/istio/proxyv2:1.6.3-gke.0
...

将所有命名空间迁移到新的 Istio 版本。针对所有工作负载命名空间重复第 3 步到第 5 步。

如果您计划迁移到 Anthos Service Mesh，请跳至关闭旧的控制层面。

如需继续使用 Istio 插件，请执行以下步骤将入站流量网关迁移到新的 Istio 版本。

修改 IstioOperator CR，以将入站网关替换为 1.6 版本：
```
kubectl edit istiooperators -n istio-system istio-1-6-3-gke-0
```

将网关的 enabled 设置更改为 true：

...
spec:
  components:
    ingressGateways:
    - enabled: false # change this to true
      name: istio-ingressgateway

验证是否已使用新的 1.6 版本重建网关 Pod。

kubectl get pods -n istio-system -l app=istio-ingressgateway -o yaml | grep image

关闭旧的控制层面

在所有工作负载代理都使用 1.6 控制层面后，您可以将每个旧组件的副本调节到 0 来关闭旧的控制层面。

如需缩减副本，请使用以下命令：

kubectl scale deploy -n istio-system --replicas=0 \
  istio-citadel istio-galley istio-pilot istio-policy istio-sidecar-injector istio-telemetry prometheus promsd

剩余 Istio 资源可以无条件保留在集群中。

如果您继续使用 Istio，现在可以修改 IstioOperator CR 并按照自己的时间表升级 Operator。如需了解详情，请参阅 Operator 文档。

迁移到 Anthos Service Mesh

在迁移到 Anthos Service Mesh 之前，您必须如以下所述停用 Operator。迁移后，您仍然使用与 Operator 相同的 IstioOperator CR 格式配置服务网格，但当您希望更改安装状态时，请使用 istioctl install 命令，而不是让 Operator 控制器持续监控集群中的 IstioOperator CR。

要迁移到 Anthos Service Mesh，您使用 Google 提供的脚本来处理准备 Cloud 项目和集群的所有细节，然后使用 Anthos Service Mesh 版 istioctl install 安装 Anthos Service Mesh。虽然我们建议迁移到 Anthos Service Mesh 1.7，但您也可以通过 1.6 版脚本迁移到 Anthos Service Mesh 1.6。

要求

请确保您的集群符合以下要求：

具有至少四个 vCPU 的机器类型，例如 e2-standard-4。如果集群的机器类型没有至少四个 vCPU，请按照将工作负载迁移到不同的机器类型中所述更改机器类型。
最小节点数取决于您的机器类型。Anthos Service Mesh 至少需要八个 vCPU。如果机器类型有四个 vCPU，则您的集群必须至少有两个节点。如果机器类型有八个 vCPU，则集群只需要一个节点。如果需要添加节点，请参阅调整集群大小。
该脚本会在集群上启用 Workload Identity。建议使用 Workload Identity 来调用 Google API。如 Workload Identity 限制所述，启用 Workload Identity 会更改从工作负载到 Google API 的调用方式。
如需将服务端口纳入服务网格，必须为服务端口命名，并且名称必须包含以下语法的端口协议：name: protocol[-suffix]，其中方括号表示必须以短划线开头的可选后缀。如需了解详情，请参阅为服务端口命名。
如果您要在专用集群上安装 Anthos Service Mesh，则必须在防火墙中打开端口 15017，以获取与自动 Sidecar 注入搭配使用的网络钩子，以便正常运行。如需了解详情，请参阅在专用集群上打开端口。
如果您在组织中创建了服务边界，则可能需要将 Mesh CA 服务添加到边界。如需了解详情，请参阅将 Mesh CA 添加到服务边界。

规划迁移

如需规划迁移，请查看准备从 Istio 迁移。

停用 Operator

为了防止 Operator 调整 Anthos Service Mesh 安装的 istio-ingressgateway，您需要停用 Operator。

要停用 Operator，请执行以下操作：

获取 Operator 版本：

kubectl get istiooperators -n istio-system

输出内容类似如下：

NAME                        REVISION     STATUS    AGE
istio-1-6-11-gke-0          istio-1611   HEALTHY   12h

在示例输出中，Operator 版本为 istio-1-6-11-gke-0。

停用 Operator。在以下命令中，将 VERSION 替换为上一步中的 Operator 版本：
```
kubectl patch -n istio-system istiooperator VERSION -p '{"spec":{"profile":"disabled"}}' --type=merge
```
此命令会阻止 Operator 在集群中进行任何更改。

迁移到 Anthos Service Mesh

本部分介绍如何使用 install_asm 脚本迁移到 Anthos Service Mesh。我们建议您迁移到 Anthos Service Mesh 1.7，但也支持迁移到 Anthos Service Mesh 1.6。

迁移到 1.7

安装所需的工具。
下载 install_asm 脚本。
查看脚本的选项和标志。

如果您尚未自定义 Istio 安装，并且想要继续使用 Citadel 作为证书授权机构 (CA)，则可以在脚本中使用以下参数迁移到 Anthos Service Mesh：
```
./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME\
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --enable_apis
```
注意：如果您自定义了 Istio 安装，则在迁移到 Anthos Service Mesh 时也需要使用相同的自定义设置。install_asm 脚本允许您使用 --custom_overlay 选项传入一个或多个 IstioOperator YAML 文件。
Anthos Service Mesh 1.7 还在 GitHub 中提供了常用功能（例如启用出站流量网关）的叠加文件。如需了解详情，请参阅启用可选功能。
要完成 Anthos Service Mesh 的设置，您需要启用自动 Sidecar 注入并部署或重新部署工作负载。

迁移到 1.6

安装所需的工具。
下载 install_asm 脚本。
查看脚本的选项和标志。

如果您尚未自定义 Istio 安装，并且想要继续使用 Citadel 作为证书授权机构 (CA)，则可以在脚本中使用以下参数迁移到 Anthos Service Mesh：
```
./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME\
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --enable_apis
```
注意：如果您自定义了 Istio 安装，则在迁移到 Anthos Service Mesh 时也需要使用相同的自定义设置。1.6 install_asm 脚本允许您使用 --custom_overlay 选项传入一个 IstioOperator YAML 文件。
要完成 Anthos Service Mesh 的设置，您需要启用自动 Sidecar 注入并部署或重新部署工作负载。

迁移之后

运行以下命令，并将 VERSION 替换为您之前用于停用 Operator 的 Operator 版本：

kubectl patch -n istio-system istiooperator VERSION -p '{"spec":{"profile":"empty"}}'

此命令通过 empty 配置文件重新启用 Operator，这会导致它从集群移除它之前安装的资源。这不包括由 install_asm 脚本安装的网关或控制层面元素。