このページでは、外部アプリケーション ロードバランサ用の Ingress が Google Kubernetes Engine(GKE)でどのように機能するかについて説明します。外部ロード バランシング用に Ingress を設定して使用する方法もご覧ください。
GKE でのロード バランシングの使用するに関する一般的な情報については、外部アプリケーション ロードバランサ用の Ingress をご覧ください。
Google Kubernetes Engine(GKE)ネットワーキングは Cloud Load Balancing 上に成り立っています。Cloud Load Balancing を使用すると、単一のエニーキャスト IP アドレスにより、最も近い Google Cloud ロードバランサへの最小コストのパスが判断されます。
Google Cloud 機能のサポート
BackendConfig を使用すると、次のような機能を使用するように外部アプリケーション ロードバランサを構成できます。
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
が含まれています。
ロードバランサの事前共有証明書
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
を参照します。
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 の機能の構成について学ぶ。
HTTP から HTTPS へのリダイレクトを有効にする方法を確認する。