Git リポジトリでの構成ファイルの使用

Config Sync は、多数のクラスタを管理するクラスタ オペレータ向けに設計されています。Config Sync にすべてのクラスタの Namespace、Role、RoleBinding、ResourceQuota、その他の重要な Kubernetes オブジェクトの管理を任せることで、運用するクラスタがビジネスやコンプライアンスの基準を確実に遵守するようにできます。

Config Sync は、構成ファイルを使用して、登録されたクラスタの同期を行います。構成ファイルは Git リポジトリに保存されている YAML または JSON ファイルであり、これには kubectl apply コマンドを使用して手動でクラスタに適用できるものと同じタイプの構成情報が含まれています。クラスタ内に存在可能な Kubernetes オブジェクトの構成ファイルを作成できます。このトピックでは、次の項目について説明します。

  • ディレクトリ内の構成ファイルを整理する方法。
  • 構成ファイルを保存する Git リポジトリを初期化する方法。
  • 構成ファイルから読み取るように Config Sync を構成する方法。

構成ファイルをリポジトリに保存する

Config Sync は、構成ファイルのストレージとバージョン管理に Git リポジトリを使用し、そのコンテンツに基づいてアクションを実行します。Config Sync では、このリポジトリを「リポ」といいます。リポには、非構造化階層型の 2 つの形式があります。

  • 非構造化ソース形式を使用すると、リポジトリ内の構成ファイルを最適な方法で整理できます。この形式は、kustomizekpthelm などのツールで構成ファイルを整理または生成する場合に特に便利です。
  • 階層型または構造化されたソース形式では、構成ファイルをカテゴリに分類して整理できます。カテゴリとしては、システム構成、クラスタ メタデータ、クラスタレベルの構成、名前空間構成があります。階層型リポジトリ構造の詳細については、階層型リポジトリの構造をご覧ください。

次の表に、階層型リポジトリと非構造化リポジトリの形式の相違点を示します。

機能 階層型リポジトリの形式 非構造化リポジトリの形式
Namespace セレクタ サポート対象 サポート対象
クラスタ セレクタ サポート対象 サポート対象
抽象 Namespace サポート対象 非対応
Repo オブジェクト サポート対象 非対応
HierarchyConfig オブジェクト サポート対象 非対応
Hierarchy Controller の階層型 Namespace 非対応 サポート対象
Namespace リポジトリの形式として使用 非対応 サポート対象
ルート リポジトリの形式として使用 サポート対象 サポート対象
Hierarchy Controller と一緒に使用 非推奨 サポート対象
nomos init コマンド サポート対象 非対応
nomos hydrate コマンド サポート対象 非対応
nomos vet コマンド サポート対象 --source-format=unstructured フラグでサポート
その他のすべての nomos コマンド サポート対象 サポート対象

非構造化構成ファイルのレイアウト例

次の例は、Google Cloud リソースを含む構成ファイルを整理する方法を示しています。

未加工の構成ファイルを raw-configs ディレクトリに配置し、スクリプトまたは自動パイプラインを使用して未加工の構成ファイルをレンダリングし、出力を manifests ディレクトリに格納できます。最後に、Config Sync を manifests ディレクトリから同期するように構成します。

├── manifests
│   ├── access-control
│   │   ├── ...
│   ├── change-control
│   │   ├── ...
│   ├── git-ops
│   │   └── ...
│   ├── logging-monitoring
│   │   └── ...
│   ├── networking
│   │   └── ...
│   ├── project-factory
│   │   └── ...
│   └── resource-hierarchy
│   │   └── ...
├── raw-configs
│   ├── access-control
│   │   └── ...
│   ├── change-control
│   │   └── ...
│   ├── git-ops
│   │   └── ...
│   ├── logging-monitoring
│   │   └── ...
│   ├── networking
│   │   └── ...
│   ├── project-factory
│   │   └── ...
│   └── resource-hierarchy
│   │   └── ...
└── scripts
    └── render.sh

Git リポジトリの初期化

リポジトリを初期化する方法は、その構造によって異なります。

  • 非構造化形式では、空の Git リポジトリを初期化し、リポで構成ファイルの追加を開始できます。
  • 階層形式の場合、nomos init コマンドを使用してリポを初期化することも、ディレクトリ構造を手動で作成することもできます。

リポジトリから読み取る Config Sync の構成

Config Sync をインストールするときに、リポの場所を構成します。この構成は、あとで Operator の構成ファイルで編集することもできます。Git リポジトリに構成以外のコンテンツがある場合は、リポの場所に加えて、監視する Git ブランチとサブディレクトリを指定できます。

構成ファイルの更新後、kubectl apply コマンドを使用して、構成をクラスタに適用します。Config Sync は Operator 自身の構成を管理しません。

特定のプロダクト チームのデプロイリポへのアクセス権を付与できます。ただし、デプロイリポへのアクセス権をユーザーに付与すると、そのリポで実行される調整者と同じ RBAC もそのユーザーに付与されることになります。

Config Sync とリポ間の認証と認可を構成する方法については、git-creds Secret の構成に関するインストール手順をご覧ください。

オブジェクトのミューテーションを無視する

背後にクラスタが存在するオブジェクトの状態を Config Sync が維持しないようにするには、Config Sync がミューテーションを無視するように client.lifecycle.config.k8s.io/mutation: ignore アノテーションをオブジェクトに追加します。アノテーションを使用するには、マルチリポジトリ モードを有効にして、1.7.0 以降のバージョンを使用する必要があります。

そのアノテーションをオブジェクトに追加する方法を、次の例に示します。

metadata:
  annotations:
    client.lifecycle.config.k8s.io/mutation: ignore 

クラスタのマネージド オブジェクトでは、このアノテーションは手動で変更できません。

次のステップ