Jetstackのエンジニアリングチームは、複数のGoogle Kubernetes Engine(GKE)クラスタを対象として、Google独自のコンテナネイティブなロードバランシングと、DDoS防御にGoogle Cloud Armorを使用した、グローバルロードバランサのセットアップについて講演した。
Jetstackのあるユーザが運用していた既存のセットアップは、複数のKubernetesクラスタと、複数のロードバランサIPへのDNSベースのルーティングによって構成されたものだったが、Cloud Armor DDoSプロテクションの導入と、"トラフィックの可視性とネットワークパフォーマンス向上"のためにコンテナネイティブなロード・バランシングを使用したいと考えていた。Jetstackエンジニアリングチームは複数のマイグレーションフェーズを通じて、これらの機能と、複数のKubernetesクラスタバックエンドを単一GLBで結びつける独自の方法を導入したのだ。
Kubernetesには仕様上、Ingressを使わずに、サービスレベルで"ロードバランシング"を行う方法が3つ — ClusterIP、NodePort、LoadBalancer — ある。Jetstackの件のユーザは"LoadBalancing"サービスタイプを使用していた。これは、基盤にあるクラウドプラットフォームをベースとした独自LBを実装する方法だ。GKEの場合、それはネットワークLB(NLB)として実装される。ただしKubernetesクラスタでは、インターネットからのトラフィックを受け入れるために、GKEのグローバルLB(GLB)によって実装されたIngressを用意するのが一般的だ。そのユーザのそれまでのセットアップでは、AWS Route53で地理的なロケーションを基準としたIPアドレスのルーティングを行っていた。Route 53は、DNSクエリの発行された場所によって異なるIPアドレスを返すことができる。
GoogleのNLBはCloud Armor DDoSプロテクションサービスをサポートしない。ただしCloud Armorのコンフィギュレーションは、レイヤ3-7のネットワークルールをサポートしている。従って、L7 LB — 例えばGlobal Load Balancer(GLB) — への切り替えが必要だった。GKEにIngressリソースを生成すれば、自動的にこれを生成してくれる。L7 GLBはURLルーティングに柔軟性があり、ロードバランサ自体にTLSターミネーションを備えると同時に、トラフィックサービスポートを80、8080、443に制限する。後者の結果として、それまで他のポートを使用していたアプリケーションはいくつかの変更を行うことになった。このフェーズの完了時にはまだ複数のL7ロードバランサが存在していて、DNSはそれぞれのIPアドレスをポイントする状態だった。
GKEには"コンテナネイティブ・ロード・バランシング"と呼ばれる機能があり、Podがロードバランサから直接トラフィックを受け取ることができる。これはKubernetesの仕様ではなく、GKEでの最適化であるため、他ベンダのマネージドKubernetesサービスでは使用できない。これがなければ、LBからPodへのトラフィックは、GKEのネットワーク内部で遠回りなルートを取ることになる。この余分なネットワークホップは、レイテンシの増加にも影響する。コンテナネイティブなロードバランシングには、トラフィックをサービスするバックエンドPodのIPアドレスを含んだNetwork Endpoint Groups(NEGs) — Google独自の機能 — を生成する必要がある。これはマイグレーションの第2フェーズで行われた。
第3フェーズでのおもな変更は、リージョン毎に異なるロードバランサのIPアドレスをDNSから返すのではなく、単一のGLB IPアドレスを使用するようにしたことだ。Kubernetesには、単一のIngressの背後に複数のクラスタを置くようなメカニズムはない。これを実行しようとするGoogleのベータ版ツールがあるものの、いまだ開発の初期段階だ。複数のKubernetesクラスタをひとつのGLB(あるいはIngress LB)にまとめるのは、複数のKubernetesクラスタを同時に運用することとは違うので、その点に注意しなくてはならない。前者が単一のエンドポイント経由で、グローバルなトラフィックは独立したKubernetesクラスタにルートされるのに対して、後者では複数のKubernetesクラスタを単一のコントロールプレーンの下で使用することになる。前者の構成を他のクラウドで行うのは簡単ではない。Jetstackのチームは、TerraformのGoogleプロバイダをオートメーションに使用した上で、NEGリソースとGLBを別々に生成した上で、それらをアノテーションで結び付ける、という作業を行った。これについては、もっと容易に実現可能であると称する他のツールや、別の方法で — EnvoyコントロールプレーンやCluster Registoryなどを使って — 実現している企業もある。