外部負荷分散向け Ingress の構成

このページでは、Kubernetes Ingress オブジェクトを作成して、外部 HTTP(S) ロードバランサを構成する方法について説明します。1 つの Ingress オブジェクトは 1 つ以上の Service オブジェクトに関連付けられている必要があります。それぞれの Service オブジェクトは Pod のセットに関連付けられます。

Service オブジェクトには 1 つ以上の servicePort 構造があります。Ingress がターゲットにしているそれぞれの servicePort は、Google Cloud バックエンド サービス リソースに関連付けられます。

始める前に

作業を始める前に、次のことを確認してください。

• Google Kubernetes Engine API が有効になっていることを確認します。
Google Kubernetes Engine API を有効にする
• Cloud SDK がインストール済みであることを確認します。

次のいずれかの方法で gcloud のデフォルトの設定を指定します。

• gcloud init。デフォルトの設定全般を確認する場合に使用します。
• gcloud config。プロジェクト ID、ゾーン、リージョンを個別に設定する場合に使用します。

gcloud init の使用

エラー One of [--zone, --region] must be supplied: Please specify location を受信した場合は、このセクションの内容を実施します。

1. gcloud init を実行して、次の操作を行います。

   gcloud init

   リモート サーバーで SSH を使用している場合は、--console-only フラグを指定して、コマンドがブラウザを起動しないようにします。

   gcloud init --console-only

2. 手順に従って gcloud を承認し、Google Cloud アカウントを使用します。
3. 新しい構成を作成するか、既存の構成を選択します。
4. Google Cloud プロジェクトを選択します。
5. ゾーンクラスタの場合はデフォルトの Compute Engine ゾーン、リージョン クラスタまたは Autopilot クラスタの場合はデフォルトの Compute Engine リージョンを選択します。

注: これらのデフォルト設定は、gcloud コマンドで --project、--zone、--region フラグを使用することでオーバーライドできます。

gcloud config の使用

• デフォルトのプロジェクト ID を設定します。

  gcloud config set project PROJECT_ID

• ゾーンクラスタを使用する場合は、デフォルトのコンピューティング ゾーンを設定します。

  gcloud config set compute/zone COMPUTE_ZONE

• Autopilot クラスタまたはリージョン クラスタを使用する場合は、デフォルトのコンピューティング リージョンを設定します。

  gcloud config set compute/region COMPUTE_REGION

• gcloud を最新バージョンに更新します。

  gcloud components update

注: これらのデフォルト設定は、gcloud コマンドで --project、--zone、--region フラグを使用することでオーバーライドできます。

プロジェクトに、HTTP(S) 負荷分散アドオンが有効になっている GKE クラスタが必要です。

Console

1. Cloud Console で Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. 変更するクラスタの名前をクリックします。

3. [ネットワーキング] の [HTTP 負荷分散] フィールドで、[ HTTP 負荷分散の編集] をクリックします。

4. [HTTP 負荷分散を有効にする] チェックボックスをオンにします。

5. [変更を保存] をクリックします。

gcloud

gcloud container clusters update cluster-name --update-addons=HttpLoadBalancing=ENABLED

cluster-name はクラスタの名前です。

複数のバックエンド サービス

外部 HTTP(S) ロードバランサは、さまざまなバックエンド サービスにリクエストをルーティングするために使用できる、安定した IP アドレスを 1 つ提供します。

この演習では、URL パスに応じてリクエストを異なるバックエンド サービスに転送するように外部 HTTP(S) ロードバランサを構成します。パスが / のリクエストとパスが /kube のリクエストを、それぞれ別のバックエンド サービスにルーティングします。

この演習の全体を通した手順は次のとおりです。

1. Deployment を作成し、hello-world という名前の Service で公開します。
2. 2 番目の Deployment を作成し、hello-kubernetes という名前の Service で公開します。
3. リクエストの URL パスに応じて、いずれかの Service にリクエストをルーティングするためのルールを指定する Ingress を作成します。Ingress を作成すると、GKE Ingress コントローラが外部 HTTP(S) ロードバランサを作成して構成します。
4. 外部 HTTP(S) ロードバランサをテストします。

Deployment の作成

最初の Deployment のマニフェストは次のとおりです。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world-deployment
spec:
  selector:
    matchLabels:
      greeting: hello
      department: world
  replicas: 3
  template:
    metadata:
      labels:
        greeting: hello
        department: world
    spec:
      containers:
      - name: hello
        image: "gcr.io/google-samples/hello-app:2.0"
        env:
        - name: "PORT"
          value: "50000"

このマニフェストを hello-world-deployment.yaml という名前のファイルにコピーして Deployment を作成します。

kubectl apply -f hello-world-deployment.yaml

Service の作成

最初の Deployment を公開する Service のマニフェストは次のとおりです。

apiVersion: v1
kind: Service
metadata:
  name: hello-world
spec:
  type: NodePort
  selector:
    greeting: hello
    department: world
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000

この演習を進めるにあたって、この Service について次のことを理解しておくことが重要です。

• greeting: hello ラベルと department: world ラベルの両方を持つすべての Pod はこの Service のメンバーです。

• リクエストが TCP ポート 60000 でこの Service に送信されると、そのリクエストは TCP ポート 50000 でメンバーポッドの 1 つに転送されます。

マニフェストを hello-world-service.yaml という名前のファイルにコピーして、Service を作成します。

kubectl apply -f hello-world-service.yaml

2 番目の Deployment の作成

2 番目の Deployment のマニフェストは次のとおりです。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-kubernetes-deployment
spec:
  selector:
    matchLabels:
      greeting: hello
      department: kubernetes
  replicas: 3
  template:
    metadata:
      labels:
        greeting: hello
        department: kubernetes
    spec:
      containers:
      - name: hello-again
        image: "gcr.io/google-samples/node-hello:1.0"
        env:
        - name: "PORT"
          value: "8080"

このマニフェストを hello-kubernetes-deployment.yaml という名前のファイルにコピーして Deployment を作成します。

kubectl apply -f hello-kubernetes-deployment.yaml

2 番目の Service の作成

2 番目の Deployment を公開する Service のマニフェストは次のとおりです。

apiVersion: v1
kind: Service
metadata:
  name: hello-kubernetes
spec:
  type: NodePort
  selector:
    greeting: hello
    department: kubernetes
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

この演習を進めるにあたって、この Service について次のことを理解しておくことが重要です。

• greeting: hello ラベルと department: kubernetes ラベルの両方を持つすべての Pod はこの Service のメンバーです。

• リクエストが TCP ポート 80 でこの Service に送信されると、そのリクエストは TCP ポート 8080 でメンバーポッドの 1 つに転送されます。

マニフェストを hello-kubernetes-service.yaml という名前のファイルにコピーして、Service を作成します。

kubectl apply -f hello-kubernetes-service.yaml

Ingress の作成

Ingress のマニフェストを次に示します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    # If the class annotation is not specified it defaults to "gce".
    kubernetes.io/ingress.class: "gce"
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: hello-world
            port:
              number: 60000
      - path: /kube
        pathType: ImplementationSpecific
        backend:
          service:
            name: hello-kubernetes
            port:
              number: 80

この演習を進めるにあたって、この Ingress マニフェストについて次のことを理解しておくことが重要です。

• GKE Ingress には 2 つの Ingress クラスがあります。gce クラスは外部ロードバランサをデプロイし、gce-internal クラスは内部ロードバランサをデプロイします。クラスが指定されていない Ingress リソースのデフォルトは gce です。

• Ingress の path フィールドでサポートされているワイルドカード文字は「*」のみです。「*」はスラッシュ（「/」）の直後に置く必要があり、パターンの最後の文字でなければなりません。たとえば、/*、/foo/*、/foo/bar/* は有効なパターンですが、*、/foo/bar*、/foo/*/bar は有効ではありません。

  より具体的なパターンのほうが、そうでないものよりも優先されます。/foo/* と /foo/bar/* の両方を使用すると、/foo/bar/bat が /foo/bar/* と比較されます。パスの制限とパターン マッチングの詳細については、URL マップのドキュメントをご覧ください。

• Ingress マニフェストには、（serviceName、servicePort）のペアが 2 つあります。Ingress がターゲットにしているそれぞれの（serviceName、servicePort）は、Google Cloud バックエンド サービス リソースに関連付けられます。

• pathType フィールドでサポートされているパスタイプは ImplementationSpecific だけです。

このマニフェストを my-ingress.yaml という名前のファイルにコピーし、次のようにして Ingress を作成します。

kubectl apply -f my-ingress.yaml

Ingress を作成すると、GKE Ingress コントローラによって外部 HTTP(S) ロードバランサが作成され、そのロードバランサが次のように構成されます。

• クライアントが URL パス / を使用してロードバランサにリクエストを送信すると、そのリクエストはポート 60000 で hello-world Service に転送されます。

• クライアントが URL パス /kube を使用してロードバランサにリクエストを送信すると、そのリクエストはポート 80 で hello-kubernetes に転送されます。

ロードバランサが構成されるまで約 5 分待ちます。

外部 HTTP(S) ロードバランサのテスト

外部 HTTP(S) ロードバランサをテストするには、次のようにします。

1. Ingress を確認します。

   kubectl get ingress my-ingress --output yaml
   

   外部 HTTP(S) ロードバランサの IP アドレスが、出力に表示されます。

   status:
     loadBalancer:
       ingress:
       - ip: 203.0.113.1
   

2. / パスをテストします。

   curl load-balancer-ip/
   

   load-balancer-ip は、ロードバランサの外部 IP アドレスに置き換えます。

   出力には、Hello, world! メッセージが表示されます。

   Hello, world!
   Version: 2.0.0
   Hostname: ...
   

3. /kube パスをテストします。

   curl load-balancer-ip/kube
   

   出力には、Hello Kubernetes! メッセージが表示されます。

   Hello Kubernetes!
   

クライアントとロードバランサ間の HTTPS

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

• クライアントとロードバランサ間の HTTPS（TLS）の設定
• Ingress での HTTPS 負荷分散のための複数の SSL 証明書の使用。

HTTP の無効化

クライアントとロードバランサ間のすべてのトラフィックで HTTPS を使用する場合は、HTTP を無効にできます。詳しくは、HTTP の無効化をご覧ください。

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

GKE Pod で実行しているアプリケーションが HTTPS リクエストを受信できる場合は、ロードバランサがリクエストをアプリケーションに転送するときに HTTPS を使用するようにロードバランサを構成できます。詳しくは、ロードバランサとアプリケーション間の HTTPS（TLS）をご覧ください。

クライアントとロードバランサ間の HTTP/2

クライアントは HTTP/2 を使用してロードバランサにリクエストを送信できます。構成は不要です。

ロードバランサとアプリケーション間の HTTP/2

GKE Pod で実行しているアプリケーションが HTTP/2 リクエストを受信できる場合は、ロードバランサがリクエストをアプリケーションに転送するときに HTTP/2 を使用するようにロードバランサを構成できます。詳しくは、Ingress での HTTP/2 を使用した負荷分散をご覧ください。

ネットワーク エンドポイント グループ

クラスタがコンテナネイティブの負荷分散をサポートしている場合は、ネットワーク エンドポイント グループ（NEG）を使用することをおすすめします。GKE クラスタ 1.17 以降と一定の条件下では、コンテナネイティブの負荷分散がデフォルトであり、明示的な cloud.google.com/neg: '{"ingress": true}' Service のアノテーションは必要ありません。

外部 Ingress アノテーションの概要

Ingress アノテーション

アノテーション	説明
kubernetes.io/ingress.allow-http	クライアントと HTTP(S) ロードバランサ間の HTTP トラフィックを許可するかどうかを指定します。有効な値は true と false です。デフォルトは "true" です。HTTP の無効化をご覧ください。
ingress.gcp.kubernetes.io/pre-shared-cert	証明書と鍵を Google Cloud プロジェクトにアップロードできます。このアノテーションを使用して証明書と鍵を参照します。HTTP(S) ロードバランサのための複数の SSL 証明書の使用をご覧ください。
kubernetes.io/ingress.global-static-ip-name	このアノテーションを使用して、以前に作成した静的外部 IP アドレスをロードバランサが使用するように指定します。HTTP(S) ロードバランサの静的 IP アドレスをご覧ください。
networking.gke.io/v1beta1.FrontendConfig	このアノテーションを使用して、ロードバランサのクライアント向け構成をカスタマイズします。詳細については、Ingress の機能をご覧ください。

Ingress に関連する Service アノテーション

アノテーション	説明
service.alpha.kubernetes.io/app-protocols	このアノテーションを使用して、ロードバランサとアプリケーション間の通信用のプロトコルを設定します。有効なプロトコルは HTTP、HTTPS、HTTP/2 です。ロードバランサとアプリケーション間の HTTPS と Ingress による HTTP/2 を使用したロードバランサをご覧ください。
beta.cloud.google.com/backend-config	このアノテーションを使用して、servicePort に関連付けられるバックエンド サービスを構成します。詳細については、Ingress の機能をご覧ください。
cloud.google.com/neg	このアノテーションを使用して、ロードバランサがネットワーク エンドポイント グループを使用するように指定します。コンテナ ネイティブのロードバランサの使用をご覧ください。

次のステップ

• GKE での HTTP(S) ロードバランサの Ingress のコンセプトを確認する。

• Ingress での HTTP ロードバランサの設定のチュートリアルを確認する。

• GKE における Service のコンセプトの概要を確認する。