2.7. マルチテナントクラスター内の Operator
Operator Lifecycle Manager (OLM) のデフォルトの動作は、Operator のインストール時に簡素化することを目的としています。ただし、この動作は、特にマルチテナントクラスターでは柔軟性に欠ける場合があります。OpenShift Container Platform クラスターの複数のテナントが Operator を使用するために、OLM のデフォルトの動作では、管理者が Operator を All namespaces モードでインストールする必要があります。これは、最小特権の原則に違反していると見なすことができます。
以下のシナリオを考慮して、環境と要件に最適な Operator インストールワークフローを決定してください。
2.7.1. デフォルトの Operator インストールモードと動作
管理者として Web コンソールを使用して Operator をインストールする場合、通常、Operator の機能に応じて、インストールモードに 2 つの選択肢があります。
- 単一の namespace
- 選択した単一の namespace に Operator をインストールし、Operator が要求するすべての権限をその namespace で使用できるようにします。
- すべての namespace
-
デフォルトの
openshift-operatorsnamespace で Operator をインストールし、クラスターのすべての namespace を監視し、Operator をこれらの namespace に対して利用可能にします。Operator が要求するすべてのアクセス許可をすべての namespace で使用できるようにします。場合によっては、Operator の作成者はメタデータを定義して、その Operator が提案する namespace の 2 番目のオプションをユーザーに提供できます。
この選択は、影響を受ける namespace のユーザーが、namespace でのロールに応じて、所有するカスタムリソース (CR) を活用できる Operators API にアクセスできることも意味します。
-
namespace-adminおよびnamespace-editロールは、Operator API の読み取り/書き込みが可能です。つまり、Operator API を使用できます。 -
namespace-viewロールは、その Operator の CR オブジェクトを読み取ることができます。
Single namespace モードの場合、Operator 自体が選択した namespace にインストールされるため、その Pod とサービスアカウントもそこに配置されます。All namespaces モードの場合、Operator の権限はすべて自動的にクラスターロールに昇格されます。つまり、Operator はすべての namespace でこれらの権限を持ちます。
2.7.2. マルチテナントクラスターの推奨ソリューション
Multinamespace インストールモードは存在しますが、サポートされている Operator はほとんどありません。標準 All namespaces と Single namespace インストールモードの中間的なソリューションとして、次のワークフローを使用して、テナントごとに 1 つずつ、同じ Operator の複数のインスタンスをインストールできます。
- テナントの namespace とは別のテナント Operator の namespace を作成します。
- テナントの namespace のみを対象とするテナント Operator の Operator グループを作成します。
- テナント Operator namespace に Operator をインストールします。
その結果、Operator はテナントの Operator namespace に存在し、テナントの namespace を監視しますが、Operator の Pod もそのサービスアカウントも、テナントによって表示または使用できません。
このソリューションは、より優れたテナント分離、リソースの使用を犠牲にした最小特権の原則、および制約が確実に満たされるようにするための追加のオーケストレーションを提供します。詳細な手順は、「マルチテナントクラスター用の Operator の複数インスタンスの準備」を参照してください。
制限および考慮事項
このソリューションは、次の制約が満たされている場合にのみ機能します。
- 同じ Operator のすべてのインスタンスは、同じバージョンである必要があります。
- Operator は、他の Operator に依存することはできません。
- Operator は CRD 変換 Webhook を出荷できません。
同じクラスターで同じ Operator の異なるバージョンを使用することはできません。最終的に、Operator の別のインスタンスのインストールは、以下の条件を満たす場合にブロックされます。
- インスタンスは Operator の最新バージョンではありません。
- インスタンスは、クラスターですでに使用されている新しいリビジョンに含まれる情報またはバージョンを欠いている CRD の古いリビジョンを出荷します。
「非クラスター管理者による Operator のインストールの許可」で説明されているように、非クラスター管理者が自給自足で Operator をインストールできるようにする場合は、管理者として注意してください。これらのテナントは、依存関係がないことがわかっている Operator の精選されたカタログにのみアクセスできる必要があります。これらのテナントは、CRD が変更されないようにするために、Operator の同じバージョンラインを使用することを強制する必要もあります。これには、ネームスペーススコープのカタログを使用し、グローバルなデフォルトカタログを無効にする必要があります。
2.7.3. Operator のコロケーションと Operator グループ
Operator Lifecycle Manager (OLM) は、同じ namespace にインストールされている OLM 管理 Operator を処理します。つまり、それらの Subscription リソースは、関連する Operator として同じ namespace に配置されます。それらが実際には関連していなくても、いずれかが更新されると、OLM はバージョンや更新ポリシーなどの状態を考慮します。
Operator のコロケーションと Operator グループの効果的な使用の詳細は、Operator Lifecycle Manager (OLM)
