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

Yutty Kawahara

Published in

google-cloud-jp

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

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

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