BT

InfoQ ホームページ ニュース Jetstackが複数のKubernetesクラスタにグローバルロードバランサをセットアップした方法

Jetstackが複数のKubernetesクラスタにグローバルロードバランサをセットアップした方法

ブックマーク

原文(投稿日:2020/02/29)へのリンク

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などを使って — 実現している企業もある。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT

あなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。

Eメールを変更すると確認のメールが配信されます。

会社名:
役職:
組織規模:
国:
都道府県:
新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。