Istio は In-Cluster Operator を非推奨にしました

Istio の In-Cluster Operator は Istio 1.23 で非推奨となりました。Operator を利用しているユーザー（ユーザーベースの 10% 未満と推定）は、Istio 1.24 以降にアップグレードするために、他のインストールおよびアップグレードメカニズムに移行する必要があります。この変更を行う理由、および Operator ユーザーが何をすべきかを以下で説明します。

これはあなたに影響しますか？

この非推奨は、In-Cluster Operatorのユーザーのみに影響します。istioctl install コマンドと IstioOperator YAML ファイルを使用して Istio をインストールするユーザーは影響を受けません。

影響を受けるかどうかを確認するには、kubectl get deployment -n istio-system istio-operator および kubectl get IstioOperator を実行します。両方のコマンドが空でない値を返す場合、クラスターは影響を受けます。最近の調査によると、これは Istio ユーザーの 10% 未満に影響すると予想されます。

Operator ベースの Istio インストールは無期限に実行され続けますが、1.23.x を超えてアップグレードすることはできません。

いつ移行する必要がありますか？

Istio のベータ機能の非推奨ポリシーに従い、Istio In-Cluster Operator は、この発表から約 3 か月後の Istio 1.24 のリリースで削除されます。Istio 1.23 は 2025 年 3 月までサポートされ、その時点で Operator ユーザーはサポートを維持するために別のインストールメカニズムに移行する必要があります。

どのように移行しますか？

Istio プロジェクトは、istioctl コマンドおよび Helm を介したインストールとアップグレードを今後もサポートします。プラットフォームエンジニアリングエコシステムにおける Helm の普及のため、ほとんどのユーザーは Helm に移行することをお勧めします。istioctl install は Helm テンプレートに基づいており、今後のバージョンでは Helm とより深く統合される可能性があります。

Helm インストールは、Flux や Argo CD などの GitOps ツールで管理することもできます。

Istio を実行するための Operator パターンを好むユーザーは、2 つの新しい Istio エコシステムプロジェクト、Classic Operator Controller、または Sail Operator のいずれかに移行できます。

Helm への移行

Helm への移行には、IstioOperator YAML を Helm の values.yaml ファイルに変換する必要があります。この移行をサポートするツールは、Istio 1.24 のリリースと同時に提供されます。

istioctl への移行

IstioOperator カスタムリソースを特定します。結果は 1 つだけになるはずです。

$ kubectl get IstioOperator

リソースの名前を使用して、Operator の構成を YAML 形式でダウンロードします

$ kubectl get IstioOperator <name> > istio.yaml

In-Cluster 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

Classic Operator Controller への移行

新しいエコシステムプロジェクトである Classic Operator Controller は、Istio に組み込まれていた元のコントローラーのフォークです。このプロジェクトは、元の Operator と同じ API とコードベースを維持しますが、Istio コアの外で保守されます。

API が同じであるため、移行は簡単です。新しい Operator のインストールのみが必要です。

Classic Operator Controller は、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 があった理由は何ですか？

Operator パターンは、2016 年に CoreOS によって、人間の知性をコード化する方法として普及しました。最も一般的なユースケースはデータベース Operator で、ユーザーは 1 つのクラスターに複数のデータベースインスタンスを持ち、複数の継続的な運用タスク（バックアップ、バキューム、シャーディング）を実行する可能性があります。

Istio は、Helm v2 の問題に対応して、バージョン 1.4 で istioctl と In-Cluster Operator を導入しました。ほぼ同時期に、コミュニティの懸念に対処した Helm v3 が導入され、今日では Kubernetes にソフトウェアをインストールする推奨される方法となっています。Helm v3 のサポートは Istio 1.8 で追加されました。

Istio の In-Cluster Operator はサービスメッシュコンポーネントのインストールを処理しました。これは通常、クラスターごとに 1 回、1 つのインスタンスに対して行う操作です。クラスター内で istioctl を実行する方法と考えることができます。ただし、これはクラスター内で特権の高いコントローラーを実行していることを意味し、セキュリティ体制が弱まります。継続的な管理タスク（バックアップ、スナップショットの作成など、Istio の実行には必須ではありません）は処理しません。

Istio Operator はクラスターにインストールする必要があるため、何かのインストールをすでに管理する必要があります。同様に、クラスターをアップグレードするために、まず istioctl の新しいバージョンをダウンロードして実行する必要がありました。

Operator を使用するということは、間接的なレベルを作成したことを意味します。つまり、インストールについて変更したい可能性のあるすべての設定を構成するためのオプションをカスタムリソースに含める必要があります。Istio は、インストールオプションを構成できる IstioOperator API を提供することで、この問題を回避しました。このリソースは、In-Cluster Operator と istioctl install の両方で使用されるため、Operator ユーザーにとっては簡単な移行パスがあります。

3 年前— Istio 1.12 の頃—新しい Istio インストールに Operator を使用することは推奨されておらず、Istio をインストールするには istioctl または Helm を使用する必要があることをドキュメントで更新しました。

3 つの異なるインストール方法があるため、混乱が生じました。Helm または istioctl を使用している人々（インストールベースの 90% 以上）に最高のエクスペリエンスを提供するために、Istio 1.23 では In-Cluster Operator を正式に非推奨にすることにしました。