Service ネットワーキングの概要

このページでは、Google Kubernetes Engine（GKE）に Service をデプロイする方法について説明します。このページは、Service ネットワーキングや GKE に存在する Service ネットワーク機能の詳細を理解するのに役立ちます。

Service ネットワーキングの概要

Service ネットワーキングとは、クライアントが使用しているアプリケーションの基礎となる所有権、実装、または環境を抽象化する方法でアプリを公開することです。最も簡単な形式では、Service はアプリケーションにアクセスするための中継点となる、安全性、整合性、可用性を備えたエンドポイントです。

クライアントとアプリケーションは、通信方法に関して多様なニーズを抱えています。アプリケーションを Kubernetes クラスタで公開して Pod の消費を促すといった簡単なものから、世界中のインターネット クライアントからアプリケーションへのトラフィックをルーティングするという複雑なニーズまで存在します。GKE では、独自のユースケースに適した Service としてアプリケーションを公開する方法を多数ご用意しています。

Service の要素

アプリケーションをクライアントに公開するには、Service の 3 つの主要要素を考慮します。

  • フロントエンド: ロードバランサのフロントエンドでは、クライアントがロードバランサにアクセスしてトラフィックを送信できるスコープを定義します。これは、ネットワーク上でトラフィックをリッスンする場所です。ネットワーク、特定のリージョン（またはネットワーク内のサブネット）、ネットワーク内の 1 つ以上の IP、ポート、特定のプロトコル、セキュア接続の確立で使用される TLS 証明書から構成されます。

  • ルーティングとロード バランシング: ルーティングとロード バランシングでは、トラフィックの処理とルーティングの方法を定義します。プロトコル、HTTP ヘッダー、HTTP パスなどのパラメータに基づいてトラフィックを Service にルーティングできます。使用するロードバランサによっては、トラフィックを分散させると、レイテンシが低くなり、ユーザーに対する復元性が向上する場合があります。

  • バックエンド: ロードバランサのバックエンドは、エンドポイントの種類、アプリケーション プラットフォーム、バックエンド サービス ディスカバリの統合によって定義されます。GKE では、サービス ディスカバリの統合を使用し、GKE エンドポイントの増減に合わせてロードバランサのバックエンドを動的に更新します。

次の図は、内部トラフィックと外部トラフィックとこれらのコンセプトの関係を示しています。

この図では、外部アプリケーション ロードバランサが、世界中の数百もの Google の接続拠点を介して公共のインターネットからのトラフィックをリッスンしています。このグローバルなフロントエンドにより、Google データセンターでバックエンドにロードバランスする前に、クライアントに近いエッジでトラフィックを終端できます。

内部アプリケーション ロードバランサは VPC ネットワークのスコープ内でリッスンするため、プライベート通信を内部で行うことができます。アプリケーションのさまざまなユースケースに合わせて、こうしたロードバランサの特性を活用できます。

GKE のロード バランシングについて理解する

GKE クラスタの外部でアプリケーションを公開するために、GKE は組み込みの GKE Ingress コントローラと GKE Service コントローラを使用して、GKE ユーザーに代わってロードバランサをデプロイします。これは、VM のライフサイクル インフラストラクチャが完全に自動化され、GKE によって制御される点を除き、VM ロード バランシングのインフラストラクチャと同じです。GKE のネットワーク コントローラは、Ingress API と Service API の標準に準拠した独自の高レベル インターフェースを介して、Pod IP のロード バランシングをコンテナ ネイティブで行います。

次の図は、GKE ネットワーク コントローラがロードバランサの作成を自動化する方法を示しています。

図のように、インフラストラクチャ管理者またはアプリ管理者が GKE クラスタの宣言型マニフェストをデプロイします。Ingress コントローラと Service コントローラは、GKE ネットワーキング リソース（Ingress オブジェクトなど）を監視し、マニフェストに基づいてロードバランサ（IP アドレス指定、ファイアウォール ルールなどを含む）をデプロイします。

コントローラは、環境の変化やトラフィックの変化に基づいてロードバランサとバックエンドの管理を行います。このため、GKE のロード バランシングは、デベロッパー向けのインターフェースを備えた、動的で自律的なロードバランサになります。

アプリケーションの公開方法を選択する

アプリケーションを GKE で公開する方法を選択する場合、クライアント ネットワーク、プロトコル、アプリケーションのリージョンの対象などの要素を中心に検討します。GKE の Ingress コントローラと Service コントローラのスイートを使用すると、これらの要因を念頭にアプリケーションを公開できます。

以降のセクションは、アプリケーション ネットワーキングのあらゆる側面を網羅するものではありませんが、これらの要因を確認すると、アプリケーションに最適なソリューションを判断する際に役立ちます。ほとんどの GKE 環境にはさまざまな種類のアプリケーションがホストされ、それぞれに固有の要件が存在します。このため、特定のクラスタで複数のソリューションが使用される可能性があります。

Ingress 機能の詳細な比較については、Ingress の構成をご覧ください。

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

クライアント ネットワークは、アプリケーション クライアントがアプリケーションにアクセスするネットワークです。これは、ロードバランサのフロントエンドがリッスンする場所に影響します。たとえば、クライアントがアプリケーションと同じ GKE クラスタ内にあるとします。この場合、クライアントはクラスタ ネットワーク内からアプリケーションにアクセスし、Kubernetes ネイティブの ClusterIP ロード バランシングを使用できます。

クライアントが内部ネットワーク クライアントの場合もあります。その場合、Virtual Private Cloud（VPC）内または Cloud Interconnect を介してオンプレミス ネットワークからアプリケーションにアクセスできます。

クライアントが外部ネットワーク クライアントの場合は、公共のインターネットを介してアプリケーションにアクセスします。ネットワークの種類に応じてロード バランシング トポロジが決まります。

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

次の表に、内部および外部ネットワークで使用可能なソリューションの概要を示します。

ネットワークの種類 利用可能なソリューション
内部 ClusterIP Service
NodePort Service
内部 LoadBalancer Service
内部 Ingress
外部 NodePort Service1
外部 LoadBalancer Service
外部 Ingress
マルチクラスタ Ingress

1 --no-enable-private-nodes フラグを使用する GKE クラスタには、パブリック IP アドレスとプライベート IP アドレスを持つノードがあるため、NodePort Service には内部と外部の両方からアクセスできます。

プロトコル

プロトコルは、クライアントがアプリケーションとの通信に使用する言語です。音声、ゲーム、低レイテンシのアプリケーションは通常、TCP または UDP 上で直接通信するため、レイヤ 4 できめ細かい制御を行うロードバランサを必要とします。その他のアプリケーションは HTTP、HTTPS、gRPC、HTTP2 で通信しますが、これらのプロトコルを明示的にサポートするロードバランサが必要です。プロトコルの要件では、アプリケーションを公開する最適な方法が詳しく定義されます。

GKE では、レイヤ 4 ロードバランサを構成し、ポート、プロトコルなどのネットワーク情報に基づいてトラフィックをルーティングできます。また、レイヤ 7 ロードバランサを使用すると、クライアント セッションなどのアプリケーション情報を認識できます。次の表のように、ロードバランサはそれぞれ特定のプロトコルをサポートします。

レイヤ プロトコル 利用可能なソリューション
L4 TCP
UDP		 ClusterIP Service
NodePort Service
内部 LoadBalancer Service
外部 LoadBalancer Service
L7 HTTP
HTTPS
HTTP2		 内部 Ingress
外部 Ingress
マルチクラスタ Ingress

アプリケーションの地域性

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

GKE ロード バランシング ソリューションの地域性は、次の 2 つの部分に分かれています。

  • バックエンドのスコープ（クラスタのスコープ）: ロードバランサが複数の GKE クラスタにまたがってバックエンドにトラフィックを送信できるかどうかを示します。マルチクラスタ Ingress では、単一の仮想 IP アドレスを公開し、異なるリージョンの別クラスタから Pod にトラフィックを転送できます。

  • フロントエンドのスコープ: この範囲は、ロードバランサの IP が単一リージョン内か、複数のリージョンにわたってリッスンされるかを示します。すべての外部ロードバランサは本質的にマルチリージョンで、インターネット上でリッスンしますが、一部の内部ロードバランサは単一リージョン内のみでリッスンします。

下の表は、この 2 つの区分で GKE のロード バランシング ソリューションを分類したものです。

バックエンド スコープ
（クラスタ スコープ）		 利用可能なソリューション
単一クラスタ ClusterIP Service
NodePort Service
内部 LoadBalancer Service
外部 LoadBalancer Service
内部 Ingress
外部 Ingress
マルチクラスタ マルチクラスタ Ingress
フロントエンド スコープ 利用可能なソリューション
リージョン ClusterIP Service
内部 Ingress
グローバル ClusterIP Service
NodePort Service
内部 LoadBalancer Service
外部 LoadBalancer Service
外部 Ingress
マルチクラスタ Ingress

アプリケーションの公開に関するその他のソリューション

アプリケーションの公開に使用できるソリューションは上記以外にもあります。GKE ロードバランサの代替または補完として、以下のソリューションが有効な場合もあります。

クラスタ内 Ingress

クラスタ内 Ingress はソフトウェアによる Ingress コントローラで、Ingress プロキシを Kubernetes クラスタ内にホストしています。これは GKE Ingress コントローラとは異なります。後者はロード バランシング インフラストラクチャを Kubernetes クラスタと分離してホストし、管理します。これらのサードパーティ ソリューションは通常、クラスタ オペレータが自分でデプロイし、管理します。istio-ingressgateway と nginx-ingress の 2 つはオープンソースのクラスタ内 Ingress コントローラとしてよく利用されています。

クラスタ内 Ingress コントローラは Kubernetes Ingress 仕様に準拠し、さまざまな機能と高い操作性を備えています。オープンソースのソリューションには、より厳密な管理と高レベルの技術的な専門知識が求められる可能性がありますが、アプリケーションが必要とする機能を提供するものであれば、要件に適している場合があります。また、オープンソース コミュニティが中心となって構築された、巨大な Enterprise ingress ソリューション エコシステムでも、高度な機能とエンタープライズ サポートを提供しています。

スタンドアロン ネットワーク エンドポイント グループ（NEG）

GKE の Ingress コントローラと Service コントローラによる Cloud Load Balancing のデプロイは、自動化された宣言型の Kubernetes ネイティブな方法です。また、ロードバランサを GKE バックエンドに手動でデプロイしたほうが良い場合もあります。たとえば、ロードバランサを直接、きめ細かく制御する場合や、コンテナと VM バックエンド間でロード バランシングを行う場合などが該当します。

スタンドアロン NEG は、NEG の Pod バックエンド IP を動的に更新することでこの機能を提供しますが、ロードバランサのフロントエンドは手動でデプロイできます。これにより、GKE クラスタによって制御される動的バックエンドを維持しながら、ロードバランサを最大限に直接制御できます。

サービス メッシュ

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

次のステップ