5.16. Go ベースの Operator 用のオブジェクトプルーニングユーティリティー
operator-lib プルーニングユーティリティーを使用すると、Go ベースの Operator は、オブジェクトが不要になったときにオブジェクトをクリーンアップまたはプルーニングできます。Operator の作成者は、ユーティリティーを使用してカスタムフックと戦略を作成することもできます。
Operator プロジェクトの関連スキャフォールディングおよびテストツールなど、Red Hat がサポートするバージョンの Operator SDK CLI ツールは非推奨となり、OpenShift Container Platform の今後のリリースで削除される予定です。Red Hat は、現在のリリースライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は今後、機能拡張の提供はなく、OpenShift Container Platform リリースから削除されます。
新しい Operator プロジェクトを作成する場合、Red Hat がサポートするバージョンの Operator SDK は推奨されません。既存の Operator プロジェクトを使用する Operator 作成者は、OpenShift Container Platform 4.18 でリリースされるバージョンの Operator SDK CLI ツールを使用してプロジェクトを維持し、OpenShift Container Platform の新しいバージョンを対象とする Operator リリースを作成できます。
Operator プロジェクトの次の関連ベースイメージは 非推奨 ではありません。これらのベースイメージのランタイム機能と設定 API は、バグ修正と CVE への対応のために引き続きサポートされます。
- Ansible ベースの Operator プロジェクトのベースイメージ
- Helm ベースの Operator プロジェクトのベースイメージ
OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧は、OpenShift Container Platform リリースノートの 非推奨および削除された機能 セクションを参照してください。
サポートされていない、コミュニティーによって管理されているバージョンの Operator SDK は、Operator SDK (Operator Framework) を参照してください。
5.16.1. operator-lib プルーニングユーティリティーについて リンクのコピーリンクがクリップボードにコピーされました!
ジョブや Pod などのオブジェクトは、Operator ライフサイクルの通常の部分として作成されます。クラスター管理者または Operator がこれらのオブジェクトを削除しない場合には、そのままクラスターにとどまり、リソースを消費する可能性があります。
以前は、不要なオブジェクトの整理に次のオプションを使用できました。
- Operator の作成者は、Operator 向けに独自のプルーニングソリューションを作成する必要がありました。
- クラスター管理者は、自分でオブジェクトをクリーンアップする必要がありました。
operator-lib プルーニングユーティリティー では、特定の namespace の Kubernetes クラスターからオブジェクトを削除します。このライブラリーは、Operator Framework の一部として operator-lib ライブラリー のバージョン 0.9.0 で追加されました。