このページでは、Google Kubernetes Engine（GKE）でコンテナ ネイティブのロード バランシングを使用する方法について説明します。コンテナ ネイティブのロード バランシングにより、ロードバランサは Kubernetes Pod を直接ターゲットにして、トラフィックを Pod に均等に分配できます。
コンテナ ネイティブのロード バランシングのメリット、要件、制限事項の詳細については、コンテナ ネイティブのロード バランシングをご覧ください。
始める前に
作業を始める前に、次のタスクが完了していることを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API を有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。gcloud CLI をインストール済みの場合は、
gcloud components updateコマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
- すでに VPC ネイティブ クラスタが存在していることを確認する。必要な場合は、クラスタを作成します。GKE クラスタはデフォルトで VPC ネイティブです。
コンテナ ネイティブのロード バランシングを使用する
以下のセクションでは、GKE でのコンテナ ネイティブのロード バランシングの構成について説明します。
Deployment を作成する
次の Deployment のサンプル（neg-demo-app）では、コンテナ化された HTTP サーバーの単一インスタンスが実行されます。Pod の readiness フィードバックを使用するワークロードを使用することをおすすめします。
Pod の readiness フィードバックを使用する
apiVersion: apps/v1 kind: Deployment metadata: labels: run: neg-demo-app # Label for the Deployment name: neg-demo-app # Name of Deployment spec: selector: matchLabels: run: neg-demo-app template: # Pod template metadata: labels: run: neg-demo-app # Labels Pods from this Deployment spec: # Pod specification; each Pod created by this Deployment has this specification containers: - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods name: hostname # Container name ports: - containerPort: 9376 protocol: TCP
ハードコードされた遅延を使用する
apiVersion: apps/v1 kind: Deployment metadata: labels: run: neg-demo-app # Label for the Deployment name: neg-demo-app # Name of Deployment spec: minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready selector: matchLabels: run: neg-demo-app template: # Pod template metadata: labels: run: neg-demo-app # Labels Pods from this Deployment spec: # Pod specification; each Pod created by this Deployment has this specification containers: - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods name: hostname # Container name # Note: The following line is necessary only on clusters running GKE v1.11 and lower. # For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/container-native-load-balancing#align_rollouts ports: - containerPort: 9376 protocol: TCP terminationGracePeriodSeconds: 60 # Number of seconds to wait for connections to terminate before shutting down Pods
この Deployment では、各コンテナで HTTP サーバーが実行されます。HTTP サーバーは、アプリケーション サーバーのホスト名（サーバーが実行されている Pod の名前）をレスポンスとして返します。
このマニフェストを neg-demo-app.yaml として保存し、Deployment を作成します。
kubectl apply -f neg-demo-app.yaml
コンテナ ネイティブのロードバランサに Service を作成する
Deployment を作成したら、Pod を Service にグループ化する必要があります。
次のサンプルの Service neg-demo-svc は、前のセクションで作成したサンプルの Deployment をターゲットにしています。
apiVersion: v1
kind: Service
metadata:
name: neg-demo-svc # Name of Service
spec: # Service's specification
type: ClusterIP
selector:
run: neg-demo-app # Selects Pods labelled run: neg-demo-app
ports:
- name: http
port: 80 # Service's port
protocol: TCP
targetPort: 9376
ロードバランサは Service の Ingress を作成するまで作成されません。
このマニフェストを neg-demo-svc.yaml として保存し、Service を作成します。
kubectl apply -f neg-demo-svc.yaml
Service の Ingress を作成する
次の Ingress のサンプル（neg-demo-ing）では、作成した Service をターゲットとしています。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: neg-demo-ing
spec:
defaultBackend:
service:
name: neg-demo-svc # Name of the Service targeted by the Ingress
port:
number: 80 # Should match the port used by the Service
このマニフェストを neg-demo-ing.yaml として保存し、Ingress を作成します。
kubectl apply -f neg-demo-ing.yaml
Ingress を作成すると、プロジェクト内にアプリケーション ロードバランサが作成され、クラスタが実行される各ゾーンにネットワーク エンドポイント グループ（NEG）が作成されます。NEG 内のエンドポイントと Service のエンドポイントは同期の状態が維持されます。
Ingress を確認する
ワークロードをデプロイし、Pod を Service にグループ化して Service の Ingress を作成したら、Ingress によってコンテナ ネイティブのロードバランサが正常にプロビジョニングされていることを確認します。
Ingress のステータスを取得します。
kubectl describe ingress neg-demo-ing
出力には、ADD イベントと CREATE イベントが含まれます。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ADD 16m loadbalancer-controller default/neg-demo-ing
Normal Service 4s loadbalancer-controller default backend set to neg-demo-svc:32524
Normal CREATE 2s loadbalancer-controller ip: 192.0.2.0
ロードバランサをテストする
以降のセクションでは、コンテナ ネイティブのロードバランサの機能をテストする方法について説明します。
Ingress の IP アドレスにアクセスする
アプリケーション ロードバランサが構成されるまで数分待ちます。
Ingress の IP アドレスにアクセスすることで、コンテナ ネイティブのロードバランサが機能していることを確認できます。
Ingress の IP アドレスを取得するには、次のコマンドを実行します。
kubectl get ingress neg-demo-ing
コマンド出力の ADDRESS 列に、Ingress の IP アドレスが表示されます。この IP アドレスに、ウェブブラウザでアクセスします。
バックエンド サービスのヘルス ステータスをチェックする
ロードバランサのバックエンド サービスのヘルス ステータスを取得することもできます。
プロジェクトで実行されているバックエンド サービスのリストを取得します。
gcloud compute backend-services listService の名前を含むバックエンド サービスの名前（
neg-demo-svcなど）を記録します。バックエンド サービスの稼働状況を取得します。
gcloud compute backend-services get-health BACKEND_SERVICE_NAME --globalBACKEND_SERVICE_NAMEは、バックエンド サービスの名前に置き換えます。
Ingress をテストする
ロードバランサが期待どおりに機能しているかどうかをテストするもう 1 つの方法は、サンプルの Deployment をスケーリングし、テスト リクエストを Ingress に送信して、正しい数のレプリカが応答するかどうかを確認することです。
neg-demo-appDeployment を 1 つのインスタンスから 2 つのインスタンスにスケーリングします。kubectl scale deployment neg-demo-app --replicas 2このコマンドの完了までに数分かかることがあります。
ロールアウトが完了したことを確認します。
kubectl get deployment neg-demo-app出力には、使用可能な 2 つのレプリカが含まれます。
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE neg-demo-app 2 2 2 2 26mIngress の IP アドレスを取得します。
kubectl describe ingress neg-demo-ingこのコマンドで 404 エラーが返された場合は、ロードバランサが起動するまで数分待ってからもう一度お試しください。
ロードバランサからの個別のレスポンスの数をカウントします。
for i in `seq 1 100`; do \ curl --connect-timeout 1 -s IP_ADDRESS && echo; \ done | sort | uniq -cIP_ADDRESSは、Ingress の IP アドレスに置き換えます。出力は次のようになります。
44 neg-demo-app-7f7dfd7bc6-dcn95 56 neg-demo-app-7f7dfd7bc6-jrmzfこの出力では、個別のレスポンスの数はレプリカの数と同じです。これは、すべてのバックエンド Pod がトラフィックを処理していることを示しています。
クリーンアップ
このページのタスクを完了したら、アカウントで不要な請求が発生しないように、以下の手順でリソースを削除します。
クラスタの削除
gcloud
gcloud container clusters delete neg-demo-cluster
コンソール
Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
neg-demo-cluster を選択し、delete [削除] をクリックします。
確認のメッセージが表示されたら、[削除] をクリックします。
次のステップ
- スタンドアロン ゾーン NEG によるコンテナ ネイティブのロード バランシングを使用する方法を学習する。
- VPC ネイティブ クラスタの詳細を確認する。
- Ingress の構成の詳細を確認する。
- Google マネージド SSL 証明書を使用する方法を学習する。