Config Sync の概要

Config Sync は、クラスタ オペレータとプラットフォーム管理者が一貫した構成とポリシーをデプロイできるオープンソースのツールです。これらの構成とポリシーは、個々の Kubernetes クラスタだけでなく、ハイブリッド環境とマルチクラウド環境にまたがる複数のクラスタや、クラスタ内の複数の名前空間にデプロイできます。このプロセスにより、大規模な環境での構成とポリシー管理作業を簡素化、自動化できます。Config Sync を使用すると、開発チームは管理者が設定したポリシー ガードレールを適用しながら、クラスタ内の名前空間を個別に管理することもできます。

Config Sync は Kubernetes 自体と同じ原則を使用しています。中央の Kubernetes の宣言型の構成ファイル(構成ファイル)のセットを使用して、登録済みのクラスタの状態を継続的に調整します。構成ファイルは 1 つ以上の Git リポジトリに格納され、Config Sync は構成された Kubernetes オブジェクトの整合性を維持します。この GitOps アプローチ(Configuration as Code とも呼ばれます)を使用することで、監査、トランザクション管理、レビュー、バージョン管理が可能なプロセスを使用して、共通の構成を管理し、デプロイできます。

次の図では、プラットフォーム管理者が、クラスタと Namespace に構成ファイルを適用することで 3 つの異なるクラスタに一貫した構成を作成しています。

プラットフォーム管理者が複数の構成ファイルをクラスタにデプロイしています。

Config Sync のメリット

Config Sync を使用する主なメリットは次のとおりです。

  • 「シャドウ オペレーション」のリスクを軽減する: 十分に検証されていない変更がライブクラスタに push されると、文書化された構成とライブ環境の違いを理解するのが難しくなります。クラスタ構成に対するすべての変更が必ず Config Sync を介して適用されるようにすることで、Kubernetes API への直接アクセスを禁止し、Git の信頼できる情報源と比較して変更を追跡できます。
  • GitOps のベスト プラクティスを使用する: ライブ環境に変更が push される前に、任意のリポジトリ管理ツールでコードレビューを行うことを必須できます。Config Sync を使用して、構成の変更の原因となった commit を監査します。
  • 構成関連の停止によるダウンタイムを削減する: Config Sync では、「元に戻してから調査」という戦略を使用します。破壊的な変更をロールバックしてライブクラスタを正常な動作状態に戻してから、問題のある変更を修正して新しい commit として適用します。
  • 継続的インテグレーション / 継続的デプロイ(CI / CD)パイプラインを使用する: CI / CD ワークフローを使用して、任意のツールと形式で構成のレンダリング、変更のテスト、検証を行い、テストに合格したときに変更を自動的に commit できます。その後、Config Sync が変更を適用し、以降の構成のずれをモニタリングして修正します。

Config Sync について

前提条件

Config Sync は、実装のコア部分として名前空間ラベルアノテーションを使用しています。プロダクトを使い始める前に、これらのコンセプトをよく理解しておくことをおすすめします。

クラスタの構成

Config Sync では、Git の信頼できる単一の情報源から構成の共通セットとクラスタレベルのポリシー(Policy Controller の制約など)を作成し、登録済みで接続しているクラスタに一貫した方法で適用できます。クラスタを構成する前に、構成とリポジトリを作成しておく必要があります。

構成ファイル

構成ファイルは、YAML または JSON で記述された Kubernetes 構成の宣言です。Config Sync は構成ファイルを読み取り、1 つ以上のクラスタに適用します。これにより、クラスタ内の Kubernetes オブジェクトやリソースを作成または構成します。また、Config Sync 自体が必要とする情報を提供します。構成ファイルには、kubectl edit または kubectl apply を使用して、Kubernetes クラスタに適用可能な任意の構成情報を含めることができます。1 つのファイルで複数の構成ファイルを宣言することもできます。Config Sync は 3 種類のファイル(.yaml.yml.json)を読み取ります。他の拡張子のファイルは無視されます。

構成ファイルを作成する前に、構成ファイルに記述する Kubernetes オブジェクトについて理解しておく必要があります。

詳細については、Git リポジトリに構成ファイルを追加する構成ファイルを作成するをご覧ください。

リポジトリ

リポジトリ(またはリポ)は、構成ファイル(Config Sync 自体の構成ファイルも含む)が保存されている Git リポジトリです。Config Sync を構成するときに、変更をモニタリングするリポジトリ、ブランチ、サブディレクトリを構成します。

Config Sync を使用すると、複数のリポジトリの構成を同じクラスタのセットに同期できます。Config Sync では、Git のリファレンス(Git URL、リポジトリ ブランチ、commit またはタグ、ディレクトリ)を使用して各リポジトリを参照できます。この構成により、構成ファイルのデプロイ ライフサイクルがチーム別に切り離されます。また、リポジトリを配置する場所の選択と、リポジトリを構成する方法の自由度も高まります。

ルート リポジトリと名前空間リポジトリの 2 種類のリポジトリを作成できます。

  • ルート リポジトリ: ルート リポジトリを使用すると、クラスタ スコープ名前空間スコープの各構成ファイルを同期できます。ルート リポジトリは、管理者レベルの認証情報を使用してアプリケーションの Namespace にポリシーを適用し、構成ファイルで宣言された状態からずれているローカルの変更をオーバーライドします。通常、ルート リポジトリは中央管理者によって管理されます。

    ルート リポジトリには次の 2 つの構造を使用できます。

    • 非構造化: 非構造化ソース形式を使用すると、リポジトリ内の構成ファイルを最適な方法で整理できます。この形式は、Kustomizekpthelm などのツールで構成ファイルを整理または生成する場合に特に便利です。非構造化は、ほとんどのユーザーに推奨される形式です。これは、Google Cloud Console を使用して Config Sync を構成する際のデフォルトの形式です。詳細については、非構造化リポジトリの使用をご覧ください。
    • 階層型: 階層型または構造化されたソース形式では、構成ファイルをシステム構成、クラスタ メタデータ、クラスタレベルの構成、名前空間構成などのカテゴリに分類して整理できます。また、ディレクトリ構造に基づいて複数の Namespace で構成の階層構造を継承することもできます。詳細については、Namespace の構成をご覧ください。マニフェストで sourceFormat を指定していない場合、階層型が Config Sync のデフォルトのリポジトリ形式になります。詳細については、階層リポジトリの概要をご覧ください。

    ルート リポジトリを構成する方法については、Config Sync をインストールするをご覧ください。

  • 名前空間リポジトリ: 名前空間リポジトリはオプションです。名前空間スコープの構成ファイルを保存し、クラスタ間で特定の名前空間に同期できます。名前空間リポジトリの設定と制御を管理者以外のユーザーに委任することもできます。名前空間リポジトリには非構造化形式を使用する必要があります。

次の図は、管理者がクラスタを単一のルート リポジトリ(管理者が管理)と複数の名前空間リポジトリ(アプリケーション オペレータが管理)にどのように同期するかの概要を示しています。

複数の構成ファイルを管理する中央管理者と、それぞれが自前の Namespace 構成ファイルを管理するアプリ オペレータ。

前の図では、中央管理者が組織の一元化されたインフラストラクチャを管理し、クラスタと組織内のすべての Namespace にポリシーを適用します。実際のデプロイメントを管理するアプリケーション オペレータは、取り組んでいる Namespace 内のアプリケーションに構成を適用します。

複数のクラスタを構成する

Config Sync を使用すると、ハイブリッド環境とマルチクラウド環境にまたがる複数のクラスタに一貫した方法で構成やポリシーをデプロイできます。

Config Sync では、次のオプションを使用して複数のクラスタを構成できます。

クラスタを登録することを強くおすすめします。クラスタを登録すると、Google Cloud Console からすべてのクラスタの現在のステータスをモニタリングし、Config Sync で登録済みのクラスタの構成と管理を一元的に行うことができます。詳細については、クラスタの登録Config Sync の構成Config Sync バージョンのアップグレードをご覧ください。

名前空間を構成する

Config Sync で名前空間を構成すると、次のことが可能になります。

  • 登録済みで接続しているクラスタ全体で、名前空間スコープのポリシー(RBAC ロールなど)を使用して、Kubernetes 名前空間のプロビジョニングを一貫した方法で行うことができます。名前空間スコープのポリシーを使用すると、クラスタ内でマルチテナンシーの実装と管理をより簡単に行うことができます。
  • 構成ファイルを複製することなく、複数の関連する名前空間にポリシーを適用します。特定の名前空間または名前空間セットの構成をオーバーライドまたは拡張できるため、テナント間で一貫したポリシーを簡単に適用できます。

これらの機能は、リポジトリの形式(非構造化階層型か)によって動作が異なります。

非構造化リポジトリの場合は、Hierarchy Controller を使用して、クラスタに定義したポリシーを名前空間の階層全体に伝播できます。詳細については、Hierarchy Controller の概要をご覧ください。

階層型リポジトリの場合は、抽象名前空間という名前空間グループを使用して、伝播する名前空間ポリシーを制御できます。抽象名前空間では、リポジトリのディレクトリ ツリーを使用して名前空間を階層的に整理する必要があります。詳細については、名前空間と名前空間スコープ オブジェクトの構成名前空間の継承の概要をご覧ください。

どちらのリポジトリの形式(非構造化か階層型か)でも、ラベルセレクタを使用して階層外の名前空間セットをターゲットに設定できます。

nomos コマンド

Config Sync には API が用意されています。nomos(Windows の場合は nomos.exe)コマンドは、この API を使用してインストール ステータスを確認し、構成ファイルを検証します。

詳細については、nomos コマンドライン ツールの使用をご覧ください。

Config Sync RBAC / 権限

以下のセクションでは、Config Sync とそのコンポーネントにクラスタレベルで適切なアクセス権を付与する方法について説明します。リストされている権限はデフォルトで有効になっています。Config Sync の使用中は無効にしないでください。

コンポーネント Namespace サービス アカウント 権限 説明
reconciler-manager config-management-system reconciler-manager cluster-admin ルート Reconciler をプロビジョニングし、ルート Reconciler の ClusterRoleBinding を作成するには、reconciler-manager が cluster-admin である必要があります。
root reconcilers config-management-system ルート Reconciler の名前 cluster-admin クラスタ スコープのリソースとカスタム リソースを適用するには、ルート Reconciler が cluster-admin である必要があります
namespace reconcilers config-management-system Namespace Reconciler の名前 configsync.gke.io:ns-reconciler Namespace Reconciler には、RepoSync オブジェクト、ResourceGroup オブジェクト、これらのステータスを取得または更新する権限が必要です
resource-group-controller-manager config-management-system resource-group-sa resource-group-manager-role resource-group-leader-election-role resource-group-controller-manager には、オブジェクトのステータスを確認し、リーダー選出を有効にするロールが必要です。
admission-webhook config-management-system admission-webhook cluster-admin クラスタ内の任意のオブジェクトに対するリクエストを拒否するには、アドミッション Webhook を cluster-admin にする必要があります。
importer config-management-system importer cluster-admin ユーザーに設定権限が必要なため、RBAC の権限を設定するには、importer が cluster-admin cluster-admin である必要があります。

Namespace Reconciler の RBAC

次の API 定義は、Namespace Reconciler のアクセス制御権限を示しています。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: configsync.gke.io:ns-reconciler
  labels:
    configmanagement.gke.io/system: "true"
    configmanagement.gke.io/arch: "csmr"
rules:
- apiGroups: ["configsync.gke.io"]
  resources: ["reposyncs"]
  verbs: ["get"]
- apiGroups: ["configsync.gke.io"]
  resources: ["reposyncs/status"]
  verbs: ["get","list","update"]
- apiGroups: ["kpt.dev"]
  resources: ["resourcegroups"]
  verbs: ["*"]
- apiGroups: ["kpt.dev"]
  resources: ["resourcegroups/status"]
  verbs: ["*"]
- apiGroups:
  - policy
  resources:
  - podsecuritypolicies
  resourceNames:
  - acm-psp
  verbs:
  - use

リソース グループ コントローラの RBAC

次の API 定義は、リソース グループ コントローラのアクセス制御の権限を示しています。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  labels:
    configmanagement.gke.io/arch: "csmr"
    configmanagement.gke.io/system: "true"
  name: resource-group-manager-role
rules:
# This permission is needed to get the status for managed resources
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
# This permission is needed to watch/unwatch types as they are registered or removed.
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
  - list
  - watch
# This permission is needed so that the ResourceGroup controller can reconcile a ResourceGroup CR
- apiGroups:
  - kpt.dev
  resources:
  - resourcegroups
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
# This permission is needed so that the ResourceGroup controller can update the status of a ResourceGroup CR
- apiGroups:
  - kpt.dev
  resources:
  - resourcegroups/status
  verbs:
  - get
  - patch
  - update
# This permission is needed so that the ResourceGroup controller can work on a cluster with PSP enabled
- apiGroups:
  - policy
  resourceNames:
  - acm-psp
  resources:
  - podsecuritypolicies
  verbs:
  - use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    configmanagement.gke.io/arch: "csmr"
    configmanagement.gke.io/system: "true"
  name: resource-group-leader-election-role
  namespace: resource-group-system
rules:  // The following permissions are needed so that the leader election can work
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete
- apiGroups:
  - ""
  resources:
  - configmaps/status
  verbs:
  - get
  - update
  - patch
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  verbs:
  - '*'

次のステップ