このチュートリアルでは、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 Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
-
Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。
- GitHub アカウントを作成するか、アカウントへのアクセス権を取得します。
次のコマンドを実行して Kustomize をインストールします。
gcloud components install kustomize
また、Git と Kustomize にある程度習熟することも役に立ちます。
Kustomize ファイルを更新する
以降のセクションでは、リポジトリ内の Kustomize ファイルを更新して、tenant-a
に適用されるポリシーをアップデートします。
環境を準備する
環境を準備するには、次の手順を行います。
リポジトリをフォークします。
- GitHub の Anthos Config Management samples ディレクトリ リポジトリに移動します。
- [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 のメニューに移動します。
[add_box 作成] をクリックします。
[Standard] セクションで [構成] をクリックします。
[クラスタの基本] セクションで、次の操作を行います。
- クラスタの [名前] に、「
mt-cluster
」を入力します。 - [ゾーン] プルダウン リストで、[
us-central1-c
] を選択します。 - 他のフィールドは、すべて推奨されたデフォルトのままにしておきます。
- クラスタの [名前] に、「
左側のメニューで [default-pool] をクリックし、表示されたプルダウン リストで [ノード] をクリックします。
[ノード] セクションで、次の操作を行います。
- [マシンタイプ] プルダウン リストで、[e2-standard-4] を選択します。
- 他のすべてのフィールドはデフォルト値のままにします。
左側のメニューで [セキュリティ] を選択します。
[セキュリティ] セクションで、[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] ページに移動します。
[追加] をクリックします。
[新しいメンバー] に、メールアドレスを入力します。個人、サービス アカウント、Google グループをメンバーとして追加できます。
[ロールを選択] プルダウン リストで、[GKE Hub 管理者] を検索して選択します。
[保存] をクリックします。
gcloud
Google Cloud CLI で管理者権限を付与するには、次の操作を行います。
gcloud projects add-iam-policy-binding PROJECT_ID \
--member=MEMBER \
--role=roles/gkehub.admin
次のように置き換えます。
PROJECT_ID
: プロジェクト IDMEMBER
: メンバーの識別子。通常、member-type:id の形式(user:my-user@example.com
など)で指定します。member に使用できる値の一覧については、ポリシー バインディングのリファレンスをご覧ください。
クラスタの登録
クラスタを作成すると、クラスタをフリートに登録できます。
コンソール
Google Cloud Console でクラスタを登録するには、次の操作を行います。
Google Cloud Console で、[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 の [構成管理] ページに移動します。
[
mt-cluster
] を選択して [構成] をクリックします。[ACM の Git リポジトリ認証] セクションで、[なし] を選択して、[続行] をクリックします。
[クラスタ用の ACM 設定] セクションで、次の操作を行います。
- [バージョン] フィールドで、バージョン 1.7 以降を選択します。
- [Config Sync を有効にする] チェックボックスをオンにして、次のフィールドに入力します。
- [URL] フィールドに
https://github.com/GITHUB_USERNAME/anthos-config-management-samples
を追加します。 - [ブランチ] フィールドに
main
を追加します。 - [タグ / commit] に
HEAD
を追加します。 - [構成ディレクトリ] フィールドに、
namespace-specific-policy/configsync
を追加します。 - [同期の待機時間] フィールドは、空白のままにします。
- [Git プロキシ] フィールドは、空白のままにします。
- [ソース形式] プルダウン リストで、[unstructured] を選択します。
- [URL] フィールドに
[完了] をクリックします。[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 を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。
ディレクトリの削除
テナントの 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 を確認します。