Istio 已弃用其集群内 Operator

Istio 的集群内 Operator 已在 Istio 1.23 中弃用。使用 Operator 的用户（我们估计少于 10% 的用户群）将需要迁移到其他安装和升级机制才能升级到 Istio 1.24 或更高版本。继续阅读以了解我们进行此更改的原因以及 Operator 用户需要做些什么。

这会影响您吗？

此弃用仅影响 集群内 Operator 的用户。使用 istioctl install 命令和 IstioOperator YAML 文件安装 Istio 的用户不受影响。

要确定您是否受到影响，请运行 kubectl get deployment -n istio-system istio-operator 和 kubectl get IstioOperator。如果这两个命令都返回非空值，则您的集群将受到影响。根据最近的调查，我们预计这将影响不到 10% 的 Istio 用户。

基于 Operator 的 Istio 安装将继续无限期运行，但不能升级到 1.23.x 版本。

我什么时候需要迁移？

为了遵循 Istio 对 Beta 特性的弃用策略，Istio 集群内 Operator 将在 Istio 1.24 发布时被移除，大约距离本公告发布三个月。Istio 1.23 将得到支持到 2025 年 3 月，届时 Operator 用户将需要迁移到其他安装机制才能保留支持。

如何迁移？

Istio 项目将继续支持通过 istioctl 命令以及 Helm 进行安装和升级。由于 Helm 在平台工程生态系统中的流行度，我们建议大多数用户迁移到 Helm。istioctl install 基于 Helm 模板，未来版本可能会与 Helm 深度集成。

Helm 安装也可以使用 GitOps 工具（如 Flux 或 Argo CD）来管理。

喜欢使用 Operator 模式运行 Istio 的用户可以迁移到两个新的 Istio 生态系统项目中的任何一个，即经典 Operator 控制器或 Sail Operator。

迁移到 Helm

Helm 迁移需要将您的 IstioOperator YAML 转换为 Helm values.yaml 文件。支持此迁移的工具将与 Istio 1.24 版本一起提供。

迁移到 istioctl

识别您的 IstioOperator 自定义资源：应该只有一个结果。

$ kubectl get IstioOperator

使用您的资源的名称，以 YAML 格式下载您的 Operator 配置

$ kubectl get IstioOperator <name> > istio.yaml

禁用集群内 Operator。这不会禁用您的控制平面或中断您当前的网格流量。

$ kubectl scale deployment -n istio-system istio-operator –replicas 0

当您准备好将 Istio 升级到 1.24 或更高版本时，请按照 升级说明 进行操作，使用您上面下载的 istio.yaml 文件。

完成并验证迁移后，运行以下命令清理您的 Operator 资源

$ kubectl delete deployment -n istio-system istio-operator
$ kubectl delete customresourcedefinition istiooperator

迁移到经典 Operator 控制器

一个新的生态系统项目，经典 Operator 控制器，是内置于 Istio 的原始控制器的分支。该项目保持与原始 Operator 相同的 API 和代码库，但在 Istio 核心之外维护。

由于 API 相同，因此迁移非常简单：只需要安装新的 Operator。

经典 Operator 控制器不受 Istio 项目的支持。

迁移到 Sail Operator

一个新的生态系统项目，Sail Operator，能够在 Kubernetes 或 OpenShift 集群中安装和管理 Istio 控制平面的生命周期。

Sail Operator API 是围绕 Istio 的 Helm 图表 API 构建的。Istio 的 Helm 图表公开的所有安装和配置选项都可通过 Sail Operator CRD 的 values: 字段获得。

Sail Operator 不受 Istio 项目的支持。

什么是 Operator，为什么 Istio 会有一个？

Operator 模式 由 CoreOS 在 2016 年推广，作为将人类智慧编码到代码中的方法。最常见的用例是数据库 Operator，用户可能在一个集群中拥有多个数据库实例，并有多个正在进行的操作任务（备份、vacuum、分片）。

Istio 在 1.4 版本中引入了 istioctl 和集群内 Operator，以解决 Helm v2 的问题。大约在同一时间，Helm v3 被引入，解决了社区的担忧，并且是如今在 Kubernetes 上安装软件的首选方法。在 Istio 1.8 中添加了对 Helm v3 的支持。

Istio 的集群内 Operator 处理服务网格组件的安装 - 您通常在一个集群中对一个实例进行一次操作。可以将其视为在集群内运行 istioctl 的一种方式。但是，这意味着您在集群中运行了一个高权限的控制器，这会削弱您的安全态势。它不处理任何正在进行的管理任务（备份、快照等不是运行 Istio 的要求）。

Istio Operator 是您必须安装到集群中的东西，这意味着您已经必须管理某个东西的安装。同样，使用它来升级集群首先需要您下载并运行新版本的 istioctl。

使用 Operator 意味着您创建了一个间接级别，您必须在自定义资源中拥有选项来配置您可能希望更改安装的任何内容。Istio 通过提供 IstioOperator API 来解决此问题，该 API 允许配置安装选项。此资源由集群内 Operator 和 istioctl install 使用，因此 Operator 用户有一个微不足道的迁移路径。

三年前（大约在 Istio 1.12 期间），我们更新了文档，说明不鼓励使用 Operator 进行新的 Istio 安装，用户应该使用 istioctl 或 Helm 来安装 Istio。

拥有三种不同的安装方法会导致混淆，为了为使用 Helm 或 istioctl 的用户提供最佳体验（超过 90% 的安装基础），我们决定在 Istio 1.23 中正式弃用集群内 Operator。