このページでは、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 ベースのプロキシ。
Google Cloud 機能のサポート
内部アプリケーション ロードバランサ用の Ingress は、さまざまな追加機能をサポートしています。
- Google Cloud を使用したセルフマネージド SSL 証明書。この機能では、リージョン証明書のみがサポートされます。
- Kubernetes Secret を使用したセルフマネージド SSL 証明書。
- セッション アフィニティと接続タイムアウトの BackendService 機能。これらの機能は、BackendConfig を使用して構成できます。
内部アプリケーション ロードバランサに必要なネットワーク環境
内部アプリケーション ロードバランサは、ネットワークにプロキシのプールを提供します。プロキシは、URL マップ、BackendService のセッション アフィニティ、各バックエンド NEG の分散モードなどの要素に基づいて各 HTTP(S) リクエストを実行する場所を評価します。
リージョンの内部アプリケーション ロードバランサは、VPC ネットワーク内のそのリージョンのプロキシ専用サブネットを使用して、Google 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
次のステップ
- プロキシ専用サブネットをデプロイする方法を確認する。
- 外部アプリケーション ロードバランサ用の Ingress について確認する。
- 内部ロードバランサ用の Ingress の構成方法を学習する。
- GKE でのネットワーキングの概要を読む。