外部負荷分散向け Ingress の設定

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

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

始める前に

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

次のいずれかの方法で 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 ゾーンを選択します。

gcloud config の使用

  • デフォルトのプロジェクト ID を設定します。
    gcloud config set project project-id
  • ゾーンクラスタを使用する場合は、デフォルトのコンピューティング ゾーンを設定します。
    gcloud config set compute/zone compute-zone
  • リージョン クラスタを使用する場合は、デフォルトのコンピューティング リージョンを設定します。
    gcloud config set compute/region compute-region
  • gcloud を最新バージョンに更新します。
    gcloud components update

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

Console

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. 有効にするクラスタを選択します。

  3. アイコンをクリックします。

  4. [アドオン] をクリックします。

  5. [HTTP 負荷分散] で [有効] を選択します。

  6. [保存] をクリックしてクラスタを更新します。

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 から別の 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

サービスの作成

最初の 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 ラベルの両方を持つすべてのポッドはこの 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 番目のサービスを作成する

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 ラベルの両方を持つすべてのポッドはこの 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/v1beta1
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: /*
        backend:
          serviceName: hello-world
          servicePort: 60000
      - path: /kube
        backend:
          serviceName: hello-kubernetes
          servicePort: 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 マニフェストには、(serviceNameservicePort)の組が 2 つあります。Ingress がターゲットにしているそれぞれの(serviceNameservicePort)は、Google Cloud バックエンド サービス リソースに関連付けられます。

このマニフェストを 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 を完了するための秘密鍵も必要です。詳細情報

HTTP の無効化

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

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

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

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

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

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

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

次のステップ