階層リポジトリと同期する

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

目標

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

料金

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

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

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

始める前に

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

注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

プロジェクトセレクタに移動
Google Cloud プロジェクトの課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。
Config Sync がすでにインストールされているクラスタへのアクセス権を取得します。このようなクラスタがない場合は、Git リポジトリからの同期のチュートリアルの「始める前に」セクションと「環境の準備」セクションの手順を行います。
1. 次のコマンドを実行して、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 と Google Cloud CLI を使用して、クラスタを階層リポジトリに同期させます。

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

Google Cloud CLI を使用して apply-spec.yaml ファイルを適用します。
```
 gcloud alpha container fleet config-management apply \
     --membership=CLUSTER_NAME \
     --config=CONFIG_YAML_PATH \
     --project=PROJECT_ID
```
次のように置き換えます。
- CLUSTER_NAME: この構成を適用する登録済みクラスタの名前
- CONFIG_YAML_PATH: apply-spec.yaml ファイルのパス
- PROJECT_ID: プロジェクト ID

Config Sync がすべての構成ファイルをクラスタに正常に同期させたことを確認します。

gcloud alpha container fleet 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 に設定されているため、このラベルを使用してリソースをクエリできます。

次のコマンドを実行して、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

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

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 アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトの削除

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このチュートリアルで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のチュートリアルとクイックスタートを検討する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て制限を超えないようにできます。

Google Cloud コンソールで、[リソースの管理] ページに移動します。
[リソースの管理] に移動
プロジェクトリストで、削除するプロジェクトを選択し、[削除] をクリックします。
ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

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

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

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

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

gcloud container clusters delete CLUSTER_NAME

次のステップ

Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud Architecture Center をご覧ください。

階層リポジトリと同期する

目標

料金

始める前に

リポジトリ アーキテクチャを調べる

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

構成ファイルを調べる

クリーンアップ

プロジェクトの削除

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

次のステップ

リポジトリアーキテクチャを調べる

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