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

Yutty Kawahara
Feb 5 · 11 min read

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 を通じて作成したリソースに応じて課金が発生します)

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

google-cloud-jp

Google Cloud Platform 製品などに関連するコミュニティが記載したテクニカル記事集。掲載された意見は著者のものであり、必ずしも Google のものを反映するものではありません。

Thanks to Kazuu Shinohara and Kozzy Hasebe

Yutty Kawahara

Written by

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

google-cloud-jp

Google Cloud Platform 製品などに関連するコミュニティが記載したテクニカル記事集。掲載された意見は著者のものであり、必ずしも Google のものを反映するものではありません。

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade