このページでは、Google Kubernetes Engine(GKE)で内部アプリケーション ロードバランサ用の Ingress がどのように機能するかについて説明します。内部アプリケーション ロードバランサ用の Ingress を設定して使用する方法についても説明します。
GKE では、内部アプリケーション ロードバランサは、プロキシベースのリージョンのレイヤ 7 ロードバランサです。内部ロード バランシング IP アドレスの背後でサービスを実行し、サービスをスケーリングできます。GKE Ingress オブジェクトでは、GKE クラスタに Ingress オブジェクトを作成することで、内部アプリケーション ロードバランサがネイティブにサポートされます。
GKE のロード バランシングに Ingress を使用する方法の一般的な情報については、Ingress を使用した HTTP(S) ロード バランシングをご覧ください。
内部アプリケーション ロードバランサに Ingress を使用するメリット
内部アプリケーション ロードバランサに GKE Ingress を使用すると、次のメリットがあります。
- 高可用性の GKE マネージド Ingress コントローラ。
- 内部サービス間通信のためのロード バランシング。
- ネットワーク エンドポイント グループ(NEG)でのコンテナ ネイティブのロード バランシング。
- HTTP と HTTPS がサポートされるアプリケーション ルーティング。
- 復元性に優れたサービスのための高精度な Compute Engine ヘルスチェック。
- トラフィック容量のニーズを満たすためにオンデマンドでデプロイされる Envoy ベースのプロキシ。
Trusted Cloud 機能のサポート
内部アプリケーション ロードバランサ用の Ingress は、さまざまな追加機能をサポートしています。
- Trusted Cloud by S3NSを使用したセルフマネージド SSL 証明書。この機能では、リージョン証明書のみがサポートされます。
- Kubernetes Secret を使用したセルフマネージド SSL 証明書。
- セッション アフィニティと接続タイムアウトの BackendService 機能。これらの機能は、BackendConfig を使用して構成できます。
内部アプリケーション ロードバランサに必要なネットワーク環境
内部アプリケーション ロードバランサは、ネットワークにプロキシのプールを提供します。プロキシは、URL マップ、BackendService のセッション アフィニティ、各バックエンド NEG の分散モードなどの要素に基づいて各 HTTP(S) リクエストを実行する場所を評価します。
リージョンの内部アプリケーション ロードバランサは、VPC ネットワーク内のそのリージョンのプロキシ専用サブネットを使用して、 Trusted Cloudによって作成された各プロキシに内部 IP アドレスを割り当てます。
デフォルトでは、ロードバランサの転送ルールに割り当てられる IP アドレスは、プロキシ専用サブネットではなく、GKE によって割り当てられたノードのサブネット範囲から取得されます。ルールを作成するときに、サブネットからの転送ルールに IP アドレスを手動で指定することもできます。
次の図は、前の段落で説明した内部アプリケーション ロードバランサのトラフィック フローの概要を示しています。
内部アプリケーション ロードバランサの仕組みは次のとおりです。
- クライアントは、ロードバランサの転送ルールの IP アドレスとポートに接続します。
- プロキシは、クライアントのネットワーク接続を受信して終了します。
- プロキシは、NEG 内の適切なエンドポイント(Pod)への接続を確立します。これは、ロードバランサの URL マップとバックエンド サービスによって決定されます。
各プロキシは、対応するロードバランサの転送ルールで指定された IP アドレスとポートでリッスンします。プロキシからエンドポイントに送信される各パケットの送信元 IP アドレスは、プロキシ専用サブネットからプロキシに割り当てられた内部 IP アドレスです。
ロードバランサとアプリケーション間の HTTPS(TLS)
内部アプリケーション ロードバランサは、クライアントとアプリケーションの間のプロキシとして機能します。クライアントは、HTTP または HTTPS を使用してロードバランサ プロキシと通信できます。ロードバランサ プロキシからアプリケーションへの接続は、デフォルトで HTTP を使用します。ただし、アプリケーションが GKE Pod で実行され、HTTPS リクエストを受信できる場合は、ロードバランサがリクエストをアプリケーションに転送する際に HTTPS を使用するようにロードバランサを構成できます。
ロードバランサとアプリケーションの間で使用されるプロトコルを構成するには、cloud.google.com/app-protocols
アノテーションを Service マニフェストで使用します。
次の Service マニフェストでは、2 つのポートを指定しています。このアノテーションは、内部アプリケーション ロードバランサが Service のポート 80 をターゲットにする場合は HTTP を使用し、Service のポート 443 をターゲットにする場合は HTTPS を使用するように指定します。
アノテーションでポートの name
項目を使用する必要があります。別の項目(targetPort
など)は使用しないでください。
apiVersion: v1
kind: Service
metadata:
name: my-service
annotations:
cloud.google.com/app-protocols: '{"my-https-port":"HTTPS","my-http-port":"HTTP"}'
spec:
type: NodePort
selector:
app: metrics
department: sales
ports:
- name: my-https-port
port: 443
targetPort: 8443
- name: my-http-port
port: 80
targetPort: 50001