もっとGCPが使いやすくなる!? GKE Config Connectorを試してみた!

Yutty Kawahara
google-cloud-jp
Published in
11 min readFeb 5, 2020

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で複数のプロジェクトを管理する場合

まとめ

Config Connectorを利用して、簡単にGCPリソースを構成する事ができました。1システム : 1プロジェクトで運用されていた場合、コードと同じように構成も管理でき、他プロジェクトにも再利用しやすそうなので便利な機能でした。

欲を言えば、個人的には「そもそも GKE にアドオンするんじゃなくて、サーバーレスで Resouce Deployment したい」「プロジェクトが増えたときに、SAの管理が複雑になりそう」とも思いましたが、それでも GCP の構成をYAMLで管理できるのは大きなメリットじゃないでしょうか?現時点では、Config Connector 自体に料金はかかりません。(Config Connector を通じて作成したリソースに応じて課金が発生します)

ぜひ皆様も使ってみてください!

--

--

Yutty Kawahara
google-cloud-jp

Customer Engineer in Google Cloud. All views and opinions are my own.