内部 HTTP(S) 負荷分散での Ingress

このページでは、内部 HTTP(S) 負荷分散の Ingress が Google Kubernetes Engine(GKE)でどのように機能するかについて説明します。また、内部 HTTP(S) 負荷分散の Ingress を設定して使用する方法についても説明します。

GKE では、内部 HTTP(S) ロードバランサは、プロキシベースのリージョンのレイヤ 7 ロードバランサです。内部負荷分散 IP アドレスの背後でサービスを実行し、スケーリングできます。GKE Ingress オブジェクトでは、GKE クラスタに Ingress オブジェクトを作成することで、内部 HTTP(S) ロードバランサがネイティブにサポートされます。

GKE の負荷分散に Ingress を使用する方法の一般的な情報については、Ingress を使用した HTTP(S) 負荷分散をご覧ください。

内部 HTTP(S) ロードバランサに Ingress を使用するメリット

内部 HTTP(S) 負荷分散に GKE Ingress を使用すると、次のメリットがあります。

  • 高可用性の GKE マネージド Ingress コントローラ。
  • 内部サービス間通信のための負荷分散。
  • ネットワーク エンドポイント グループ(NEG)でのコンテナ ネイティブの負荷分散。
  • HTTP と HTTPS がサポートされるアプリケーション ルーティング。
  • 復元性に優れたサービスのための高精度な Compute Engine ヘルスチェック。
  • トラフィック容量のニーズを満たすためにオンデマンドでデプロイされる Envoy ベースのプロキシ。

Google Cloud 機能のサポート

内部 HTTP(S) 負荷分散の Ingress では、さまざまな追加機能がサポートされます。

必要なネットワーク環境

内部 HTTP(S) ロードバランサは、ネットワークにプロキシのプールを提供します。プロキシは、URL マップ、BackendService のセッション アフィニティ、各バックエンド NEG の分散モードなどの要素に基づいて各 HTTP(S) リクエストを実行する場所を評価します。

リージョンの内部 HTTP(S) ロードバランサは、VPC ネットワーク内のそのリージョンのプロキシ専用サブネットを使用して、Google Cloud によって作成された各プロキシに内部 IP アドレスを割り当てます。

デフォルトでは、ロードバランサの転送ルールに割り当てられる IP アドレスは、プロキシ専用サブネットではなく、GKE によって割り当てられたノードのサブネット範囲から取得されます。ルールを作成するときに、サブネットの IP アドレスを手動で指定することもできます。

次の図は、内部 HTTP(S) ロードバランサのトラフィック フローの概要を示します。

内部 HTTP(S) ロード バランシングでの Ingress の図

内部 HTTP(S) ロードバランサの仕組みは次のとおりです。

  1. クライアントは、ロードバランサの転送ルールの IP アドレスとポートに接続します。
  2. プロキシは、クライアントのネットワーク接続を受信して終了します。
  3. プロキシは、NEG 内の適切なエンドポイント(Pod)への接続を確立します。これは、ロードバランサの URL マップとバックエンド サービスによって決定されます。

各プロキシは、対応するロードバランサの転送ルールで指定された IP アドレスとポートでリッスンします。プロキシからエンドポイントに送信される各パケットの送信元 IP アドレスは、プロキシ専用サブネットからプロキシに割り当てられた内部 IP アドレスです。

GKE Ingress コントローラでファイアウォール ルールのデプロイが管理されるため、手動でデプロイする必要はありません。

ロードバランサとアプリケーション間の HTTPS(TLS)

内部 HTTP(S) ロードバランサは、クライアントとアプリケーション間のプロキシとして機能します。クライアントは、HTTP または HTTPS を使用してロードバランサ プロキシと通信できます。ロードバランサ プロキシからアプリケーションへの接続は、デフォルトで HTTP を使用します。ただし、アプリケーションが GKE Pod で実行され、HTTPS リクエストを受信できる場合は、ロードバランサがリクエストをアプリケーションに転送する際に HTTPS を使用するようにロードバランサを構成できます。

ロードバランサとアプリケーションの間で使用されるプロトコルを構成するには、cloud.google.com/app-protocols アノテーションを Service マニフェストで使用します。

次の Service マニフェストでは、2 つのポートを指定しています。このアノテーションは、内部 HTTP(S) ロードバランサが 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

次のステップ