このページでは、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 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
プロジェクトに、HTTP(S) 負荷分散アドオンが有効になっている GKE クラスタが必要です。
Console
Cloud Console で Google Kubernetes Engine のメニューに移動します。
変更するクラスタの名前をクリックします。
[ネットワーキング] の [HTTP 負荷分散] フィールドで、[edit 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 のコンセプトの概要を確認する。