Ingress による負荷分散の構成

Ingress による負荷分散の構成

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

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

始める前に

このタスクの準備として、次の手順を行います。

Google Kubernetes Engine API が有効になっていることを確認します。

Google Kubernetes Engine API の有効化

Cloud SDK がインストール済みであることを確認します。
デフォルトのプロジェクト 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
```

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

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

HTTP(S) ロードバランサにより、リクエストをさまざまなバックエンドサービスにルーティングする際にも、単一の固定 IP アドレスを使用できます。

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

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

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

最初の 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 のマニフェストは次のとおりです。

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 という名前のファイルにコピーして Deployment を作成します。

kubectl apply -f hello-kubernetes-deployment.yaml

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 のマニフェストを次に示します。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: hello-world
          servicePort: 60000
      - path: /kube
        backend:
          serviceName: hello-kubernetes
          servicePort: 80

Ingress マニフェストには 2 つの（serviceName、servicePort）ペアがあることに注意してください。それぞれの（serviceName、servicePort）は GCP バックエンドサービスに関連付けられています。

マニフェストを 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 Service に転送されます。

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

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

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

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

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

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

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

クラスタがコンテナネイティブの負荷分散をサポートしている場合は、ネットワークエンドポイントグループを使用するようにロードバランサを構成できます。詳しくは、コンテナネイティブの負荷分散を使用するをご覧ください。

Ingress アノテーションの概要

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

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

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

次のステップ

GKE における Ingress のコンセプトの概要をご覧ください。
Ingress での HTTP 負荷分散の設定のチュートリアルをご覧ください。
BackendConfig カスタムリソースについて学習してください。
GKE における Service のコンセプトの概要をご覧ください。

このページは役立ちましたか？評価をお願いいたします。

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

最終更新日: 10月 24, 2019

始める前に

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

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

HTTP の無効化

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

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

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

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

Ingress アノテーションの概要

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

次のステップ

フィードバックを送信...

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

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