階層型リポジトリを使用する

このページでは、Config Sync が階層型の信頼できる情報源から構成ファイルを読み取り、生成された構成をクラスタに自動的に適用する方法について説明します。

より柔軟な構造が必要な場合（リソースのサブフォルダを作成する場合など）は、非構造化の信頼できる情報源を作成します。ほとんどのユースケースでは、非構造化の信頼できる情報源をおすすめします。階層型の信頼できる情報源をすでに使用している場合は、非構造化の信頼できる情報源に変換できます。

Config Sync が階層型リポジトリを使用する方法を理解するには、Git リポジトリと git コマンドライン インターフェースに関する知識が役立ちます。

ディレクトリの構造

階層型の情報源の場合、Config Sync はファイルシステムに似た構造を利用し、そのディレクトリを使用して構成ファイルがどのクラスタまたは Namespace に関連しているかを判断します。

namespaces/

namespaces/ ディレクトリには、Namespace と Namespace スコープ オブジェクトの構成ファイルが入っています。namespaces/ 内の構造に基づいて、Namespace の継承が行われます。NamespaceSelector を使用すると、構成を継承できる Namespace を制限できます。

cluster/

cluster/ ディレクトリには、（Namespace ではなく）クラスタ全体に適用される構成ファイルが含まれています。デフォルトでは、cluster/ ディレクトリ内の構成ファイルが、Config Sync に登録されているすべてのクラスタに適用されます。ClusterSelector を使用することで、ある特定の構成ファイルを適用する対象のクラスタを制限できます。

clusterregistry/

clusterregistry/ はオプションのディレクトリであり、ClusterSelector の構成ファイルが含まれています。ClusterSelector は、構成ファイルが適用されるクラスタを制限し、cluster/ と namespaces/ ディレクトリの構成ファイルで参照されます。

system/

system/ ディレクトリには Operator の構成ファイルがあります。

階層型の信頼できる情報源の例

次のディレクトリ構造は、Config Sync の階層型の信頼できる情報源を使用して、異なる 2 チーム（team-1 と team-2）によって共有される Kubernetes クラスタを構成する方法を示しています。

  • チームそれぞれに、独自の Kubernetes Namespace、Kubernetes サービス アカウント、リソース割り当て、ネットワーク ポリシー、RoleBinding があります。
  • クラスタ管理者は、namespaces/limit-range.yaml にポリシーを設定して、Pod とコンテナ両方の Namespace でリソースの割り当てを制限します。
  • また、クラスタ管理者は、ClusterRole と ClusterRoleBinding も設定します。

有効な Config Sync の階層型の情報源には、cluster/、namespaces/、system/ の 3 つのサブディレクトリが含まれている必要があります。

cluster/ ディレクトリには、Namespace ではなくクラスタ全体に適用される構成ファイル（ClusterRole、ClusterRoleBinding など）が含まれています。

namespaces/ ディレクトリには、Namespace オブジェクトと Namespace スコープ オブジェクトの構成ファイルが入っています。namespaces/ の各サブディレクトリには、Namespace オブジェクトの構成ファイルと、Namespace の下にあるすべての Namespace スコープ オブジェクトの構成ファイルが入っています。サブディレクトリの名前は、Namespace オブジェクトの名前と同じにする必要があります。各 Namespace に作成する必要がある Namespace スコープ オブジェクトは、namespaces/ の直下に配置できます（例: namespaces/limit-range.yaml）。

system/ ディレクトリには ConfigManagement Operator の構成ファイルが入っています。

├── cluster
│   ├── clusterrolebinding-namespace-reader.yaml
│   ├── clusterrole-namespace-reader.yaml
│   ├── clusterrole-secret-admin.yaml
│   └── clusterrole-secret-reader.yaml
├── namespaces
│   ├── limit-range.yaml
│   ├── team-1
│   │   ├── namespace.yaml
│   │   ├── network-policy-default-deny-egress.yaml
│   │   ├── resource-quota-pvc.yaml
│   │   ├── rolebinding-secret-reader.yaml
│   │   └── sa.yaml
│   └── team-2
│       ├── namespace.yaml
│       ├── network-policy-default-deny-all.yaml
│       ├── resource-quota-pvc.yaml
│       ├── rolebinding-secret-admin.yaml
│       └── sa.yaml
├── README.md
└── system
    └── repo.yaml

Namespace の継承と抽象名前空間を使用する

階層型の信頼できる情報源を使用すると、Namespace の継承のコンセプトを使用して、Namespace が存在する（または存在するはずの）すべてのクラスタ内の Namespace のグループに構成を自動的に適用できます。

Namespace の継承は、階層リポジトリとそのすべてのサブディレクトリ内の namespaces/ ディレクトリに適用されます。リポジトリの他のディレクトリ（cluster/ など）の構成ファイルは継承の対象ではありません。

階層型の信頼できる情報源では、namespaces/ ディレクトリに次の 2 種類のサブディレクトリを含めることができます。

  • 1 つの Namespace ディレクトリには Namespace の構成ファイルが 1 つ含まれます。構成ファイルを含むファイルの名前は重要ではありませんが、構成ファイルには kind: Namespace が含まれている必要があります。名前空間ディレクトリには、他の種類の Kubernetes オブジェクトのコンフィグも含めることができます。名前空間ディレクトリにサブディレクトリを含めることはできません。名前空間構成ファイルは、クラスタ内の実際の名前空間を表します。

  • 複数の名前空間ディレクトリを含む抽象名前空間ディレクトリ。他の Kubernetes オブジェクトの構成ファイルも含めることができますが、名前空間の構成ファイルを直下に含めることはできません。Kubernetes クラスタ内のオブジェクトを表すのは抽象名前空間ディレクトリではなく、その下位の Namespace ディレクトリです。

エラーが発生すると、Namespace と抽象名前空間の情報源に正しいタイプの構成ファイルと構造が適用されるように、KNV1003: IllegalNamespaceSubdirectoryError エラーが報告されます。

Namespace ディレクトリ内の構成ファイルはその Namespace にのみ適用され、抽象名前空間ディレクトリ内の構成ファイルは抽象名前空間の下位にある Namespace ディレクトリすべてに適用されます（NamespaceSelector が存在する場合は、構成ファイルの NamespaceSelector に一致する下位の Namespace に適用されます）。

namespaces/ ディレクトリ内の構成ファイルの継承は、その構成ファイルが信頼できる情報源内のディレクトリ ツリーのどこに位置しているかに基づいて行われます。特定のクラスタ内の特定の Namespace に適用されている構成ファイルを確認するには、Namespace の継承に関するサンプル リポジトリをご覧ください。

制限付きの Namespace

config-management-system は制限付きの名前空間です。抽象名前空間ディレクトリとしては使用できません。config-management-system Namespace を定義できますが、config-management-system Namespace で許可されるリソースタイプは RootSync のみです。

信頼できる情報源に変更を加える

namespaces/ ディレクトリ内に Namespace ディレクトリを作成するか、削除するように信頼できる情報源に変更を加えると、アクションによっては予期しない結果になることがあります。

  • ディレクトリの作成: 有効な namespaces/ 階層が信頼できる情報源に commit されると、Config Sync は Namespace を作成してから、Namespace ディレクトリに含まれる構成ファイルまたは継承された構成ファイルに対応する Kubernetes オブジェクトをそれらの Namespace に作成します。
  • ディレクトリの削除: Namespace ディレクトリの削除は破壊的な操作です。Config Sync によって管理されているクラスタのうち、その Namespace が存在するすべてのクラスタから、Namespace とその内容が削除されます。下位の Namespace ディレクトリを含む抽象名前空間ディレクトリを削除すると、Config Sync によって管理されているすべてのクラスタから、それらすべての Namespace とその内容が削除されます。

  • ディレクトリ名の変更: Namespace ディレクトリの名前を変更すると、いったん削除した後再び作成されるため、破壊的な操作とみなされます。抽象名前空間ディレクトリの名前を変更しても、外部から見える影響はありません。

  • ディレクトリの移動: namespaces/ 内で Namespace または抽象名前空間ディレクトリを移動しても、その Namespace やその中のオブジェクトは削除されません。ただし、その階層が変更された結果、抽象名前空間ディレクトリからの構成ファイルの継承が開始または停止される場合は除きます。

次のステップ