外部アプリケーション ロードバランサ用の Ingress

Autopilot Standard

---

このページでは、外部アプリケーション ロードバランサ用の Ingress が Google Kubernetes Engine（GKE）でどのように機能するかについて説明します。外部ロード バランシング用に Ingress を設定して使用する方法もご覧ください。

GKE でのロード バランシングの使用するに関する一般的な情報については、外部アプリケーション ロードバランサ用の Ingress をご覧ください。

Google Kubernetes Engine（GKE）ネットワーキングは Cloud Load Balancing 上に成り立っています。Cloud Load Balancing を使用すると、単一のエニーキャスト IP アドレスにより、最も近い Google Cloud ロードバランサへの最小コストのパスが判断されます。

Google Cloud 機能のサポート

BackendConfig を使用すると、次のような機能を使用するように外部アプリケーション ロードバランサを構成できます。

• Google Cloud Armor
• ヘルスチェック

• Cloud CDN

• Identity-Aware Proxy

BackendConfig は、Google Cloud 機能の構成情報を保持するカスタム リソースです。サポートされている機能の詳細については、Ingress の構成をご覧ください。

WebSocket のサポート

外部アプリケーション ロードバランサでは、WebSocket プロトコルは構成なしで機能します。

WebSocket プロトコルを使用する場合は、デフォルトの 30 秒よりも長いタイムアウト値を使用することをおすすめします。Google Cloud 外部アプリケーション ロードバランサ経由で送信される WebSocket トラフィックのバックエンド サービスのタイムアウトは、アイドル状態かどうかにかかわらず、WebSocket 接続をオープン状態に保てる最長時間として解釈されます。

Ingress で構成されたバックエンド サービスのタイムアウト値を設定するには、BackendConfig オブジェクトを作成し、Service マニフェストで beta.cloud.google.com/backend-config アノテーションを使用します。

構成の情報については、バックエンド レスポンスのタイムアウトをご覧ください。

HTTPS ロードバランサの静的 IP アドレス

Ingress オブジェクトを作成すると、クライアントが Service、さらには実行中のコンテナにアクセスするために使用できる固定の外部 IP アドレスを取得できます。この IP アドレスは、Ingress オブジェクトの存続期間にわたって持続するという意味で固定されます。ただし、Ingress を削除して同じマニフェスト ファイルから新しい Ingress を作成しても、同じ外部 IP アドレスが得られる保証はありません。

Ingress を削除して新しい IP アドレスを作成した後も、同じ永続 IP アドレスが必要な場合は、グローバルな静的外部 IP アドレスを予約する必要があります。その後、Ingress マニフェストに、予約した静的 IP アドレスの名前を示すアノテーションを追加します。エフェメラル IP アドレスではなく静的 IP アドレスを使用するように既存の Ingress を変更すると、GKE がロードバランサの転送ルールを再作成するときに、ロードバランサの IP アドレスが変更されることがあります。

たとえば、my-static-address という名前のグローバル静的外部 IP アドレスを次のように予約しているとします。Ingress マニフェストで、次のように kubernetes.io/ingress.global-static-ip-name を追加します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: my-static-address

クライアントとロードバランサ間の HTTPS（TLS）の設定

HTTP(S) ロードバランサは、クライアントとアプリケーションの間のプロキシとして機能します。クライアントからの HTTPS リクエストを受け入れるには、ロードバランサは証明書を持っていなければなりません。これにより、適切な送信先であることをクライアントに示すことができます。さらに、ロードバランサには、HTTPS handshake を完了するための秘密鍵も必要です。

ロードバランサがクライアントからの HTTPS リクエストを受け入れると、クライアントとロードバランサ間のトラフィックは TLS で暗号化されます。ただし、TLS 暗号化はロードバランサで終了し、アプリケーションへのリクエストの転送は暗号化なしに行われます。ロードバランサとアプリケーションの間でトラフィックを暗号化する方法については、ロードバランサとアプリケーション間の HTTPS をご覧ください。

Google マネージド SSL 証明書、またはユーザー自身が管理する証明書を使用できます。Google マネージド証明書を使用する Ingress の作成方法については、Google マネージド SSL 証明書の使用をご覧ください。

ご自身で作成した証明書と鍵を HTTP(S) ロードバランサで利用するには、Kubernetes Secret オブジェクトを作成します。Secret には証明書とキーが格納されます。次の例のように、Ingress マニフェストの tls フィールドに Secret を追加します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress-2
spec:
  tls:
  - secretName: SECRET_NAME
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: SERVICE_NAME
            port:
              number: 60000

このマニフェストには次の値が含まれます。

• SECRET_NAME: 作成した Secret の名前。
• SERVICE_NAME: バックエンド サービスの名前。

Secret の変更内容は一定期間ごとに反映されるので、Secret 内のデータを変更した場合、それらの変更がロードバランサに適用されるまでに最大で 10 分かかります。

詳細については、Ingress を使用した HTTPS ロード バランシングにおける複数 SSL 証明書の使用をご覧ください。

GKE クラスタの HTTPS で暗号化された Ingress を保護するには、Ingress の保護の例をご覧ください。

HTTP の無効化

クライアントと HTTP(S) ロードバランサ間のすべてのトラフィックに HTTPS を使用する場合は、Ingress マニフェストに kubernetes.io/ingress.allow-http アノテーションを追加します。アノテーションの値を "false" に設定します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress-2
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: SECRET_NAME
  ...

このマニフェストには、作成した Secret の名前である SECRET_NAME が含まれています。

注: アノテーション networking.gke.io/managed-certificates を使用している場合、アノテーション kubernetes.io/ingress.allow-http: false は使用できません。外部アプリケーション ロードバランサのプログラムが完全に作成された後で初めて、Ingress を更新してアノテーション kubernetes.io/ingress.allow-http: false を追加できます。

注意: マルチクラスタ Ingress では HTTP を無効にできません。

ロードバランサの事前共有証明書

HTTP(S) 終端用に Kubernetes Secret を使用してロードバランサに証明書を提供する代わりに、事前に Google Cloud プロジェクトにアップロードしておいた証明書を使用することもできます。詳細については、事前共有証明書の使用と Ingress を使用した HTTPS 負荷分散における複数 SSL 証明書の使用をご覧ください。

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

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

ロードバランサとアプリケーションの間で使用されるプロトコルを構成するには、cloud.google.com/app-protocols アノテーションを Service マニフェストで使用します。 コンテナ ネイティブのロード バランシングを使用しない場合、このサービス マニフェストに type: NodePort を含める必要があります。コンテナ ネイティブのロード バランシングを使用する場合は、type: ClusterIP を使用します。

次の Service マニフェストでは、2 つのポートを指定しています。そのアノテーションによると、HTTP(S) ロードバランサが Service のポート 80 をターゲットにしているとき、HTTP を使用する必要があります。また、ロードバランサが Service のポート 443 をターゲットにしているときは、HTTPS を使用する必要があります。

Service マニフェストでは、ポートのアノテーションに name 値を含める必要があります。Service ポートを編集するには、targetPort 値ではなく、割り当てられた name を参照します。

注意: 潜在的なダウンタイムを制限するには、この機能を有効にするときに Service のポート名を編集しないでください。Service のポートに名前がない場合は、cloud.google.com/app-protocols: '{"": "HTTPS"}' と同様に、空のポート名をアノテーションのキーとして使用します。初期設定後にポート名またはアノテーションを編集すると、アプリケーションのダウンタイムが発生する可能性があります。

apiVersion: v1
kind: Service
metadata:
  name: my-service-3
  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

次のステップ

• Deployment、Service、Ingress を作成して外部アプリケーション ロードバランサを構成する。

• Service を使用してアプリケーションを公開する方法を学習する。

• Ingress で外部アプリケーション ロードバランサを設定するチュートリアルを学習する。

• GKE でのネットワーキングの概要を読む。

• Ingress の機能の構成について学ぶ。

• HTTP から HTTPS へのリダイレクトを有効にする方法を確認する。