読み取り専用リポジトリとの同期

このクイックスタートでは、foo-corp example repo を使用して Config Sync を新しいクラスタで起動し、一連の構成を使用してクラスタをブートストラップする方法について説明します。このクイックスタートでは、リポジトリへの書き込み権限は必要ありません。以下では、組織のコンプライアンス チームが構成の作成を担当し、クラスタをリポジトリと同期する必要があることを前提として説明します。

このクイックスタートを終了すると、構成の作成、テスト、同期に関する上級クイックスタートに進むことができます。

始める前に

  1. クラスタを作成する。

  2. クラスタの認証を行うように kubectl コマンドを設定します。次のコマンドを実行して、自分自身をクラスタ管理者にする RoleBinding を作成します。[MY-CLUSTER] にあるクラスタ名を使用し、[USER-ACCOUNT] にある Cloud 請求先アカウントのメールアドレスを使用します。ローカル システムでの gcloud コマンドの構成方法によっては、--project フィールドと --zone フィールドの追加が必要になる場合があります。

    gcloud container clusters get-credentials [MY-CLUSTER]

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole cluster-admin --user [USER_ACCOUNT]

  3. ローカル システムに nomos コマンドをインストールします。

  4. 作成したクラスタに Config Sync Operator をインストールします。

クラスタを構成する

config-management.yaml を作成し、下の YAML をコピーします。リポジトリは読み取り制限がないので、secretType は none に設定されています。フィールドの詳細については、Git リポジトリの構成をご覧ください。

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  # clusterName is required and must be unique among all managed clusters
  clusterName: my-cluster
  git:
    syncRepo: https://github.com/GoogleCloudPlatform/csp-config-management/
    syncBranch: 1.0.0
    secretType: none
    policyDir: "foo-corp"

クラスタに構成を適用します。

kubectl apply -f config-management.yaml

コマンドが成功すると、Kubernetes はクラスタの Config Sync Operator を更新し、リポジトリからのクラスタ構成の同期を開始します。Config Sync Operator が実行されていることを確認するには、config-management-system 名前空間で実行されている Pod のリストを取得します。

kubectl get pods -n config-management-system

出力:

NAME                                   READY     STATUS    RESTARTS   AGE
git-importer-5f8bdb59bd-7nn5m          2/2       Running   0          2m
monitor-58c48fbc66-ggrmd               1/1       Running   0          2m
syncer-7bbfd7686b-dxb45                1/1       Running   0          2m

クラスタとリポを調べる

foo-corp リポジトリの cluster/ ディレクトリと namespaces/ ディレクトリに構成ファイルが配置されています。リポジトリから読み取るように Config Sync Operator が構成されるとすぐに、これらの構成ファイルが適用されます。

Config Sync で管理されるオブジェクトの app.kubernetes.io/managed-by ラベルは configmanagement.gke.io に設定されています。

次のコマンドを実行して、Config Sync で管理されている名前空間の一覧を取得します。

kubectl get ns -l app.kubernetes.io/managed-by=configmanagement.gke.io

出力:

NAME               STATUS   AGE
audit              Active   4m
shipping-dev       Active   4m
shipping-prod      Active   4m
shipping-staging   Active   4m

これらの名前空間を作成した構成ファイル（namespaces/audit/namespace.yaml、namespaces/online/shipping-app-backend/shipping-dev/namespace.yaml など）を調べます。

次のコマンドを実行して、Config Sync で管理されている ClusterRoles の一覧を取得します。

kubectl get clusterroles -l app.kubernetes.io/managed-by=configmanagement.gke.io

出力:

NAME               AGE
namespace-reader   6m52s
pod-creator        6m52s

ClusterRole の構成ファイルの宣言を調べます。

  • cluster/namespace-reader-clusterrole.yaml
  • cluster/pod-creator-clusterrole.yaml

同じ方法で Roles や PodSecurityPolicies などの他のオブジェクトも検証できます。

マネージド オブジェクトを手動で変更しようとした場合

Config Sync によって管理されている Kubernetes オブジェクトを手動で変更すると、そのオブジェクトの構成は、リポジトリ内のオブジェクトの構成ファイルと一致するよう自動的に更新されます。これをテストするには、shipping-dev 名前空間を削除します。

kubectl delete namespace shipping-dev

すぐに確認すると、この名前空間がリストから消えたことがわかりますが、数秒以内に再びリストに現れます。例:

kubectl get ns shipping-dev

出力:

Error from server (NotFound): namespaces "shipping-dev" not found

数秒後に次のコマンドを実行します。

kubectl get ns shipping-dev

出力:

NAME           STATUS   AGE
shipping-dev   Active   3s

クリーンアップ

このトピックの演習を終えたら、テストに使用したクラスタを削除してクリーンアップ作業を行います。

次のステップ