【GCP Anthos】 Regionに跨って冗長化したKubernetsのマルチクラスタをロードバランシングする

Anthosとは？

アプリケーションを、OSSをベースにモナタイゼーションするための統括的な機能を提供するプラットフォーム。
- モナタイゼーションとは？
  - マイクロサービス化
  - インフラとアプリケーションの疎結合化
  - サーバレス
  - 自動化
  - なるべくManagedへ
Anthosが提供する機能は現時点では下記の資料が一番わかり易い
- https://inthecloud.withgoogle.com/anthos-day-2001/Google_Cloud_Anthos_Day_200130_Session2.pdf

本記事の目的

本記事ではマルチクラスタを構築し、Anthosの機能を使ってクラスタにまたがって負荷分散することができるかに焦点をあてる。 GKE HubのIngress For Anthosという機能を用い実現する。本当はマルチクラウドなクラスタで負荷分散させたかったが、GKE以外のクラスタはまだサポートされていないようだ。

Anthosへのクラスタ登録とクラスタモニタリングの仕組み

Anthosはクラスタ管理のため、各クラスタ内にGKE Connector Agentをデプロイする。このAgentがAnthosに情報を集約し、Anthosのコントロールプレーンからの命令を各クラスタで実行することになる。 AgentがAnthosの命令を実行する流れ引用: https://cloud.google.com/anthos/multicluster-management/connect/security-features

Ingress For Anthosのアーキテクチャ

Anthosによるクラスタ間のロードバランシングは、Ingress For Anthosという仕組みを用いて実現する。これは下記イメージのようなアーキテクチャになっている。

アーキテクチャ引用: https://cloud.google.com/kubernetes-engine/docs/concepts/ingress-for-anthos

登場人物について

Config Cluster
- Ingress For Anthosの設定リソースを配置するクラスタ
- アプリケーション用のクラスタと一緒にしてもいいが、Config Clusterの障害がサービス影響を出さないためにも分離しておいたほうが良い
Anthos Member Cluster
- Anthosが管理するクラスタ郡のメンバー
Anthos Ingress Controller
- クラスタの外でGoogleマネージドで稼働しているグローバルなIngress Controller
- Config Clusterを監視し、リソース作成、変更のタイミングでクラスタ間ロードバランシングの設定を行う
MultiClusterService(MCS)
- 各クラスタに作成されるServiceのテンプレートであり、MultiClusterIngressから参照するServiceの論理的な単位となる
  - MultiClusterIngressはこのMultiClusterServiceを指定してルーティングする
- このリソースが作成されると、各クラスタにテンプレートから生成されたServiceが作成される
MultiClusterIngress(MCI)
- このリソースが作成されると、GCLBとZone NEG(MCSによって各クラスタに作成されたServiceに紐づく)が作られ、GCLBのバックエンドにはNEGが紐付けられる

動作イメージ

MultiClusterIngressがConfig Clusterに作成されたタイミングで、Anthos Ingres Controllerが単一のGCLBを作成し、それぞれのクラスタに紐づくZone NEGをバックエンドとしてぶら下げる
- このNEGは、MultiClusterServiceを元に各クラスタに作成されたServiceにルーティングされる
- 一つのNEG(クラスタ)へのアクセスが正常でない場合、すぐに別のNEGへfallbackされる

Config Clusterの可用性について

当然疑問に上がってくるのは、Config Clusterの可用性はどう担保するのか？というところ。ちなみにConfig Clusterが死ぬとMultiClusterIngressとMultiCluserServiceの設定変更ができなくなる。つまりすでに適用した設定でのロードバランシングには影響しないが、なるべくRegionalなクラスタで運用するようなどしたほうが良い。ただ、個人的にはサービスダウンに直結するわけではない & MultiClusterServiceとMultiClusterIngressを頻繁にメンテすることはあんまりなさそうなのでそこまでガチな可用性はなくても良さそうに感じている。 (ここにマルチクラスタで冗長化とかあんまやりたくはない...)

実際に動かしてみる

セットアップ

下記リンクの内容を済ませておく https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-for-anthos-setup

GKEクラスタをAnthosのクラスタメンバーに登録

あらかじめフィンランドと東京にGKEクラスタ、Config用のクラスタを作成しておく
メンバー用クラスタ(東京)

gcloud container hub memberships register  gke-anthos-asia    \
   --project=[project_name] \
   --gke-cluster=asia-northeast1-a/gke-anthos-asia \
   --service-account-key-file=./service-account.json

メンバー用クラスタ(フィンランド)

gcloud container hub memberships register gke-anthos-eu   \
   --project=[project_name] \
   --gke-cluster=europe-north1-a/gke-anthos-eu \
   --service-account-key-file=./service-account.json

ConfigクラスタをAnthosに設定

gcloud alpha container hub ingress enable \
  --config-membership=projects/[project_name]/locations/global/memberships/gke-anthos-config

アプリケーションのデプロイ

このドキュメントのリンクのセクションに従ってzoneprinterをデプロイする https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-for-anthos#deployment_tutorial

結果

クラスタがAnthosのメンバーとして認識された様子(本記事の手順では割愛しているが、EKSも検証のため入れてみた)
ロードバランサーのバックエンドに自動的に作成されたNEGが紐付いている
中身はクラスタのMultiClusterServiceによって作成されたHeadlessServiceから取得されたPodのIPに紐付いている
試しにcurlしてみると、GCLBがAnyCastで最寄りのクラスタ(ネットワーク的に)にルーティングしてくれるため、常に東京クラスタの結果が帰ってくる

❯❯❯ curl 34.107.232.154/ping
{"Hostname":"34.107.232.154","Version":"1.0","GCPZone":"asia-northeast1-a","Backend":"zone-ingress-5f6ff94966-2phdz"}%

試しにAsiaクラスタを殺してみる

deploymentを殺し、Podが存在しないようにする

❯❯❯ kubectl delete -f deployment.yaml
deployment.apps "zone-ingress" deleted

curlしてみるとフィンランドにルーティングされているのが分かる

❯❯❯ curl 34.107.232.154/ping
{"Hostname":"34.107.232.154","Version":"1.0","GCPZone":"europe-north1-a","Backend":"zone-ingress-5f6ff94966-7hlt7"}%

まとめ

GKEのクラスタであればかんたんにロードバランシングできるので、クラスタ自体のアップデートをしたいが、ダウンタイムを許容したくないときやRegion障害などに活用できそうだということがわかった。 EKSなどのサポートも進めばよりいっそう便利なので対応を待望しています。

参考

Ingress For Anthosの仕組み https://cloud.google.com/kubernetes-engine/docs/concepts/ingress-for-anthos

Enjoy Architecting

Twitter: @taisho6339