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

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

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

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

ディレクトリの構造

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

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

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

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

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

名前空間と抽象名前空間情報源の構成ファイルと構造が正しい型になるよう、エラーの場合は KNV1003: legalNamespaceSubdirectoryError が報告されます。

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

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

名前空間を制限

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

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

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

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

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

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

次のステップ