GKE

GKE のベストプラクティス: Ingress と Service を使用した GKE アプリケーションの公開

2020年7月27日

Google Cloud Japan Team

※この投稿は米国時間 2020 年 7 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Kubernetes Engine（GKE）で実行するエンタープライズアプリケーションの設計において重要なことの一つは、アプリケーションがクライアントからどのように使用されるかを検討することです。たとえば、アプリケーションをクラスタ外に公開して、外部クライアントが他の内部クライアントと同じくらい簡単に使用できるようにする場合もあれば、世界中のパブリッククライアントからのアプリケーションへのトラフィックをルーティングする場合もあります。

どのようにすべきかは、さまざまな要因に左右されます。クライアントはインターネットからアクセスするか、それとも内部ネットワークからか。アプリケーションが使用するネットワークプロトコルは何か。アプリケーションは単一のリージョンやクラスタでホストされているか、それともグローバルにデプロイされているか。アプリケーションの公開に使用するソリューションを決定するには、いくつかの主要な領域でのアプリケーション要件を考慮する必要があります。これらの要件を個別に評価するのではなく、総合的に判断して、アプリケーションを公開するのに最も適したネットワーキングソリューションを決定します。

ここでは、GKE でアプリケーションを公開する際に考慮すべきさまざまな要因を順に見ていき、それらがアプリケーションの公開にどのように影響するかを説明し、それぞれの要件がどのネットワーキングソリューションにつながるかに焦点を当てます。ここでは、Deployment、Service、Ingress リソースといった Kubernetes の概念を理解していることを前提として、内部、外部、マルチクラスタなど、さまざまな公開方法を区別して解説します。

アプリケーションの公開を理解する

アプリケーションを外部クライアントに公開するには、次の 3 つの主要な要素が必要となります。これらが組み合わさることで、トラフィックをアプリケーションにルーティングできるようになります。

フロントエンド: ロードバランサのフロントエンドは、クライアントがアクセスしてトラフィックをロードバランサに送信できるスコープを定義します。トラフィックをリッスンするネットワークの場所であり、そうした場所としては、ネットワーク、ネットワーク内の特定のリージョンまたはサブネット、ネットワーク内の 1 つ以上の IP、ポート、特定のプロトコル、安全な接続を確立するために提示される TLS 証明書などが挙げられます。
ルーティングと負荷分散: ルーティングと負荷分散は、トラフィックの処理方法とルーティング方法を定義します。プロトコル、HTTP ヘッダー、HTTP パスなどのパラメータに基づいて、トラフィックをサービスにルーティングできます。使用するロードバランサによっては、複数のゾーンやリージョンにトラフィックを分散して、ユーザーのためにレイテンシの短縮や復元力の向上を図る場合もあります。
バックエンド: バックエンドは、エンドポイントのタイプ、アプリケーションプラットフォーム、バックエンドサービスディスカバリの統合によって定義されます。GKE などの特定のアプリケーション環境には、サービスディスカバリの統合が利用されており、これによってロードバランサのバックエンドは、GKE エンドポイントの増減に合わせて動的に更新されます。

次の図は、外部トラフィックと内部トラフィックという 2 つの異なるタイプのトラフィックフローを使用してこれらの概念を示しています。外部 HTTP(S) ロードバランサは、世界各地にある何百もの Google の接続拠点を通過する公共のインターネット上のトラフィックをリッスンします。このグローバルなフロントエンドにより、トラフィックを Google データセンターでバックエンドに負荷分散する前に、クライアントに近いエッジでトラフィックを終端できます。ここに示す内部 HTTP(S) ロードバランサは、VPC ネットワークのスコープ内でリッスンし、内部でプライベート通信を行えるようにします。こうしたロードバランサの特性を、アプリケーションのさまざまなユースケースに合わせて活用できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_vpc_network.max-1000x1000.jpg

Ingress コントローラと Service コントローラによる GKE の負荷分散

GKE クラスタの外部にアプリケーションを公開するために、GKE には組み込みの GKE Ingress コントローラと GKE Service コントローラが用意されており、これらが GKE ユーザーに代わって Google Cloud ロードバランサ（GCLB）をデプロイします。これらは仮想マシンで使用されるロードバランサと同じですが、ライフサイクルが GKE によって完全に自動化、制御される点が異なります。GKE のネットワークコントローラは、Ingress API および Service API の標準に準拠した独自の高レベルなインターフェースを介して、Pod IP へのコンテナネイティブの負荷分散を行います。

次の図は、GKE のネットワークコントローラがロードバランサの作成を自動化する方法を示しています。アプリ管理者あるいはインフラストラクチャ管理者が、GKE クラスタに対して宣言型マニフェストをデプロイします。Ingress コントローラは GKE ネットワークリソース（Ingress や MultiClusterIngress オブジェクトなど）を監視し、マニフェストに基づいて Cloud ロードバランサ（および IP アドレス指定やファイアウォールルールなど）をデプロイします。コントローラは引き続きこれらのリソースを管理し、環境やトラフィックの変化に基づいてロードバランサのバックエンドを更新します。そのため、GKE のロードバランシングは開発者向けのシンプルなインターフェースを備えた、動的で持続可能なロードバランサになります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_GKE_load_balancing.max-1000x1000.jpg

アプリケーションの公開に影響する要因

GKE でアプリケーションを公開する方法の選択に影響を与える要因は数多くあります。ディシジョンツリーの根元にいくつかのコア要因があり、これを使用してネットワーキングソリューションセットを絞り込むことができます。この要因とは、クライアントネットワーク、プロトコル、アプリケーションのリージョンです。

クライアントネットワークは、アプリケーションクライアントがアプリケーションにアクセスするネットワークです。これは、ロードバランサのフロントエンドがリッスンする場所に影響を及ぼします。たとえば、クライアントがアプリケーションと同じ GKE クラスタ内にあるとします。この場合、クライアントはクラスタネットワーク内からアプリケーションにアクセスし、Kubernetes ネイティブの ClusterIP 負荷分散を使用できます。クライアントが内部ネットワーククライアントの場合は、Google Cloud VPC 内から、または Google Cloud Interconnect を介してオンプレミスネットワークからアプリケーションにアクセスします。また、クライアントが外部ネットワーククライアントの場合は、公共のインターネットを介してアプリケーションにアクセスします。ネットワークのタイプごとに、異なる負荷分散トポロジが必要です。

プロトコルとは、アプリケーションがそのクライアントと通信する言語です。音声、ゲーム、低レイテンシのアプリケーションは通常、TCP または UDP 上で直接通信するため、L4 できめ細かく制御できるロードバランサが必要です。その他のアプリケーションは HTTP、HTTPS、gRPC、HTTP2 で通信しますが、これらのプロトコルに基づいて負荷を分散するには、ロードバランサがそのプロトコルを理解できる必要があります。プロトコルの要件では、どの種類のアプリケーションが最適であるかさらに定義しています。

アプリケーションのリージョンとは、アプリケーションが複数の GCP リージョンや GKE クラスタ間で分散される度合いを示します。アプリケーションの単一のインスタンスをホストするのと、2 つの独立した GKE クラスタ間でアクティブ / パッシブなアプリケーションをホストするのとでは、要件が異なります。5 つの GKE クラスタ間で地理的に分散したアプリケーションをホストして、エンドユーザーのより近くにワークロードを配置してレイテンシを短縮するには、さらにロードバランサがマルチクラスタやマルチリージョンに対応している必要があります。

ネットワーク設計に影響を与える要因は、以下で対象としているもの以外にもある場合があります。たとえば、レイテンシ要件、送信元 IP アドレスの維持、高帯域幅などが挙げられます。このリストは完全なものではありませんが、これを活用して、ソリューションの選択肢を絞り込み、要件間のトレードオフについて理解を深めるのにお役立てください。

Ingress および Services を使用したアプリケーションの公開

GKE のネイティブの Ingress コントローラと Service コントローラのスイートを使用すると、デフォルトでアプリケーションをシームレスかつ安全に本番環境に公開できます。これらのネットワークコントローラは GCLB と密接に統合されているため、Kubernetes ネイティブのインターフェースで、コンテナ IP にネイティブに負荷分散する GCLB をデプロイできます。次の表では、GKE の Ingress と Service のすべてのタイプを分類して示し、それぞれの主な特長について詳述します。GKE と Anthos Ingress のすべての機能の詳細な比較については、Ingress 機能をご覧ください。

https://storage.googleapis.com/gweb-cloudblog-publish/images/gke_resources-.max-1000x1000.jpg

さまざまなネイティブのオプションがあり、プロトコル、ネットワークアクセス、リージョンの観点からそれぞれ異なる機能を備えています。次のセクションでは、これらのネットワーキングソリューションを上記の要因別に分類します。

クライアントネットワーク

GKE のロードバランサは、内部ロードバランサと外部ロードバランサに大別できます。内部とは VPC ネットワークを指し、インターネットから直接アクセスできない内部プライベートネットワークです。外部とは、公共のインターネットを指します。ClusterIP Service は単一の GKE クラスタに対して内部となるため、VPC ネットワークよりもさらに小さなネットワークが対象となります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_Client_network.max-600x600.jpg

*パブリック GKE クラスタは各 GKE ノードにパブリック IP とプライベート IP を提供するため、NodePort Service に内部と外部の両方からアクセスできます。

プロトコル

ロードバランサは多くの場合、ポートやプロトコルなどのネットワーク情報に基づいてトラフィックをルーティングするレイヤ 4（L4）と、クライアントセッションなどのアプリケーション情報を認識するレイヤ 7（L7）に分類されます。GKE ロードバランサも、L4 と L7 に分類でき、下の表に示すように特定のプロトコルをサポートします。

https://storage.googleapis.com/gweb-cloudblog-publish/images/5_Protocol.max-600x600.jpg

アプリケーションのリージョン

GKE 負荷分散ソリューションのリージョンは、次の 2 つの領域に分類できます。

バックエンドのスコープ（またはクラスタのスコープ）は、ロードバランサが複数の GKE クラスタにわたってバックエンドにトラフィックを送信できるかどうかを示します。Ingress for Anthos（またはマルチクラスタ Ingress）は、異なるクラスタや異なる Google Cloud リージョンから Pod にトラフィックを転送する単一の VIP を公開する機能を備えています。
フロントエンドのスコープは、ロードバランサ IP が単一のリージョン内でリッスンするか複数のリージョンにわたってリッスンするかを示します。すべての外部ロードバランサは、本質的にマルチリージョンであるインターネット上でリッスンしますが、一部の内部ロードバランサは単一のリージョン内のみでリッスンします。

下の表は、この 2 つの区分で GKE の負荷分散ソリューションを分類したものです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/6_Application_regionality.max-800x800.jpg

これらはアプリケーションネットワーキングのすべての側面を網羅しているわけではありませんが、上記の各要因を検討することで、さまざまな側面を考慮したうえでアプリケーションに最適なソリューションを決定できます。ほとんどの GKE 環境では、数多くのさまざまなタイプのアプリケーションをホストしており、それぞれに固有の要件があります。そのため、特定のクラスタで複数のソリューションを使用する可能性もあります。それらの機能の詳細については、次のリソースをご覧ください。

GKE アプリケーション公開用のその他のソリューション

Kubernetes のエコシステムは巨大で、アプリケーションの公開に使用できるソリューションは上記以外にもあります。ネイティブの GKE ロードバランサの代替または補完として、以下のソリューションを実行できる場合もあります。

クラスタ内 Ingress

クラスタ内 Ingress はソフトウェアによる Ingress コントローラを指し、Ingress プロキシを Kubernetes クラスタ自体の内部でホストします。これは、負荷分散インフラストラクチャを Kubernetes クラスタと分離してホスト、管理する Cloud Ingress コントローラとは区別されます。これらのサードパーティソリューションは通常、クラスタオペレータが自分でデプロイし、自分で管理します。istio-ingressgateway と nginx-ingress の 2 つは、よく使用される、オープンソースのクラスタ内 Ingress コントローラの例です。クラスタ内 Ingress コントローラは通常、Kubernetes Ingress 仕様に準拠しており、さまざまな機能と高い操作性を備えています。オープンソースのソリューションには、より厳密な管理とより高レベルの技術的専門知識が求められる可能性がありますが、アプリケーションに必要な特定の機能を提供するものであれば、ニーズに適している場合があります。また、オープンソースコミュニティが中心となって構築された、高度な機能とエンタープライズサポートを提供する巨大なエコシステム、Enterprise Ingress ソリューションもあります。

スタンドアロン NEG

GKE の Ingress コントローラと Service コントローラによる Google Cloud Load Balancing のデプロイは、自動化された宣言型の Kubernetes ネイティブな方法です。また、ロードバランサを GKE バックエンドに手動でデプロイするのが有効なユースケースもあります。たとえば、ロードバランサを直接、より詳細に制御する場合や、コンテナと VM バックエンド間で負荷分散を行う場合などが挙げられます。スタンドアロン NEG は、ネットワークエンドポイントグループ（NEG）の Pod バックエンド IP を動的に更新しますが、ロードバランサのフロントエンドを Google Cloud API を介して手動でデプロイできるようにすることで、この機能を提供します。これにより、GKE クラスタによって制御される動的バックエンドを維持しながら、ロードバランサを最大限に直接制御できます。

サービスメッシュ

サービスメッシュは、集中コントロールプレーンを通じてクライアント側の負荷分散を行います。Istio プロジェクトで内部通信のために Kubernetes に L7 のサービスメッシュが導入された一方で、サービスメッシュのエコシステムはスコープや機能を急速に拡大してきました。Traffic Director と Anthos Service Mesh では、GKE クラスタ間、リージョン間、またコンテナと VM 間で内部トラフィックを負荷分散する機能が強化されています。これにより、内部負荷分散（East-West トラフィック）と、アプリケーションの公開（North-South トラフィック）の線引きがあいまいになってきました。最新のサービスメッシュコントロールプレーンでは柔軟性や達成度が向上しており、同じサービスメッシュスコープ内にクライアントとサーバーの両方を維持できるようになってきています。上記の GKE Ingress や Service のソリューションでは通常、独自のサイドカープロキシを持たないクライアントに中間プロキシのロードバランサをデプロイします。ただし、クライアントとサーバーが同じメッシュ内にある場合、従来のアプリケーションの公開は、中間プロキシの負荷分散ではなく、メッシュを介して処理できます。

サービスにおける GKE

Google Cloud では、ユースケースに応じて、GKE アプリケーションをサービスとして公開するさまざまな方法をサポートしています。GKE がコンテナのあらゆるユースケースに対して、最も包括的なサポートを提供していることは間違いないでしょう。このブログ投稿がアプリケーションアクセスの設計方法の理解に役立った方は、他の方も理解できるよう、この投稿を自由に共有していただければ幸いです。

- カスタマーエンジニア Harrison Sweeney、プロダクトマネージャー Mark Church

投稿先