マルチテナント クラスタのポリシーの作成

このチュートリアルでは、Config Sync と Kustomize を使用してマルチテナント クラスタ内の Namespace のポリシーを構成する方法について説明します。

Kubernetes では、テナントはチームまたはワークロードです。マルチテナント クラスタの場合、Namespace は、テナントごとに作成することをおすすめします。そうすると、各 Namespace には、それぞれのニーズに合ったポリシーを設定できます。Config Sync は、こうしたポリシーをそれぞれのテナントに一貫して適用するために使用できます。

リポジトリのアーキテクチャ

このチュートリアルでは、Config Sync を、Anthos Config Management サンプル リポジトリの namespace-specific-policy/ ディレクトリ内の構成ファイルと同期するように構成します。そのディレクトリは、次のディレクトリとファイルで構成されています。

├── configsync
│   ├── tenant-a
│   │   ├── ~g_v1_namespace_default.yaml
│   │   ├── networking.k8s.io_v1_networkpolicy_deny-all.yaml
│   │   ├── rbac.authorization.k8s.io_v1_rolebinding_tenant-admin-rolebinding.yaml
│   │   └── rbac.authorization.k8s.io_v1_role_tenant-admin.yaml
│   ├── tenant-b
│   │   ├── ~g_v1_namespace_default.yaml
│   │   ├── networking.k8s.io_v1_networkpolicy_deny-all.yaml
│   │   ├── rbac.authorization.k8s.io_v1_rolebinding_tenant-admin-rolebinding.yaml
│   │   └── rbac.authorization.k8s.io_v1_role_tenant-admin.yaml
│   └── tenant-c
│       ├── ~g_v1_namespace_default.yaml
│       ├── networking.k8s.io_v1_networkpolicy_deny-all.yaml
│       ├── rbac.authorization.k8s.io_v1_rolebinding_tenant-admin-rolebinding.yaml
│       └── rbac.authorization.k8s.io_v1_role_tenant-admin.yaml
├── configsync-src
│   ├── base
│   │   ├── kustomization.yaml
│   │   ├── namespace.yaml
│   │   ├── networkpolicy.yaml
│   │   ├── rolebinding.yaml
│   │   └── role.yaml
│   ├── tenant-a
│   │   └── kustomization.yaml
│   ├── tenant-b
│   │   └── kustomization.yaml
│   └── tenant-c
│       └── kustomization.yaml
├── README.md
└── scripts
    └── render.sh

このリポジトリは、非構造化リポジトリです。これにより、構成ファイルを希望する方法で柔軟に編成できます。これは Kustomize を使用している場合に特に有用です。

このリポジトリには、異なる 3 つのテナント用に 3 つの Namespace(tenant-atenant-btenant-c)があります。各 Namespace ディレクトリには、Role、RoleBinding、NetworkPolicy の構成ファイルが入っています。configsync- src ディレクトリには、kustomize 形式の構成が入っています。configsync-src ディレクトリには、kustomize 形式の構成が入っています。1 つのベースと 3 つのオーバーレイ tenant-atenant-btenant-c があります。

目標

  • Kustomize オーバーレイを更新する。

  • Config Sync で使用できるクラスタを作成する。

  • Git リポジトリのポリシーをクラスタに同期する。

  • クラスタがリポジトリ内の構成ファイルと同期することを確認する。

料金

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

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

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

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

始める前に

このチュートリアルを始めるにあたり、次の作業を行います。

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

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

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

  3. GitHub アカウントを作成するか、アカウントへのアクセス権を取得します。
  4. 次のコマンドを実行して Kustomize をインストールします。

    gcloud components install kustomize
    

また、Git と Kustomize にある程度習熟することも役に立ちます。

Kustomize ファイルの更新

以降のセクションでは、リポジトリ内の Kustomize ファイルを更新して、tenant-a に適用されるポリシーをアップデートします。

環境を準備する

環境を準備するには、次の手順を行います。

  1. リポジトリをフォークします。

    1. GitHub の Anthos Config Management samples ディレクトリ リポジトリに移動します。
    2. [Fork] をクリックします。
  2. フォークされたリポジトリのクローンを作成します。

    git clone https://github.com/GITHUB_USERNAME/anthos-config-management-samples
    

    GITHUB_USERNAME は GitHub ユーザー名で置き換えます。

  3. このチュートリアルで使用するサンプルが格納されているディレクトリに移動します。

    cd anthos-config-management-samples/namespace-specific-policy
    

オーバーレイを更新する

このセクションでは、オーバーレイを更新します。オーバーレイは、他の Kustomize ファイルに依存する Kustomize ファイルです。

次の手順では、オーバーレイ acm-samples/namespace-specific-policy/configsync-src/tenant-a を更新して tenant-a に新しいロールを付与する方法を示します。更新する構成は 1 つだけであることから、更新する必要があるオーバーレイも 1 つになります。

この新しいロールを tenant-a に付与するには、次の手順を行います。

  1. GitHub の次のページに移動して、新しいファイルを作成します。

    github.com/GITHUB_USERNAME/anthos-config-management-samples/new/main/namespace-specific-policy/configsync-src/tenant-a
    
  2. another-role.yaml ファイルに名前を付けます。

  3. [新しいファイルの編集] ウィンドウで、新しいロール用に次の YAML マニフェストを貼り付けます。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: pod-reader
    rules:
    - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "watch", "list"]
    
  4. [Commit new file] をクリックします。

    これで、新しいロールの構成を kustomization.yaml ファイルに追加できます。

  5. /namespace-specific-policy/configsync-src/tenant-a フォルダで kustomization.yaml を開いて、編集アイコン(鉛筆のアイコン)をクリックします。

  6. kustomization.yaml のリソース セクションに、- another-role.yaml を追加します。

    namespace: tenant-a
    
    resources:
    - ../base
    - another-role.yaml
    # The rest of the file is omitted
    
  7. [Commit changes] をクリックします。

  8. 更新後、render.sh スクリプトを実行して、各 Namespace の Kustomize 出力を再ビルドします。

    ./scripts/render.sh
    
  9. 更新を commit して push します。

    git add .
    git commit -m 'update configuration'
    git push
    

GKE クラスタの作成と登録

このセクションでは、Config Sync で使用できるクラスタを作成して構成します。

クラスタの作成

Console

Google Cloud Console でゾーンクラスタを作成するには、次の操作を行います。

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine に移動

  2. [ 作成] をクリックします。

  3. [Standard] セクションで [構成] をクリックします。

  4. [クラスタの基本] セクションで、次の操作を行います。

    1. クラスタの [名前] に、「mt-cluster」を入力します。
    2. [ゾーン] プルダウン リストで、[us-central1-c] を選択します。
    3. 他のフィールドは、すべて推奨されたデフォルトのままにしておきます。
  5. 左側のメニューで [default-pool] をクリックし、表示されたプルダウン リストで [ノード] をクリックします。

  6. [ノード] セクションで、次の操作を行います。

    1. [マシンタイプ] プルダウン リストで、[e2-standard-4] を選択します。
    2. 他のすべてのフィールドはデフォルト値のままにします。
  7. 左側のメニューで [セキュリティ] を選択します。

  8. [セキュリティ] セクションで、[Workload Identity を有効にする] チェックボックスをオンにします。

  9. [作成] をクリックします。クラスタの作成には、数分かかる場合があります。

gcloud

gcloud コマンドライン ツールを使用してクラスタを作成するには、次の操作を行います。

gcloud container clusters create mt-cluster \
    --project PROJECT_ID \
    --zone us-central1-c \
    --release-channel regular \
    --machine-type "e2-standard-4" \
    --workload-pool=PROJECT_ID.svc.id.goog

PROJECT_ID を実際のプロジェクト ID に置き換えます。

クラスタの認証情報を取得する

クラスタの作成が完了したら、そのクラスタとやり取りするために必要な認証情報を取得します。

gcloud container clusters get-credentials mt-cluster --zone us-central1-c

自身に管理者権限を付与する

クラスタを作成したら、Config Sync に必要な GKE Hub 管理者のロールを自身に付与します。

Console

Google Cloud Console で管理者権限を付与するには、次の操作を行います。

  1. Cloud Console で [IAM] ページに移動します。

    IAM ページに移動

  2. [追加] をクリックします。

  3. [新しいメンバー] に、メールアドレスを入力します。個人、サービス アカウント、Google グループをメンバーとして追加できます。

  4. [ロールを選択] プルダウン リストで、[GKE Hub 管理者] を検索して選択します。

  5. [保存] をクリックします。

gcloud

gcloud コマンドライン ツールで管理者権限を付与するには、次の操作を行います。

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.admin

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

  • PROJECT_ID: プロジェクト ID
  • MEMBER: メンバーの識別子。通常、member-type:id の形式(user:my-user@example.com など)で指定します。member に使用できる値の一覧については、ポリシー バインディングのリファレンスをご覧ください。

クラスタの登録

クラスタを作成すると、クラスタをフリートに登録できます。

Console

Google Cloud Console でクラスタを登録するには、次の操作を行います。

  1. Google Cloud Console で、[Anthos クラスタ] ページに移動します。

    [Anthos クラスタ] ページに移動

  2. [既存のクラスタを登録] をクリックします。

  3. [mt-cluster] の横にある [登録] をクリックします。このクラスタがリストに表示されない場合は、クラスタが作成されていることを確認してください。

    出力例:

    Cluster mt-cluster registered successfully as mt-cluster in project PROJECT_NAME.
    

gcloud

gcloud コマンドライン ツールを使用してクラスタを登録するには、次の操作を行います。

gcloud beta container hub memberships register MEMBERSHIP_NAME \
 --gke-cluster=us-central1-c/mt-cluster \
 --enable-workload-identity

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

  • MEMBERSHIP_NAME: フリートに登録されているクラスタを一意に識別するために選択したメンバーシップ名。

Config Sync の構成

このセクションでは、Config Sync を namespace-specific-policy/ ディレクトリのポリシーと同期するように構成します。

Config Sync を構成するには、次の手順を行います。

Console

Google Cloud Console で Config Sync を構成するには、次の操作を行います。

  1. Cloud Console で Anthos Config Management のページに移動します。

    Anthos Config Management に移動

  2. [mt-cluster] を選択して [構成] をクリックします。

  3. [ACM の Git リポジトリ認証] セクションで、[なし] を選択して、[続行] をクリックします。

  4. [クラスタ用の ACM 設定] セクションで、次の操作を行います。

    1. [バージョン] フィールドで、バージョン 1.7 以降を選択します。
    2. [Config Sync を有効にする] チェックボックスをオンにして、次のフィールドに入力します。
      1. [URL] フィールドに https://github.com/GITHUB_USERNAME/anthos-config-management-samples を追加します。
      2. [ブランチ] フィールドに main を追加します。
      3. [タグ / commit] に HEAD を追加します。
      4. [ポリシーのディレクトリ] フィールドに、namespace-specific-policy/configsync を追加します。
      5. [同期の待機時間] フィールドは、空白のままにします。
      6. [Git プロキシ] フィールドは、空白のままにします。
      7. [ソース形式] プルダウン リストで、[unstructured] を選択します。
  5. [完了] をクリックします。[Anthos Config Management] ページに戻ります。数分後、構成したクラスタの横のステータス列に Synced と表示されます。

gcloud

gcloud コマンドライン ツールを使用して Config Sync を構成するには、次の操作を行います。

  1. apply-spec.yaml という名前のファイルを作成して、次の YAML ファイルをコピーします。

    # apply-spec.yaml
    
    applySpecVersion: 1
    spec:
      configSync:
        # Set to true to install and enable Config Sync
        enabled: true
        sourceFormat: unstructured
        syncRepo: https://github.com/GITHUB_USERNAME/anthos-config-management-samples
        syncBranch: main
        secretType: none
        policyDir: namespace-specific-policy/configsync
    

    GITHUB_USERNAME は GitHub ユーザー名で置き換えます。

  2. apply-spec.yaml ファイルを適用します。

     gcloud beta container hub config-management apply \
         --membership=MEMBERSHIP_NAME \
         --config=CONFIG_YAML_PATH \
         --project=PROJECT_ID
    

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

    • MEMBERSHIP_NAME: クラスタの登録時に選択したメンバーシップ名。名前は gcloud container hub memberships list で確認できます。
    • CONFIG_YAML_PATH: apply-spec.yaml ファイルのパス
    • PROJECT_ID: プロジェクト ID

Namespace 固有のポリシーが同期されていることを確認する

Config Sync のインストールが済むと、nomos status コマンドを使用して、Namespace 固有のポリシーがクラスタに同期されていることを確認できます。

nomos status

出力は、次の例のようになります。

gke_PROJECT_ID_us-central1-c_mt-cluster
  --------------------
  <root>   https:/github.com/GITHUB_USERNAME/anthos-config-management-samples/namespace-specific-policy/configsync@main
  SYNCED   bf8655aa
  Managed resources:
     NAMESPACE   NAME                                                             STATUS
                 namespace/foo                                                    Current
                 namespace/istio-system                                           Current
                 namespace/tenant-a                                               Current
                 namespace/tenant-b                                               Current
                 namespace/tenant-c                                               Current
     tenant-a    networkpolicy.networking.k8s.io/deny-all                         Current
     tenant-a    role.rbac.authorization.k8s.io/tenant-admin                      Current
     tenant-a    rolebinding.rbac.authorization.k8s.io/tenant-admin-rolebinding   Current
     tenant-b    networkpolicy.networking.k8s.io/deny-all                         Current
     tenant-b    role.rbac.authorization.k8s.io/tenant-admin                      Current
     tenant-b    rolebinding.rbac.authorization.k8s.io/tenant-admin-rolebinding   Current
     tenant-c    networkpolicy.networking.k8s.io/deny-all                         Current
     tenant-c    role.rbac.authorization.k8s.io/tenant-admin                      Current
     tenant-c    rolebinding.rbac.authorization.k8s.io/tenant-admin-rolebinding   Current

次に、リソースがクラスタに存在することを確認します。tenant-a のリソースの確認方法を、次の例に示します。

  1. tenant-a の RoleBinding が存在することを確認します。

    kubectl get RoleBinding/tenant-admin-rolebinding -n tenant-a
    

    出力例:

    NAME                       ROLE                AGE
    tenant-admin-rolebinding   Role/tenant-admin   23h
    
  2. tenant-a の Role が存在することを確認します。

    kubectl get Role/tenant-admin -n tenant-a
    

    出力例:

    NAME           CREATED AT
    tenant-admin   2021-05-24T21:49:06Z
    
  3. tenant-a の NetworkPolicy が存在することを確認します。

    kubectl get NetworkPolicy/deny-all -n tenant-a
    

    出力例:

    NAME       POD-SELECTOR   AGE
    deny-all   <none>         23h
    

これらのコマンドを使用することで、マルチテナント クラスタのベスト プラクティスに従って、各 Namespace に一連の独自ポリシーが設定されていることを確認できます。

クリーンアップ

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

プロジェクトの削除

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

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

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

ディレクトリの削除

テナントの Namespace とポリシーをクリーンアップするには、それらの構成を含むディレクトリを Git リポジトリから削除することをおすすめします。

rm -r acm-samples/namespace-specific-policy/configsync/tenant-*/*
git add .
git commit -m 'clean up'
git push

ルート リポジトリからの最後の commit が同期されると、tenant-atenant-btenant-c の 3 つの Namespace がクラスタから削除されます。

次のステップ