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

このチュートリアルでは、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-a、tenant-b、tenant-c）があります。各 Namespace ディレクトリには、Role、RoleBinding、NetworkPolicy の構成ファイルが入っています。configsync- src ディレクトリには、kustomize 形式の構成が入っています。configsync-src ディレクトリには、kustomize 形式の構成が入っています。1 つのベースと 3 つのオーバーレイ tenant-a、tenant-b、tenant-c があります。

目標

Kustomize オーバーレイを更新する。
Config Sync で使用できるクラスタを作成する。
Git リポジトリのポリシーをクラスタに同期する。
クラスタがリポジトリ内の構成ファイルと同期することを確認する。

料金

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

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

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

始める前に

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

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

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

プロジェクトセレクタに移動
Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。
GitHub アカウントを作成するか、アカウントへのアクセス権を取得します。
次のコマンドを実行して Kustomize をインストールします。
```
gcloud components install kustomize
```

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

Kustomize ファイルを更新する

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

環境を準備する

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

リポジトリをフォークします。
1. GitHub の Anthos Config Management samples ディレクトリリポジトリに移動します。
2. [Fork] をクリックします。
フォークされたリポジトリのクローンを作成します。
```
git clone https://github.com/GITHUB_USERNAME/anthos-config-management-samples
```
GITHUB_USERNAME は GitHub ユーザー名で置き換えます。
このチュートリアルで使用するサンプルが格納されているディレクトリに移動します。
```
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 に付与するには、次の手順を行います。

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

github.com/GITHUB_USERNAME/anthos-config-management-samples/new/main/namespace-specific-policy/configsync-src/tenant-a

another-role.yaml ファイルに名前を付けます。

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

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

[Commit new file] をクリックします。

これで、新しいロールの構成を kustomization.yaml ファイルに追加できます。
/namespace-specific-policy/configsync-src/tenant-a フォルダで kustomization.yaml を開いて、編集アイコン（鉛筆のアイコン）をクリックします。

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

namespace: tenant-a

resources:
- ../base
- another-role.yaml
# The rest of the file is omitted

[Commit changes] をクリックします。
更新後、render.sh スクリプトを実行して、各 Namespace の Kustomize 出力を再ビルドします。
```
./scripts/render.sh
```

更新を commit して push します。

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

GKE クラスタの作成と登録

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

クラスタの作成

コンソール

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

コンソールで Google Kubernetes Engine のメニューに移動します。

Google Kubernetes Engine に移動
[ 作成] をクリックします。
[Standard] セクションで [構成] をクリックします。
[クラスタの基本] セクションで、次の操作を行います。
1. クラスタの [名前] に、「mt-cluster」を入力します。
2. [ゾーン] プルダウンリストで、[us-central1-c] を選択します。
3. 他のフィールドは、すべて推奨されたデフォルトのままにしておきます。
左側のメニューで [default-pool] をクリックし、表示されたプルダウンリストで [ノード] をクリックします。
[ノード] セクションで、次の操作を行います。
1. [マシンタイプ] プルダウンリストで、[e2-standard-4] を選択します。
2. 他のすべてのフィールドはデフォルト値のままにします。
左側のメニューで [セキュリティ] を選択します。
[セキュリティ] セクションで、[Workload Identity を有効にする] チェックボックスをオンにします。
[作成] をクリックします。クラスタの作成には、数分かかる場合があります。

gcloud

Google Cloud CLI を使用してクラスタを作成するには、次の操作を行います。

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 管理者のロールを自身に付与します。

コンソール

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

コンソールで [IAM] ページに移動します。

[IAM] ページに移動
[追加] をクリックします。
[新しいメンバー] に、メールアドレスを入力します。個人、サービスアカウント、Google グループをメンバーとして追加できます。
[ロールを選択] プルダウンリストで、[GKE Hub 管理者] を検索して選択します。
[保存] をクリックします。

gcloud

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

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 に使用できる値の一覧については、ポリシーバインディングのリファレンスをご覧ください。

クラスタの登録

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

コンソール

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

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

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

出力例:
```
Cluster mt-cluster registered successfully as mt-cluster in project PROJECT_NAME.
```

gcloud

Google Cloud CLI を使用してクラスタを登録するには、次の操作を行います。

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 を構成するには、次の手順を行います。

コンソール

Google Cloud コンソールで Config Sync を構成するには、次の操作を行います。

コンソールで Anthos の [構成管理] ページに移動します。

Anthos の [構成管理] に移動
[mt-cluster] を選択して [構成] をクリックします。
[ACM の Git リポジトリ認証] セクションで、[なし] を選択して、[続行] をクリックします。
[クラスタ用の 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] を選択します。
[完了] をクリックします。[Anthos Config Management] ページに戻ります。数分後、構成したクラスタの横のステータス列に Synced と表示されます。

gcloud

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

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 ユーザー名で置き換えます。

apply-spec.yaml ファイルを適用します。
```
 gcloud beta container hub config-management apply \
     --membership=MEMBERSHIP_NAME \
     --config=CONFIG_YAML_PATH \
     --project=PROJECT_ID
```
次のように置き換えます。
- MEMBERSHIP_NAME: クラスタの登録時に選択したメンバーシップ名。名前は gcloud container fleet 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 のリソースの確認方法を、次の例に示します。

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

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

出力例:

NAME                       ROLE                AGE
tenant-admin-rolebinding   Role/tenant-admin   23h

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

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

出力例:

NAME           CREATED AT
tenant-admin   2021-05-24T21:49:06Z

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

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

出力例:

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

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

クリーンアップ

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

プロジェクトの削除

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

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

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

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

ディレクトリの削除

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

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

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

次のステップ

エンタープライズマルチテナンシーのベストプラクティスを確認する。
Google Cloud に関するリファレンスアーキテクチャ、図、チュートリアル、ベストプラクティスを確認する。Cloud Architecture Center を確認します。

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

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

目標

料金

始める前に

Kustomize ファイルを更新する

環境を準備する

オーバーレイを更新する

GKE クラスタの作成と登録

クラスタの作成

コンソール

gcloud

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

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

コンソール

gcloud

クラスタの登録

コンソール

gcloud

Config Sync を構成する

コンソール

gcloud

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

クリーンアップ

プロジェクトの削除

ディレクトリの削除

次のステップ

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