Hierarchy Controller は、Kubernetes Namespace に階層機能を追加します。これにより、きめ細かいポリシーを作成し、オブザーバビリティを向上させ、クラスタ管理の委任が可能になります。
Hierarchy Controller は、オープンソース プロジェクトの Hierarchy Namespace Controller（HNC）をベースにしています。クラスタ内で実行される Kubernetes コントローラと動的アドミッション コントローラを使用して実装されます。
階層型名前空間
Kubernetes では、ほとんどのオブジェクトの編成で Namespace が基本単位となります。また、Kubernetes における隔離とセキュリティの基本単位にもなります。RBAC ロール、Secret、サービス アカウント、リソース割り当て、ネットワーク ポリシーなど、ほとんどのポリシーや分離オブジェクトは Namespace レベルで動作します。
通常、クラスタのセキュリティと分離を向上させるには、1 つのマイクロサービスのように、最低限のリソースと、それに付随するリソースとポリシーを含むように Namespace のスコープを設定しますが、これにより、クラスタ内で大量の Namespace が生成され、管理が難しくなる可能性もあります。
この問題を解決するため、Hierarchy Controller の階層型 Namespace というコンセプトを使用します。これにより、Kubernetes Namespace をオーナー別にグループ化し、複数のグループを 1 つの単位として扱えるようになります。複数のチームでクラスタを共有している場合、これは非常に便利な手法です。また、オーナーは必ずしも「人」である必要はありません。たとえば、自動化ツールを一連の Namespace のオーナーに設定できます。広範な権限を必要とするものの、少数の関連する Namespace にのみアクセスする必要がある場合は、この方法が便利です。
マルチテナントのユースケースをサポートするために、階層型 Namespace では、通常の Kubernetes Namespace 以外にもいくつかの機能をサポートしています。
- ポリシーの強制。階層型 Namespace では、プロパゲーションを利用して、特定のポリシーを祖先から継承できます。たとえば、「root」Namespace に RBAC 権限を付与した場合、Hierarchy Controller は、RBAC オブジェクトをそれらの子にコピー（プロパゲーション）し、これらの権限を下位の Namespace にも適用します。例外を使用すると、プロパゲーションをよりきめ細かく制御できます。
- ポリシーの適用。すべての階層型 Namespace には、その祖先が反映されたツリーラベルが含まれています。これらのラベルは、Webhook 構成やネットワーク ポリシーの検証など、ポリシーのラベル選択で使用できます。
- 階層型の割り当て。祖先 Namespace に階層型の割り当てを定義すると、その上限は、定義した Namespace だけでなく、すべての子の合計使用量にも自動的に適用されます。
- 階層型のオブザーバビリティ。ポリシーの適用で使用されたツリーラベルは、ログや使用量をフィルタリングするなど、階層的なワークロードの監視にも使用できます。
- 委任された Namespace の作成。Hierarchy Controller の下位の Namespace というコンセプトを使用すると、クラスタレベルの Namespace 権限がない場合でも、既存の Namespace 内に下位の Namespace を作成できます。
階層型 Namespace は、委任を含むさまざまな管理機能にも対応しています。
階層型 Namespace と抽象 Namespace
Hierarchy Controller の階層型 Namespace は、Config Sync の階層型リポジトリで利用できる抽象 Namespace に似ています。ただし、コンセプトの点でいくつかの違いがあります。
- 抽象 Namespace は階層型リポジトリでのみ定義できます。つまり、構成ファイルの特定の構造が適用されます。階層型 Namespace では、非構造化リポジトリで使用できるため、構成ファイルを自由に配置できます。
- 抽象 Namespace は Git リポジトリにのみ存在しますが、階層型 Namespace は通常の Kubernetes Namespace で、クラスタ内に存在します。階層型 Namespace はリポジトリで定義することも、クラスタに直接定義することもできます。
- 階層型 Namespace にクラスタレベルの作成権限は必要ありません。代わりに、下位の Namespace を使用して、Namespace の作成を委任できます。
- 階層型のリソース割り当ては、階層型名前でのみサポートされます。抽象 Namespace ではサポートされていません。
- 抽象 Namespace は Config Sync でのみ使用できます。階層型 Namespace はオープンソースのコンセプトをベースにしています。
抽象 Namespace と階層型 Namespace はデフォルトの動作も異なります。デフォルトでは、抽象 Namespace に作成されたオブジェクトはすべて、その下位にプロパゲーションされます。階層型 Namespace のオブジェクトは、Hierarchy Controller がそのオブジェクト タイプを反映するように構成されている場合のみプロパゲーションされます。
デフォルトでは、RBAC ロールとロール バインディングのみがプロパゲーションされますが、Namespace オブジェクトのプロパゲーションも可能です。ポリシー オブジェクト（ロールなど）とリソース オブジェクト（構成マップなど）のみをプロパゲーションすることをおすすめします。Hierarchy Controller は、Pod、Deployment、Job などのワークロード オブジェクトをプロパゲーションするようには設計されていません。このような操作を行うと、予期しない結果が生じる可能性があります。ワークロードは、リーフ Namespace に配置することをおすすめします。
Config Sync での Hierarchy Controller の使用
Hierarchy Controller では、階層のコンセプトに基づいてポリシーを定義し、適用できます。これは、複数のチームで使用されるクラスタなど、多くのアプリケーションに適しています。Config Sync を使用すると、これらのポリシーを Git リポジトリに保存し、クラスタのグループに適用できます。この 2 つは異なる機能ですが、どちらも無料で利用でき、マルチチーム、マルチクラスタ環境で GitOps を適用できます。
Config Sync で Hierarchy Controller を使用する場合は、非構造化リポジトリを使用して Config Sync の抽象 Namespace を無効にし、Hierarchy Controller を使用して階層の定義とポリシーのプロパゲーションを行うことをおすすめします。リポジトリにチェックインする Namespace の場合は、HierarchicalConfiguration オブジェクトを変更することで階層関係を更新できるため、下位の Namespace ではなく、完全な Namespace の構成ファイルのみをチェックインすることをおすすめします。
階層型リポジトリで Hierarchy Controller と Config Sync の抽象 Namespace と一緒に使用できますが、制限があります。たとえば、Hierarchy Controller では、階層型リポジトリに定義された 2 つの Namespace 間の階層関係を作成できません。これは、そのリポジトリ内の抽象 Namespace と競合する可能性があるためです。ただし、次の方法では階層型 Namespace と階層型リポジトリを一緒に使用できます。
- クラスタ上で、階層型リポジトリから作成された Namespace の下にセルフサービスの下位 Namespace を作成できます。ただし、これらの下位の Namespace の構成ファイルをチェックインすることはおすすめしません。
- 複数のリポジトリを使用している場合は、その Namespace リポジトリに下位の Namespace のアンカーを作成できます。これにより、Hierarchy Controller に対して、指定した Namespace の下に Namespace を作成するように指示します。こうした下位の Namespace では、構成済みのすべてのリソースをその祖先から継承します。また、階層型リソース割り当てによる制約を受けます。ただし、これらの下位の Namespace にのみ存在するリソースを定義することはできません。Config Sync では、Namespace リポジトリ内のすべてのオブジェクトを指定の Namespace と同期します。