階層型リポジトリとの同期

このチュートリアルでは、Config Sync の階層型ルート リポジトリを使用して、異なる 2 チーム(team-1team-2)で共有される Kubernetes クラスタの構成を管理する方法について説明します。

目標

  • 階層型リポジトリを使用する際のベスト プラクティスについて確認します。
  • サンプルの階層型リポジトリにクラスタを同期させます。

料金

このチュートリアルでは、課金対象である次の Google Cloud コンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただけます。

このチュートリアルを終了した後、作成したリソースを削除すると、それ以上の請求は発生しません。詳しくは、クリーンアップをご覧ください。

新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

始める前に

  1. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

    プロジェクト セレクタに移動

  2. Cloud プロジェクトに対して課金が有効になっていることを確認します。プロジェクトに対して課金が有効になっていることを確認する方法を学習する

  3. Config Sync がすでにインストールされているクラスタへのアクセス権を取得します。このようなクラスタが存在しない場合は、Anthos のクイックスタートか、GKE のクイックスタートの「始める前に」と「環境の準備」セクションの手順を行います。
  4. 次のコマンドを実行して、kubectl コマンドライン アクセス権を構成します。

    gcloud container clusters get-credentials CLUSTER_NAME \
        --zone ZONE \
        --project PROJECT_ID
    

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

    • CLUSTER_NAME: この構成を適用する登録済みクラスタの名前
    • ZONE: クラスタを作成したゾーン
    • PROJECT_ID: プロジェクト ID

リポジトリの構造を確認する

このチュートリアルでは、hierarchical-format/ リポジトリconfig/ ディレクトリ内の構成ファイルと同期するように Config Sync を構成します。config/ ディレクトリは、次のディレクトリとファイルで構成されます。

├── cluster
│   ├── clusterrolebinding-namespace-reader.yaml
│   ├── clusterrole-namespace-reader.yaml
│   ├── clusterrole-secret-admin.yaml
│   ├── clusterrole-secret-reader.yaml
│   └── crontab-crd.yaml
├── namespaces
│   ├── limit-range.yaml
│   ├── team-1
│   │   ├── crontab.yaml
│   │   ├── namespace.yaml
│   │   ├── network-policy-default-deny-egress.yaml
│   │   ├── resource-quota-pvc.yaml
│   │   ├── rolebinding-secret-reader.yaml
│   │   └── sa.yaml
│   └── team-2
│       ├── crontab.yaml
│       ├── namespace.yaml
│       ├── network-policy-default-deny-all.yaml
│       ├── resource-quota-pvc.yaml
│       ├── rolebinding-secret-admin.yaml
│       └── sa.yaml
├── README.md
└── system
    └── repo.yaml

有効な Config Sync の階層型ルート リポジトリには、3 つのサブディレクトリ(cluster/namespaces/system/)が含まれている必要があります。

cluster/ ディレクトリには、Namespace ではなく、クラスタ全体に適用される構成ファイル(CRD、ClusterRole、ClusterRoleBinding など)が入っています。

namespaces/ ディレクトリには、Namespace オブジェクトと Namespace スコープ オブジェクトの構成ファイルが入っています。namespaces/ の各サブディレクトリには、Namespace オブジェクトの構成ファイルと、Namespace の下にあるすべての Namespace スコープ オブジェクトの構成ファイルが入っています。サブディレクトリの名前は、Namespace オブジェクトの名前と同じにする必要があります。各 Namespace に作成する必要がある Namespace スコープ オブジェクトは、namespaces/ の直下に配置できます(例: namespaces/limit- range.yaml)。

このチュートリアルでは、チームそれぞれに独自の Kubernetes Namespace、Kubernetes サービス アカウント、リソース割り当て、ネットワーク ポリシー、RoleBinding があります。クラスタ管理者は、namespaces/limit-range.yaml にポリシーを設定して、Pod とコンテナ両方の Namespace でリソースの割り当てを制限します。また、クラスタ管理者は、ClusterRole と ClusterRoleBinidng も設定します。

system/ ディレクトリには、Config Sync Operator の構成ファイルが入っています。


compiled/ ディレクトリ(Config Sync の使用には必要ありません)には、nomos hydrate の出力が入っています。この出力は、cluster/namespaces/system/ の各ディレクトリ配下から正確な形式への構成ファイルを束ねたもので、APIServer に送信して適用されます。クラスタ スコープのリソースは、このディレクトリの下に置かれます。各サブディレクトリには、Namespace の配下にあるリソースの構成ファイルがすべて入っています。compiled/ ディレクトリは、次のディレクトリとファイルで構成されます。

.
├── clusterrolebinding_namespace-reader.yaml
├── clusterrole_namespace-reader.yaml
├── clusterrole_secret-admin.yaml
├── clusterrole_secret-reader.yaml
├── customresourcedefinition_crontabs.stable.example.com.yaml
├── namespace_team-1.yaml
├── namespace_team-2.yaml
├── team-1
│   ├── crontab_my-new-cron-object.yaml
│   ├── limitrange_limits.yaml
│   ├── networkpolicy_default-deny-egress.yaml
│   ├── resourcequota_pvc.yaml
│   ├── rolebinding_secret-reader.yaml
│   └── serviceaccount_sa.yaml
└── team-2
    ├── crontab_my-new-cron-object.yaml
    ├── limitrange_limits.yaml
    ├── networkpolicy_default-deny-all.yaml
    ├── resourcequota_pvc.yaml
    ├── rolebinding_secret-admin.yaml
    └── serviceaccount_sa.yaml

Config Sync を使用してクラスタをルート リポジトリに同期させる

このセクションでは、Config Sync と gcloud コマンドライン ツールを使用して、クラスタを階層型リポジトリに同期させます。

  1. apply-spec.yaml という名前のファイルを作成し、次のテキストを貼り付けます。

    # apply-spec.yaml
    
    applySpecVersion: 1
    spec:
      configSync:
        enabled: true
        sourceFormat: hierarchy
        syncRepo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples/
        syncBranch: init
        secretType: none
        policyDir: hierarchical-format/config
    
  2. gcloud コマンドライン ツールを使用して、apply-spec.yaml ファイルを適用します。

     gcloud alpha container hub config-management apply \
         --membership=CLUSTER_NAME \
         --config=CONFIG_YAML_PATH \
         --project=PROJECT_ID
    

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

    • CLUSTER_NAME: この構成を適用する登録済みクラスタの名前
    • CONFIG_YAML_PATH: apply-spec.yaml ファイルのパス
    • PROJECT_ID: プロジェクト ID
  3. Config Sync がすべての構成ファイルをクラスタに正常に同期させたことを確認します。

    gcloud alpha container hub config-management status
        --project=PROJECT_ID
    

    出力例:

    Name          Status  Last_Synced_Token  Sync_Branch  Last_Synced_Time      Policy_Controller                          Hierarchy_Controller
    CLUSTER_NAME  SYNCED  6bfc9be            init         2021-06-08T17:26:32Z  GatekeeperControllerManager NOT_INSTALLED  PENDING
    

    正常にインストールされていれば、ステータスは SYNCED になります。

構成ファイルを検査する

config/ ディレクトリには、以下のリソースが入っています。

  • ClusterRole
  • ClusterRoleBinding
  • CRD
  • Namespace
  • RoleBinding
  • ServiceAccount
  • ResourceQuota
  • NetworkPolicy
  • LimitRange
  • CR

これらの構成ファイルは、Config Sync がリポジトリから読み取るように構成されると、すぐに適用されます。このセクションでは、Config Sync がディレクトリ内の Namespace、CRD、RoleBinding を管理していることを確認します。

Config Sync が管理するすべてのオブジェクトでは、app.kubernetes.io/managed-by ラベルが configmanagement.gke.io に設定されているため、このラベルを使用してリソースをクエリできます。

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

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

    出力例:

    NAME        STATUS   AGE
    team-1      Active   28m
    team-2      Active   28m
    
  2. Config Sync が管理する CRD を一覧表示します。

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

    出力例:

    NAME                          CREATED AT
    crontabs.stable.example.com   2021-05-04T14:58:14Z
    
  3. Config Sync が管理する RoleBinding を一覧表示します。

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

    出力例:

    NAMESPACE   NAME                            ROLE                        AGE
    team-1      secret-reader                   ClusterRole/secret-reader   29m
    team-2      secret-admin                    ClusterRole/secret-admin    29m
    

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトの削除

  1. Cloud Console で [リソースの管理] ページに移動します。

    [リソースの管理] に移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

リソースを個別に削除する

Config Sync によるクラスタの管理を停止するには、次のコマンドを実行します。

gcloud alpha container hub config-management unmanage \
    --project=PROJECT_ID \
    --membership=CLUSTER_NAME

クラスタを削除するには、次のコマンドを実行します。

gcloud container clusters delete CLUSTER_NAME

次のステップ