非構造化リポジトリを使用する

非構造化リポジトリを使用すると、最も便利な方法でリポジトリを整理できます。この柔軟性により、既存の Kubernetes 構成を Config Sync リポジトリと同期させることができます。たとえば、Helm チャートをクラスタに同期するには、helm template コマンドを実行して、レンダリングされたマニフェストをリポジトリに commit します。詳細については、Config Sync と Helm の使用のチュートリアルをご覧ください。

ほとんどのユーザーには、非構造化形式の使用をおすすめします。ただし、階層リポジトリを作成して、構成ファイルをカテゴリに分類することもできます。階層リポジトリのルールに従わずに階層型ポリシーを作成する場合は、Hierarchy Controller の使用を検討してください。

制限事項

非構造化リポジトリには次の制限があります。

  • 非構造化リポジトリでは Repo または HierarchyConfig Kubernetes オブジェクトを使用できません。

  • 抽象 Namespace は、非構造化リポジトリではサポートされていません。

  • nomos vet コマンドを使用する場合は、--source-format=unstructured フラグを追加します。次に例を示します。

    nomos vet --source-format=unstructured

名前空間スコープ オブジェクト

非構造化リポジトリで NamespaceSelector を宣言できます。NamespaceSelector を宣言するには、metadata.namespace アノテーションまたは NamespaceSelector アノテーションのどちらかを追加します。両方のアノテーションを宣言することはできません。名前空間スコープのリソースで metadata.namespace または NamespaceSelector アノテーションが宣言されていない場合、Config Sync はクラスタのデフォルトの名前空間を使用します。詳細については、構成ファイルが影響を与える名前空間を制限するをご覧ください。

クラスタ スコープ オブジェクト

非構造化リポジトリでは、ClusterSelectors は正常に機能します。

非構造化リポジトリを構成する

非構造化リポジトリを構成するには、RootSync オブジェクトで spec.sourceFormat の値を unstructured に設定します。

  # root-sync.yaml
  apiVersion: configsync.gke.io/v1beta1
  kind: RootSync
  metadata:
    name: ROOT_SYNC_NAME
    namespace: config-management-system
  spec:
    sourceFormat: unstructured
    git:
      repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
      branch: main
      dir: config-sync-quickstart/multirepo/root
      auth: ssh
      secretRef:
        name: SECRET_NAME

次のように置き換えます。

  • ROOT_SYNC_NAME: RootSync オブジェクトの名前を追加します。この名前はクラスタ内で一意で、26 文字以下にする必要があります。
  • SECRET_NAME は、Secret の名前に置き換えます。

階層型リポジトリを非構造化リポジトリに変換する

階層型リポジトリを使用していて、それを非構造化リポジトリに変換する場合は、リポジトリで次のコマンドを実行します。

nomos hydrate PATH

PATH は、作業ディレクトリのパスに置き換えます。

これにより、現在の作業ディレクトリに compiled/ ディレクトリが作成されます。このディレクトリで、登録済みのクラスタごとにサブディレクトリが作成され、完全に解決された構成ファイルが保存されます。各サブディレクトリは非構造化リポジトリで使用できます。

詳細については、nomos コマンドをご覧ください。

リポジトリを手動で変換する場合は、次の手順を行います。

  1. system/ リポジトリの Repo 構成ファイルを Git リポジトリから削除します。非構造化リポジトリに Repo リソースは必要ありません。

  2. 非構造化リポジトリでは、抽象名前空間ディレクトリはサポートされていません。namespaces/ ディレクトリとそのサブディレクトリに元々含まれていたすべてのリソースの名前空間を宣言する必要があります。

  3. 名前空間の継承は非構造化リポジトリでサポートされていません。したがって、もともと下位の名前空間に継承されているすべてのリソース、つまり、もともと namespaces/ ディレクトリにあるリソースを宣言する必要があります。

非構造化リポジトリの形式例

次の例は、非構造化リポジトリで構成ファイル（Google Cloud リソースを含む）を整理する方法を示しています。

├── 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

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

次のステップ