このページでは、信頼できる情報源で構成を整理する方法について説明します。
組織が拡大するにつれて、クラスタのフリート全体で構成を管理し、同じリポジトリで作業する複数のチームをサポートする必要が生じる可能性があります。GitOps 戦略を成功させるための重要な要素は、構成が正しいクラスタに適用され、チームが互いに干渉することなく作業できるようにすることです。
構成ファイルについて
Config Sync は、多数のクラスタを管理するクラスタ オペレーター向けに設計されています。Config Sync にすべてのクラスタの Namespace、Role、RoleBinding、ResourceQuota、その他の重要な Kubernetes オブジェクトの管理を任せることで、運用するクラスタがビジネスやコンプライアンスの基準を確実に遵守するようにできます。
Config Sync はこれらのリソースを管理する際に、構成ファイルを使用して、登録されたクラスタを同期させます。構成ファイルとは、信頼できる情報源にある YAML ファイルまたは JSON ファイルです。Config Sync は、信頼できる情報源として Git リポジトリ、OCI イメージ、Helm チャートをサポートしています。構成ファイルには、kubectl apply コマンドを使用して手動でクラスタに適用できるものと同じタイプの構成情報が含まれています。クラスタ内に存在可能な Kubernetes オブジェクトの構成ファイルを作成できます。ただし、Secret などの一部の Kubernetes オブジェクトには機密情報が含まれており、信頼できる情報源に保存するのは適切でない場合があります。これらのタイプのオブジェクトを Config Sync で管理するかどうかは、慎重に検討してください。
要件と制限事項
一部の Kubernetes リソースには、変更不可フィールドが含まれています（Deployment オブジェクトの Pod セレクタなど）。信頼できる情報源の値を変更しても、構成ファイル内の変更不可フィールドを変更することはできません。このような変更を試みると、
KNV2009エラーが発生します。変更不可フィールドを変更する必要がある場合は、信頼できる情報源からオブジェクトを削除し、Config Sync がクラスタからオブジェクトを削除するのを待ってから、更新したオブジェクトを信頼できる情報源に再作成します。Git サブモジュールを使用する場合は、サブモジュールを含むすべてのリポジトリへのアクセス権を Config Sync に付与する必要があります。
Config Sync を使用して、組み込みの Kubernetes ClusterRole を直接管理することはできません。GKE には、
cluster-admin、admin、edit、viewなどの組み込みのユーザー向けロールが用意されています。これらの ClusterRole を Config Sync で直接管理することはできません。Config Sync が GKE と競合します。組み込みの ClusterRole に権限を追加するには、ロールの集約を使用して間接的に変更します。これらのロールを変更するには、信頼できる情報源に一意の名前の ClusterRole を作成して、適切なアノテーションを追加します。
信頼できる情報源を整理する
Config Sync は、リポジトリ全体から同期するように構成することも、特定のフォルダやブランチから同期するように構成することもできます。この柔軟性により、チームまたは組織のニーズに基づいて構成ファイルを整理できます。
Config Sync を構成する際には、sourceFormat を unstructured に設定することをおすすめします。構造化（階層型）ソースタイプでは、構成ファイルを正しく同期するには特定のフォルダ構造が必要となるため、ほとんどの場合、不必要に複雑になります。
このページを含む Config Sync のほとんどのドキュメントでは、デフォルトで非構造化形式を使用していますが、必要であれば、階層型リポジトリを使用するで階層型形式に関する情報を確認できます。
非構造化ソースを使用すると、チームのワークフローに合わせて構成ファイルを柔軟に整理できます。このセクションでは、リポジトリを構造化するための一般的なパターンをいくつか紹介します。
環境ベースのレイアウト
一般的な方法では、リポジトリを環境ごとに整理します。
├── cluster-essentials/
│ ├── crds/
│ └── namespace.yaml
├── environments/
│ ├── dev/
│ │ ├── backend/
│ │ └── frontend/
│ ├── staging/
│ │ ├── backend/
│ │ └── frontend/
│ └── prod/
│ ├── backend/
│ └── frontend/
└── system/
└── monitoring/
この例では、信頼できる情報源が次のように整理されています。
cluster-essentials/: 環境に関係なく、すべてのクラスタに適用される構成が含まれます。たとえば、カスタム リソース定義（CRD）や必須の Namespace などのリソースがこれに含まれます。environments/: すべての環境固有の構成の親ディレクトリです。system/: システムレベルのサービス（モニタリングなど）の構成が含まれます。
この方法は、わかりやすく操作が簡単で、ある環境から別の環境への変更のプロモーション パスも明確です。
このシナリオで Config Sync を設定する場合は、各クラスタに複数の RootSync オブジェクトを作成します。たとえば開発クラスタには、cluster-essentials/、system/、environments/dev/ から同期される RootSync オブジェクトがそれぞれ作成されます。
クラスタベースのレイアウト
構成が異なる個々のクラスタからなるフリートの管理に重点を置く場合は、クラスタベースのレイアウトの方が適している可能性があります。
├── clusters/
│ ├── cluster-a/
│ │ ├── apps/
│ │ └── networking/
│ ├── cluster-b/
│ │ ├── apps/
│ │ └── networking/
│ └── cluster-c/
│ ├── apps/
│ └── networking/
└── shared/
├── roles/
└── policies/
この例では、信頼できる情報源が次のように整理されています。
clusters/: 管理している各クラスタのディレクトリが含まれます。shared/: すべてのクラスタに共通の構成（RBAC ロールやセキュリティ ポリシーなど）を保持します。
この方法は、それぞれ固有の構成を持つ多くのクラスタを管理する場合に効果的です。構成が互いに分離され、所有権が明確になるためです。その一方で、共有されるクラスタ構成が多いと管理が複雑になる可能性があります。
このシナリオで Config Sync を設定する場合は、RepoSync を使用して、shared とクラスタ固有のディレクトリの両方から同期するように各クラスタを構成できます。
チームベースのレイアウト
複数のチームが複数のアプリケーションやサービスを管理している組織では、チームベースのレイアウトが効果的です。この方法では、信頼できる情報源の構造を組織構造に合わせます。
├── teams/
│ ├── team-alpha/
│ │ ├── app-one/
│ │ └── app-two/
│ ├── team-beta/
│ │ ├── service-a/
│ │ └── service-b/
│ └── team-gamma/
│ ├── data-pipeline/
│ └── dashboard/
└── platform/
├── cluster-roles/
└── storage-classes/
この例では、信頼できる情報源が次のように整理されています。
teams/: 構成をチームごとに整理し、各チームが独自のアプリケーションとサービスの構成を管理します。platform/: 中央のプラットフォーム チームが管理し、すべてのチームが使用する、クラスタ全体の構成が含まれます。
この方法を使用すると、各チームが独自の構成とリリース サイクルを管理できるようになるため、あるチームの変更が別のチームに誤って影響を与える可能性を減らすことができます。その一方で、アプリチームとプラットフォーム チームの依存関係を慎重に管理する必要があります。
このシナリオで Config Sync を設定する場合は、各チームが RootSync オブジェクトを使用して構成を同期します。たとえば、team-alpha は teams/team-alpha/ から同期します。
構成ファイルを検証する
信頼できる情報源を作成して整理し、構成ファイルを追加したら、nomos vet --source-format=unstructured コマンドを使用して、構成ファイルの構文と有効性を確認します。これにより、同期中または同期後のエラーを回避できます。
オブジェクトのミューテーションを無視する
クラスタ内に存在するようになったオブジェクトの状態を Config Sync が維持しないようにするには、Config Sync がミューテーションを無視するように client.lifecycle.config.k8s.io/mutation: ignore アノテーションをオブジェクトに追加します。
そのアノテーションをオブジェクトに追加する方法を、次の例に示します。
metadata:
annotations:
client.lifecycle.config.k8s.io/mutation: ignore
クラスタのマネージド オブジェクトでは、このアノテーションは手動で変更できません。
階層型リポジトリを非構造化リポジトリに変換する
階層型リポジトリを使用している場合に、それを非構造化リポジトリに変換するには、次のコマンドを実行します。
nomos hydrate PATH
PATH は、作業ディレクトリのパスに置き換えます。
これにより、現在の作業ディレクトリに compiled/ ディレクトリが作成されます。このディレクトリで、登録済みのクラスタごとにサブディレクトリが作成されます。これらのサブディレクトリには、完全に解決された構成ファイルが含まれており、非構造化リポジトリで使用できます。
詳細については、nomos コマンドをご覧ください。
リポジトリを手動で変換する場合は、次の手順を行います。
system/リポジトリのRepo構成ファイルを Git リポジトリから削除します。非構造化リポジトリにRepoリソースは必要ありません。非構造化リポジトリでは、抽象名前空間ディレクトリはサポートされていません。したがって、
namespaces/ディレクトリとそのサブディレクトリに元々含まれていたすべてのリソースの名前空間を宣言します。名前空間の継承は非構造化リポジトリでサポートされていません。したがって、もともと下位の名前空間に継承されているすべてのリソース（もともと
namespaces/ディレクトリにあるリソース）を宣言します。