外部負荷分散向け 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 を受信した場合は、このセクションの内容を実施します。

gcloud init を実行して、次の操作を行います。
```
gcloud init
```
リモートサーバーで SSH を使用している場合は、--console-only フラグを指定して、コマンドがブラウザを起動しないようにします。
```
gcloud init --console-only
```
手順に従って gcloud を承認し、Google Cloud アカウントを使用します。
新しい構成を作成するか、既存の構成を選択します。
Google Cloud プロジェクトを選択します。
ゾーンクラスタの場合はデフォルトの 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

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

Google Kubernetes Engine のメニューに移動
変更するクラスタの名前をクリックします。
[ネットワーキング] の [HTTP 負荷分散] フィールドで、[ HTTP 負荷分散の編集] をクリックします。
[HTTP 負荷分散を有効にする] チェックボックスをオンにします。
[変更を保存] をクリックします。

gcloud

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

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

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

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

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

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

Deployment を作成し、hello-world という名前の Service で公開します。
2 番目の Deployment を作成し、hello-kubernetes という名前の Service で公開します。
リクエストの URL パスに応じて、いずれかの Service にリクエストをルーティングするためのルールを指定する Ingress を作成します。Ingress を作成すると、GKE Ingress コントローラが外部 HTTP(S) ロードバランサを作成して構成します。
外部 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/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 マニフェストには、（serviceName、servicePort）のペアが 2 つあります。Ingress がターゲットにしているそれぞれの（serviceName、servicePort）は、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) ロードバランサをテストするには、次のようにします。

Ingress を確認します。
```
kubectl get ingress my-ingress --output yaml
```
外部 HTTP(S) ロードバランサの IP アドレスが、出力に表示されます。
```
status:
  loadBalancer:
    ingress:
    - ip: 203.0.113.1
```
/ パスをテストします。
```
curl load-balancer-ip/
```
load-balancer-ip は、ロードバランサの外部 IP アドレスに置き換えます。

出力には、Hello, world! メッセージが表示されます。
```
Hello, world!
Version: 2.0.0
Hostname: ...
```
/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 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 のコンセプトの概要を確認する。

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

始める前に

gcloud init の使用

gcloud config の使用

Console

gcloud

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

Deployment の作成

Service の作成

2 番目の Deployment の作成

2 番目の Service の作成

Ingress の作成

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

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

HTTP の無効化

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

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

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

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

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

Ingress アノテーション

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

次のステップ

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

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