もっとGCPが使いやすくなる!? GKE Config Connectorを試してみた!
TL;DR
先日、GAとなったConfig Connector を使うと、Kubernetes のリソースのようにGCPのリソースを作成・管理できます。
はじめに
昨今、クラウドを利用することが増えてきたエンジニアの方々は、様々な構成管理システム、API、ツールなどを組み合わせてインフラを管理していると思います。これらの要素は、どんどん複雑化し把握するのも困難になってしまいがちです。Config Connectorは、Kubernetesを介して、Google Cloud Platform 上でリソースの構成をシンプルにしてくれます。
Config Connectorとは?
Config Connector とは、Kubernetes を介して Google Cloud のリソースを管理出来るようにするための、Google Kubernetes Engine(GKE)のアドオンです。Agones のように、CRD(CustomResourceDefinition)を利用してます。ここによるとConfig Connectorを利用すると、以下のことがKubernetes上で出来るようになります。
- RBAC アクセスコントロール
- イベントの可視化
- 構成ソースを単一化し、目的の状態を管理する複雑性を減らす
- 依存関係を疎結合にし、一貫性を保つ
難しいことを書いてますが、要するに k8s のマニフェストを使って、 GCP 上のリソースを管理する事ができるわけです。k8s を触ったことのある方、かつGCPを触ったことのある方は以下のサンプルを見ると、ビビッと来るのではないでしょうか?!
以下は、Spanner のインスタンスを構成するためのサンプルになります。
apiVersion: spanner.cnrm.cloud.google.com/v1beta1
kind: SpannerInstance
metadata:
labels:
label-one: "value-one"
name: spannerinstance-sample
spec:
config: regional-us-west1
displayName: Spanner Instance Sample
numNodes: 2
そうです!このように、YAMLに構成を記述し、k8sにデプロイするとGCP上にリソースが作成されます。
Config Connector で利用できる対象のリソースはこちらを参照ください。https://cloud.google.com/config-connector/docs/reference/resources?hl=en#accesscontextmanageraccesslevel
またサンプルのマニフェストはこちらにあります。https://github.com/GoogleCloudPlatform/k8s-config-connector
Config Connector のセットアップ
Config Connectorを利用するには、既存のクラスターにインストールする必要があります。インストールには3つの方法があり、
- GCP の Identity
- GKE の Workload Identity
- ネームスペースモード(複数のGCPのIdentityを利用する場合には、こちら)
となります。
「GCPの Identity」を利用する場合はいわゆるService Accountを利用するのですが、Service Account の鍵をSecret リソースとしてクラスターに保持しているので、個人的には、「GKE の Workload Identity」を利用することをおすすめしたいです。GCP の Identityを使うのは、GKE以外の、Kubernetesクラスタを利用する場合でしょうか。
Workload Identity については、こちらの記事を参照ください。
Config Connector のインストール
さっそく、ドキュメントに従ってインストールしてみましょう。以下ではWorkload Identity でConfig Connector を使う手順です。
前提条件
- Workload Identityを有効にしたGKEクラスタが存在している
- gcloud CLIのセットアップが完了している
ちなみに Kubernetes のバージョンは 1.13.11 です。
1. Identity の作成( link )
まずは GCP のService Accountを作成し、構成を管理するGCP プロジェクトのオーナー権限を付与します。
$ gcloud iam service-accounts create cnrm-system
$ gcloud projects add-iam-policy-binding [PROJECT_ID] --member="serviceAccount:cnrm-system@[PROJECT_ID].iam.gserviceaccount.com" --role="roles/owner"
GCP のサービスアカウントとKubernetes のサービスアカウントを紐付けます。
$ gcloud iam service-accounts add-iam-policy-binding cnrm-system@[PROJECT_ID].iam.gserviceaccount.com --member="serviceAccount:[PROJECT_ID].svc.id.goog[cnrm-system/cnrm-controller-manager]" --role="roles/iam.workloadIdentityUser"
2. Config Connector アドオンのデプロイ( link )
GCS からインストール用の YAML を取得し、GKE にデプロイします。
$ gsutil cp gs://cnrm/latest/release-bundle.tar.gz release-bundle.tar.gz
$ tar zxvf release-bundle.tar.gz
$ sed -i 's/${PROJECT_ID?}/[PROJECT_ID]/' install-bundle-workload-identity/0-cnrm-system.yaml
$ kubectl apply -f install-bundle-workload-identity/
3. 起動確認( link )
こちらのコマンドで正しく起動しているかを確認します。
$ kubectl wait -n cnrm-system \
--for=condition=Initialized pod \
cnrm-controller-manager-0
以下のように返ってきたら、Config Connector の起動が完了です。
pod/cnrm-controller-manager-0 condition met
実行されている Deployment をみてみると、cnrm-resource-stats-recorder、cnrm-webhook-managerというものが存在します。また StatefulSet で cnrm-controller-manager というものがいます。
今回、それぞれが何をやっているかまでは確認できておりません、すみません!
$ kubectl get Deployments
NAME READY UP-TO-DATE AVAILABLE AGE
cnrm-resource-stats-recorder 1/1 1 1 3d14h
cnrm-webhook-manager 1/1 1 1 3d14h$ kubectl get StatefulSet
NAME READY AGE
cnrm-controller-manager 1/1 3d14h
Spanner のインスタンスを作成してみる
さっそく上で紹介したサンプルの YAML を適用して、リソースを作成してみます。
apiVersion: spanner.cnrm.cloud.google.com/v1beta1
kind: SpannerInstance
metadata:
labels:
label-one: "value-one"
name: spannerinstance-sample
spec:
config: regional-us-west1
displayName: Spanner Instance Sample
numNodes: 2
こちらを。Config Connector をインストールした k8s にデプロイしてみます。
$ kubectl apply -n spanner-space -f spanner.yaml
spannerinstance.spanner.cnrm.cloud.google.com/spannerinstance-sample created
Config Connector では各リソースごとに CustomResourceDefinitions(CRDが用意されており、Spanner のインスタンスは、SpannerInstance リソースとして管理されます。
$ kubectl get SpannerInstance -n spanner-space
NAME AGE
spannerinstance-sample 4m
実際に gcloud コマンドで Spannerのインスタンスを確認してみると、
$ gcloud spanner instances list
NAME DISPLAY_NAME CONFIG NODE_COUNT STATE
spannerinstance-sample Spanner Instance Sample regional-us-west1 2 READY
と、YAML に定義したように Node が2つで起動しています。もちろん、YAMLを変更して Node を 5 に変更すると Node 数も変更されます。
$ gcloud spanner instances list
NAME DISPLAY_NAME CONFIG NODE_COUNT STATE
spannerinstance-sample Spanner Instance Sample regional-us-west1 5 READY
また、上記の例のように、あるName Space(今回は、”spanner-space” )にリソースを作成した場合、その Name Space が削除されると、紐づくリソースも削除されます。
組織やフォルダ、複数のプロジェクトにまたがって使う場合
Config Connectorを使っていくと、組織、フォルダーといったリソースも管理したくなるかも知れません。その場合は Config Connector が利用するService Accountに、権限を付与することで、リソースの操作が可能です。
複数のプロジェクトで利用したい場合は、プロジェクトごとに Name Spaceを作成し、KASとバインドするServiceAccountをプロジェクトごとに分けることで実現できます(試してないけど)。
まとめ
Config Connectorを利用して、簡単にGCPリソースを構成する事ができました。1システム : 1プロジェクトで運用されていた場合、コードと同じように構成も管理でき、他プロジェクトにも再利用しやすそうなので便利な機能でした。
欲を言えば、個人的には「そもそも GKE にアドオンするんじゃなくて、サーバーレスで Resouce Deployment したい」「プロジェクトが増えたときに、SAの管理が複雑になりそう」とも思いましたが、それでも GCP の構成をYAMLで管理できるのは大きなメリットじゃないでしょうか?現時点では、Config Connector 自体に料金はかかりません。(Config Connector を通じて作成したリソースに応じて課金が発生します)
ぜひ皆様も使ってみてください!