概要

このラボでは、Pod の Deployment を 2 つ作成し、Ingress リソースを含む 3 種類の Service を操作します。また、GKE 内の Kubernetes Service に Google Cloud ネットワーク ロードバランサを関連付ける方法を学習します。

目標

このラボでは、次のタスクの実行方法について学びます。

• Kubernetes DNS の動作を確認する。
• マニフェストでさまざまなタイプの Service（ClusterIP、NodePort、LoadBalancer）と、既存のラベル付き Pod と Deployment に接続するラベルセレクタを定義し、それらをクラスタにデプロイして接続テストを行う。
• 入力された URL パスに基づいてクライアントを 2 つの異なる Service に接続する Ingress リソースをデプロイする。
• LoadBalancer タイプの Service 用の Google Cloud ネットワーク ロードバランサが正しく作成されることを確認する。

ラボの設定

Qwiklabs にアクセスする

各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。

1. Qwiklabs にシークレット ウィンドウでログインします。

2. ラボのアクセス時間（例: 1:15:00）に注意し、時間内に完了できるようにしてください。
   一時停止機能はありません。必要な場合はやり直せますが、最初からになります。

3. 準備ができたら、[ラボを開始] をクリックします。

4. ラボの認証情報（ユーザー名とパスワード）をメモしておきます。この情報は、Google Cloud Console にログインする際に使用します。

5. [Google Console を開く] をクリックします。

6. [別のアカウントを使用] をクリックし、このラボの認証情報をコピーしてプロンプトに貼り付けます。
   他の認証情報を使用すると、エラーが発生したり、料金の請求が発生したりします。

7. 利用規約に同意し、再設定用のリソースページをスキップします。

最初のログイン手順を完了すると、プロジェクト ダッシュボードが表示されます。

Cloud Shell を開く

このラボのほとんどの作業は Cloud Shell で行います。

1. Google Cloud コンソールのタイトルバーで、[Cloud Shell をアクティブにする]（）をクリックします。
2. [続行] をクリックします。

プロビジョニングされると、Cloud Shell プロンプトが表示されます。

タスク 1. ラボの GKE クラスタに接続して DNS をテストする

このタスクでは、ラボの GKE クラスタに接続し、クラスタ内の Pod セット用の Deployment マニフェストを作成した後、マニフェストを使って Pod 名と Service 名の DNS 解決をテストします。

ラボの GKE クラスタに接続する

1. Cloud Shell で次のコマンドを入力して、Google Cloud ゾーンとクラスタ名の環境変数を作成します。これらの環境変数は、このラボ用のクラスタを作成するために使われます。

export my_zone={{{project_0.default_zone | ZONE}}} export my_cluster=standard-cluster-1

2. kubectl コマンドライン ツールのタブ補完を構成します。

source <(kubectl completion bash)

3. kubectl がクラスタにアクセスできるよう構成します。

gcloud container clusters get-credentials $my_cluster --zone $my_zone

タスク 2. Pod と Service を作成して DNS 解決をテストする

dns-demo-1 と dns-demo-2 という 2 つのサンプル アプリケーション Pod を持つ dns-demo という Service を作成します。

ソースファイルのリポジトリのクローンを作成し、サンプル アプリケーション ポッドをデプロイする

Kubernetes Service を介したネットワーク接続のテストに使用する Pod は、ソース リポジトリに用意されている dns-demo.yaml マニフェスト ファイルを使ってデプロイされます。後でこれらの Pod を使用して、Kubernetes クラスタ内のシステムからさまざまな Service を経由する接続をテストします。

また、Cloud Shell を使用して、外部アドレスからの接続もテストします。Cloud Shell でこれを行えるのは、Cloud Shell が Kubernetes クラスタ ネットワークから完全に分離したネットワーク上にあるためです。

apiVersion: v1 kind: Service metadata: name: dns-demo spec: selector: name: dns-demo clusterIP: None ports: - name: dns-demo port: 1234 targetPort: 1234 --- apiVersion: v1 kind: Pod metadata: name: dns-demo-1 labels: name: dns-demo spec: hostname: dns-demo-1 subdomain: dns-demo containers: - name: nginx image: nginx --- apiVersion: v1 kind: Pod metadata: name: dns-demo-2 labels: name: dns-demo spec: hostname: dns-demo-2 subdomain: dns-demo containers: - name: nginx image: nginx

1. Cloud Shell に次のコマンドを入力して、ラボの Cloud Shell にリポジトリのクローンを作成します。

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

2. 作業ディレクトリへのショートカットとしてソフトリンクを作成します。

ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s

3. このラボのサンプル ファイルが入っているディレクトリに移動します。

cd ~/ak8s/GKE_Services/

4. Service と Pod を作成します。

kubectl apply -f dns-demo.yaml

5. Pod が実行されていることを確認します。

kubectl get pods

出力は次の例のようになります。

出力:

NAME READY STATUS RESTARTS AGE dns-demo-1 1/1 Running 0 8s dns-demo-2 1/1 Running 0 8s

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Pod と Service を作成して DNS 解決をテストする

6. クラスタの内部に入るには、dns-demo-1 で実行されている bash へのインタラクティブなセッションを開きます。

kubectl exec -it dns-demo-1 -- /bin/bash

これで、クラスタ内のコンテナに入りました。以降のコマンドはこのコンテキストから実行されます。後のタスクでここからさまざまなターゲットに ping してネットワーク接続をテストしますが、コンテナに ping ツールがまだ入っていないため、まず ping コマンドをインストールする必要があります。

7. 次のように apt-get を更新し、ping ツールをインストールします。

apt-get update apt-get install -y iputils-ping

8. dns-demo-2 に ping します。

ping dns-demo-2.dns-demo.default.svc.cluster.local

この ping が成功すると、ターゲットの IP アドレスが先ほど確認した dns-demo-2 Pod のアドレスであることが確認できます。

9. Ctrl+C キーを押して ping コマンドを中止します。
10. Service 内の特定の Pod ではなく、dns-demo Service の FQDN に ping します。

ping dns-demo.default.svc.cluster.local

この ping も成功しますが、2 つの demo-dns Pod のうち一方の FQDN からの応答が返されます。この Pod は、demo-dns-1 または demo-dns-2 のいずれかです。

11. Ctrl+C キーを押して ping コマンドを中止します。

アプリケーションをデプロイすると、アプリケーション コードはクラスタ内のコンテナで実行されるため、FQDN を使用して他の Service にアクセスできます。この方法は、IP アドレスや Pod 名を使用する方法よりシンプルです。IP アドレスや Pod 名は FQDN に比べて変更される可能性が高いためです。

12. dns-demo-1 上のインタラクティブ シェルは実行されたままにします。

タスク 3. サンプル ワークロードと ClusterIP Service をデプロイする

このタスクでは、クラスタ内の Pod セット用の Deployment マニフェストを作成し、ClusterIP Service を使用して公開します。

Kubernetes Engine クラスタにサンプル ウェブ アプリケーションをデプロイする

このタスクでは、hello-v1.yaml マニフェスト ファイル内にすでに作成されている次のマニフェストを使用して、ポート 8080 で HTTP サーバーをリッスンするサンプル ウェブ アプリケーションのコンテナ イメージをデプロイします。

apiVersion: apps/v1 kind: Deployment metadata: name: hello-v1 spec: replicas: 3 selector: matchLabels: run: hello-v1 template: metadata: labels: run: hello-v1 name: hello-v1 spec: containers: - image: gcr.io/google-samples/hello-app:1.0 name: hello-v1 ports: - containerPort: 8080 protocol: TCP

1. Cloud Shell のメニューバーでプラス記号（）をクリックして、新しい Cloud Shell セッションを開始します。

2 つ目の Cloud Shell セッションが Cloud Shell ウィンドウに表示されます。メニューバーでセッションをクリックすると、セッションが切り替わります。

2. 2 つ目の Cloud Shell タブで、このラボのサンプル ファイルが入っているディレクトリに移動します。

cd ~/ak8s/GKE_Services/

3. 次のコマンドを実行して、hello-v1.yaml ファイルから Deployment を作成します。

kubectl create -f hello-v1.yaml

4. 次のコマンドを実行して、Deployment のリストを表示します。

kubectl get deployments

出力は次の例のようになります。

出力:

NAME READY UP-TO-DATE AVAILABLE AGE hello-v1 3/3 3 3 14s

マニフェストでサービスのタイプを定義する

このタスクでは、すでに作成されている hello-svc.yaml サンプル マニフェストを使用して、ClusterIP タイプの Service をデプロイします。

apiVersion: v1 kind: Service metadata: name: hello-svc spec: type: ClusterIP selector: name: hello-v1 ports: - protocol: TCP port: 80 targetPort: 8080

1. 次のコマンドを実行して、ClusterIP Service をデプロイします。

kubectl apply -f ./hello-svc.yaml

このマニフェストでは ClusterIP Service を定義し、セレクタに対応する Pod に適用します。この場合、デプロイした hello-v1 Pod にマニフェストが適用されます。この Service は、name: hello-v1 というラベルが付いた他の Deployment に自動的に適用されます。

2. Service が作成され、Cluster-IP が割り当てられたことを確認します。

kubectl get service hello-svc

実際の IP アドレスは出力例とは異なる場合があります。

出力:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-svc ClusterIP 10.11.253.203 80/TCP 20s

この Service に外部 IP は割り当てられていません。Kubernetes クラスタの IP アドレスにはデフォルトでは外部からアクセスできないため、この Service を作成しても、クラスタの外部からはアプリケーションにアクセスできません。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 サンプル ワークロードと ClusterIP Service をデプロイする

アプリケーションをテストする

1. Cloud Shell で次のコマンドを使用して、新しい Service への HTTP セッションを開くよう試みます。

curl hello-svc.default.svc.cluster.local

この Service はクラスタの外部に公開されていないため、接続は失敗します。

出力:

curl: (6) Could not resolve host: hello-svc.default.svc.cluster.local

dns-demo-1 Pod 上で実行されているインタラクティブな shell を使用してクラスタ内から Service をテストします。

2. 1 つ目の Cloud Shell ウィンドウに戻ります。現在、このウィンドウは dns-demo-1 Pod の stdin と stdout に対応しています。
3. コマンドラインからウェブサービスを呼び出せるように、curl をインストールします。

apt-get install -y curl

4. 次のコマンドを使用して、Pod 間の HTTP 接続をテストします。

curl hello-svc.default.svc.cluster.local

この接続は成功し、以下の出力のような応答が返されます。実際のホスト名は出力例とは異なる場合があります。

出力:

root@dns-demo-1:/# curl hello-svc.default.svc.cluster.local Hello, world! Version: 1.0.0 Hostname: hello-v1-85b99869f-mp4vd root@dns-demo-1:/#

Kubernetes Engine クラスタの内部 DNS を使用して ClusterIP を解決できるため、正常に接続されます。

タスク 4. Service を変換して NodePort を使用する

このタスクでは、既存の ClusterIP Service を NodePort Service に変換し、クラスタの内部と外部から Service へのアクセスを再テストします。

Service のタイプを NodePort に変更する hello-nodeport-svc.yaml というファイル（hello-svc.yaml ファイルの変更バージョン）がすでに作成されています。

apiVersion: v1 kind: Service metadata: name: hello-svc spec: type: NodePort selector: name: hello-v1 ports: - protocol: TCP port: 80 targetPort: 8080 nodePort: 30100

1. 2 つ目の Cloud Shell ウィンドウに戻ります。このウィンドウは、dns-test Pod の stdin と stdout には接続されていません。
2. 次のコマンドを実行して、hello-svc の Service タイプを NodePort に変更するマニフェストをデプロイします。

kubectl apply -f ./hello-nodeport-svc.yaml

このマニフェストでは、hello-svc を NodePort Service として再定義し、その Service のクラスタの各ノードにポート 30100 を割り当てます。

3. 次のコマンドを入力して、Service のタイプが NodePort に変更されていることを確認します。

kubectl get service hello-svc

実際の IP アドレスは出力例とは異なる場合があります。

出力:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-svc NodePort 10.11.253.203 80:30100/TCP 59m 注: このサービス用に割り当てられた外部 IP はまだありません。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Service を変換して NodePort を使用する

アプリケーションをテストする

1. Cloud Shell で次のコマンドを使用して、新しい Service への HTTP セッションを開くよう試みます。

curl hello-svc.default.svc.cluster.local

この Service はクラスタの外部に公開されていないため、接続は失敗します。

出力:

curl: (6) Could not resolve host: hello-svc.default.svc.cluster.local

別の Pod から Service をテストします。

2. 1 つ目の Cloud Shell ウィンドウに戻ります。現在、このウィンドウは dns-test Pod の stdin と stdout に対応しています。
3. 次のコマンドを使用して、Pod 間の HTTP 接続をテストします。

curl hello-svc.default.svc.cluster.local

この接続は成功し、以下の出力のような応答が返されます。実際のホスト名は出力例とは異なる場合があります。

出力:

root@dns-demo-1:/# curl hello-svc.default.svc.cluster.local Hello, world! Version: 1.0.0 Hostname: hello-v1-85b99869f-mp4vd root@dns-demo-1:/#

GKE クラスタの内部 DNS を使用して ClusterIP を解決できるため、正常に接続されます。

タスク 5. Google Cloud ネットワーキングを使用して静的パブリック IP アドレスを作成する

Google Cloud ネットワーキングの静的 IP アドレスを予約する

1. Google Cloud コンソールのナビゲーション メニューで、[ネットワーキング] > [VPC ネットワーク] > [IP アドレス] の順に移動します。

2. [静的外部アドレスを予約] をクリックします。

3. [名前] には「regional-loadbalancer」と入力します。

4. その他のオプションを確認します。ただし、設定はデフォルトのままにします。デフォルトのタイプが [リージョン] であることに注意してください。

注: デフォルトのリージョンは、GKE クラスタをデプロイしたリージョンと同じである必要があります。そうでない場合は、クラスタの作成に使用したリージョンと同じになるようにここでリージョンを変更してください。ラボのデフォルトを受け入れた場合は、リージョンが になります。

5. [予約] をクリックします。

6. regional-loadbalancer という名前で予約した外部 IP アドレスをメモしておきます。後のタスクでこれを使用します。

7. [静的外部アドレスを予約] をクリックします。

8. [名前] に「global-ingress」と入力します。

9. [タイプ] を [グローバル] に変更します。

10. その他の設定はデフォルトのままにします。

11. [予約] をクリックします。

12. global-ingress という名前で予約した外部 IP アドレスをメモしておきます。後のタスクでこれを使用します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Google Cloud ネットワーキングを使用して静的パブリック IP アドレスを作成する

タスク 6. 新しい Pod セットと LoadBalancer Service をデプロイする

2 つの Service を簡単に区別できるように、違うバージョンのアプリケーションを実行する Pod セットをデプロイします。その後、新しい Pod を LoadBalancer Service として公開し、クラスタの外部から Service にアクセスします。

hello-v2.yaml という 2 つ目の Deployment マニフェストが作成されています。このマニフェストでは、ポート 8080 でサンプル hello アプリケーションのバージョン 2 を実行する新しい Deployment が作成されます。

apiVersion: apps/v1 kind: Deployment metadata: name: hello-v2 spec: replicas: 3 selector: matchLabels: run: hello-v2 template: metadata: labels: run: hello-v2 name: hello-v2 spec: containers: - image: gcr.io/google-samples/hello-app:2.0 name: hello-v2 ports: - containerPort: 8080 protocol: TCP

1. 2 つ目の Cloud Shell ウィンドウに戻ります。このウィンドウは、dns-test Pod の stdin と stdout には接続されていません。
2. 次のコマンドを実行して、hello-v2 Deployment を作成するマニフェストをデプロイします。

kubectl create -f hello-v2.yaml

3. 次のコマンドを実行して、Deployment のリストを表示します。

kubectl get deployments

出力は次の例のようになります。

出力:

NAME READY UP-TO-DATE AVAILABLE AGE hello-v1 3/3 3 3 18m hello-v2 3/3 3 3 7s

マニフェストでサービスのタイプを定義する

このタスクでは、すでに作成されている hello-lb-svc.yaml サンプル マニフェストを使用して、LoadBalancer Service をデプロイします。

sed コマンドを使用して、このロードバランサ yaml ファイル内のプレースホルダ アドレス 10.10.10.10 を、先ほどロードバランサ用に予約した静的アドレスに置き換えます。

apiVersion: v1 kind: Service metadata: name: hello-lb-svc spec: type: LoadBalancer loadBalancerIP: 10.10.10.10 selector: name: hello-v2 ports: - protocol: TCP port: 80 targetPort: 8080

1. 引き続き 2 つ目の Cloud Shell ウィンドウを使用していることを確認してください。このウィンドウは、dns-test Pod の stdin と stdout には接続されていません。

2. Cloud Shell に次のコマンドを入力し、先ほど作成したリージョン静的 IP アドレスを環境変数の中に保存します。

   export STATIC_LB=$(gcloud compute addresses describe regional-loadbalancer --region {{{project_0.default_region | REGION}}} --format json | jq -r '.address')

3. Cloud Shell に次のコマンドを入力し、プレースホルダ アドレスをリージョン静的 IP アドレスに置き換えます。

sed -i "s/10\.10\.10\.10/$STATIC_LB/g" hello-lb-svc.yaml

4. 外部 IP アドレスが正しく置き換えられたことを確認するには、Cloud Shell に次のコマンドを入力します。

cat hello-lb-svc.yaml

loadBalancerIP が、先ほど regional-loadbalancer という名前で静的 IP アドレスを予約したときにメモしたアドレスと一致するはずです。

5. 次のコマンドを実行して、LoadBalancer Service のマニフェストをデプロイします。

kubectl apply -f ./hello-lb-svc.yaml

このマニフェストによって定義される LoadBalancer Service は、Google Cloud ネットワーク ロードバランサをデプロイし、外部からのアクセスを可能にします。この Service は、name: hello-v2 セレクタを持つ Pod にのみ適用されます。

6. Service が作成されてノードポートが割り当てられたことを確認します。

kubectl get services

実際の IP アドレスは出力例とは異なる場合があります。

出力:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE dns-demo ClusterIP None 1234/TCP 1h hello-lb-svc LoadBalancer 10.11.253.48 35.184.45.240 80:30103/TCP 2m hello-svc NodePort 10.11.253.203 80:30100/TCP 1h kubernetes ClusterIP 10.11.240.1 443/TCP 2h

regional-loadbalancer という名前で予約したアドレスが、新しい LoadBalancer Service の外部 IP アドレスとして表示されることに注意してください。GKE 環境では、LoadBalancer Service 用の外部ロードバランサは Google Cloud ロードバランサを使用して実装され、作成に数分かかります。この外部 IP アドレスによって、クラスタの外部から Service にアクセスできるようになります。

Google Cloud リージョン ロードバランサが作成されたことを確認する

1. Google Cloud コンソールで、[ネットワーキング] > [ネットワーク サービス] > [負荷分散] の順に移動します。

1 つのターゲット プール バックエンドと 2 つのインスタンスを持つ TCP ロードバランサが表示されるはずです。

2. 名前をクリックして詳細ページを開きます。

これはリージョン TCP ロードバランサで、先ほど regional-loadbalancer という名前で予約した静的 IP アドレスを使用しているはずです。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 新しい Pod セットと LoadBalancer Service をデプロイする

アプリケーションをテストする

1. Cloud Shell で次のコマンドを使用して、新しい Service への HTTP セッションを開くよう試みます。

curl hello-lb-svc.default.svc.cluster.local

この Service 名はクラスタの外部に公開されていないため、接続は失敗します。

出力:

curl: (6) Could not resolve host: hello-lb-svc.default.svc.cluster.local

外部 IP アドレスがこのホスト名で登録されていないため、このような結果になります。

2. リージョン LoadBalancer Service に関連付けられている外部 IP アドレスを使って接続を再試行します。次のコマンドを実行します。[external_IP] は、Service の外部 IP アドレスに置き換えます。

curl [external_IP]

例:

curl 35.184.45.240

LoadBalancer の外部 IP アドレスには Google Cloud の外部からアクセスできるため、今回の接続は失敗しません。

注: LoadBalancer が使用可能になるまで最大で 5 分ほどかかることがあります。

出力:

Hello, world! Version: 2.0.0 Hostname: hello-v2-59c99d8b65-jrx2d

3. 1 つ目の Cloud Shell ウィンドウに戻ります。現在、このウィンドウは dns-demo-1 Pod の stdin と stdout に対応しています。
4. 次のコマンドを使用して、Pod 間の HTTP 接続をテストします。

curl hello-lb-svc.default.svc.cluster.local

この接続は成功し、以下の出力のような応答が返されます。実際のホスト名は出力例とは異なります。

出力:

root@dns-demo-1:/# curl hello-lb-svc.default.svc.cluster.local Hello, world! Version: 2.0.0 Hostname: hello-v2-59c99d8b65-78ggz root@dns-demo-1:/#

内部 DNS 名は Pod 内で使用できます。また、外部 IP アドレスを使用して、クラスタの外部から同じバージョン 2 のアプリケーションにアクセスしていることを確認できます。

5. Service に関連付けられた外部 IP アドレスを使用して、Pod 内でもう一度接続を試みます。次のコマンドを実行します。[external_IP] は、Service の外部 IP アドレスに置き換えます。

curl [external_IP]

例:

curl 35.184.45.240

出力:

root@dns-demo-1:/# curl 35.184.45.240 Hello, world! Version: 2.0.0 Hostname: hello-v2-59c99d8b65-jrx2d root@dns-demo-1:/#

外部 IP はクラスタ内で実行されている Pod の中からも使用可能で、同じバージョン 2 のアプリケーションから結果が返されます。

6. 「exit」と入力して、Pod にリダイレクトされたコンソールのセッションを閉じます。

exit

これで Cloud Shell のコマンド プロンプトに戻ります。

タスク 7. Ingress リソースをデプロイする

クラスタ内に hello アプリケーション用の 2 つの Service があります。1 つは NodePort Service を使用してバージョン 1.0 をホストしており、もう 1 つは LoadBalancer Service を使用してバージョン 2.0 をホストしています。ユーザーが入力した URL に基づいてトラフィックを両方の Service に転送する Ingress リソースをデプロイします。

Ingress リソースを作成する

Ingress は、外部 HTTP(S) トラフィックを内部 Service にルーティングするためのルールと構成の集合をカプセル化する Kubernetes リソースです。

GKE では、Ingress は Cloud Load Balancing を使用して実装されます。クラスタで Ingress リソースを作成すると、GKE では HTTP(S) ロードバランサが作成され、トラフィックをアプリケーションにルーティングするように構成されます。

Ingress リソースを構成する hello-ingress.yaml というサンプル マニフェストがあらかじめ作成されています。

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: hello-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / kubernetes.io/ingress.global-static-ip-name: "global-ingress" spec: rules: - http: paths: - path: /v1 pathType: ImplementationSpecific backend: service: name: hello-svc port: number: 80 - path: /v2 pathType: ImplementationSpecific backend: service: name: hello-lb-svc port: number: 80

この構成ファイルでは、先ほどのステップで作成した global-ingress 静的 IP アドレスに関連付けられる Ingress リソースが定義されます。この Ingress リソースによって作成されるグローバル HTTP(S) ロードバランサは、入力されたパスに基づいてトラフィックをウェブサービスに転送します。

アノテーション kubernetes.io/ingress.global-static-ip-name により、Ingress リソースが自身用の Google Cloud グローバル HTTP(S) ロードバランサの作成時に使用する予約済み IP アドレスの名前を指定できます。

• 次のコマンドを実行して、この Ingress リソースをデプロイします。

kubectl apply -f hello-ingress.yaml

このマニフェストをデプロイすると、Kubernetes によってクラスタに Ingress リソースが作成されます。また、クラスタで実行中の Ingress コントローラによって HTTP(S) ロードバランサが作成されます。このロードバランサにより、すべての外部 HTTP トラフィック（ポート 80）はウェブに公開済みの NodePort Service と LoadBalancer Service にルーティングされます。

グローバル HTTP(S) ロードバランサが作成されたことを確認する

1. Google Cloud コンソールで、[ネットワーキング] > [ネットワーク サービス] > [負荷分散] の順に移動します。今回は HTTP(S) ロードバランサも表示されるはずです。

2. 名前をクリックして詳細ページを開きます。これがグローバル HTTP(S) ロードバランサであること、また先ほど global-ingress という名前で予約した静的 IP アドレスを使用していることが示されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Ingress リソースをデプロイする

アプリケーションをテストする

1. 次のコマンドを実行して、アプリケーションに対応するロードバランサの外部 IP アドレスを取得します。

kubectl describe ingress hello-ingress

出力の一部:

Name: hello-ingress Namespace: default Address: 35.244.173.44 Default backend: default-http-backend:80 (10.8.2.5:8080) Rules: Host Path Backends ---- ---- -------- * /v1 hello-svc:80 () /v2 hello-lb-svc:80 () [...] ingress.kubernetes.io/backends:{"k8s-[...]"HEALTHY"[...]} [...] Events: Type Reason Age From Message ---- ------ --- ---- ------- Normal ADD 5m loadbalancer-controller default/hello-ingress Normal CREATE 5m loadbalancer-controller ip: 35.244.173.44 注: 外部アドレスが表示されるようになる前に、ロードバランサがアクティブになってヘルスチェックが成功するまで数分間待つ必要があります。

数分おきにコマンドを実行して、Ingress リソースの初期化が終了したかどうかを確認します。Google Cloud グローバル HTTP(S) ロードバランサの作成と初期化が完了していれば、外部 IP アドレスが表示されます。このアドレスは先ほど global-ingress という名前で予約したグローバル静的 IP アドレスと一致します。

2. Ingress リソースに関連付けられた外部 IP アドレスを使用して次のコマンドを入力します。[external_IP] は、Ingress リソースの外部 IP アドレスに置き換えます。URL パスに必ず /v1 を含めてください。

curl http://[external_IP]/v1

例:

curl http://35.201.92.69/v1

出力:

Hello, world! Version: 1.0.0 Hostname: hello-v1-85b99869f-4rmqw

hello-ingress.yaml の中で、バージョン 1 の URL は、バージョン 1 のアプリケーション Pod にトラフィックを転送する hello-svc NodePort Service を参照するように構成されます。

注: GKE が転送ルールを設定して Ingress リソース用のグローバル ロードバランサがアプリケーションにサービスを提供できるようになるまでに、数分かかることがあります。

その間、ロードバランサの構成が世界中に伝播されるまでは、HTTP 404 や HTTP 500 などのエラーが発生する可能性があります。

3. Cloud Shell からバージョン 2 の URL パスをテストします。Ingress リソースに関連付けられた外部 IP アドレスを使用して次のコマンドを入力します。[external_IP] は、Ingress リソースの外部 IP アドレスに置き換えます。URL パスに必ず /v2 を含めてください。

curl http://[external_IP]/v2

hello-ingress.yaml の中で、バージョン 2 の URL は、バージョン 2 アプリケーション Pod にトラフィックを転送する hello-lb-svc LoadBalancer Service を参照するように構成されます。

例:

curl http://35.201.92.69/v2

出力:

Hello, world! Version: 2.0.0 Hostname: hello-v2-59c99d8b65-jrx2d

Google Cloud コンソールでネットワーク リソースの変化を確認する

1. Google Cloud コンソールのナビゲーション メニューで、[ネットワーキング] > [ネットワーク サービス] > [負荷分散] の順にクリックします。

今回はロードバランサが 2 つ表示されます。

• 1 つは hello-lb-svc Service 用に最初に作成されたリージョン ロードバランサです。これは UID 形式の名前を持ち、TCP ポート 80 のトラフィックをクラスタノードに負荷分散するように構成されています。

• もう 1 つは Ingress オブジェクト用に作成されたもので、Ingress の構成と一致するホストとパスのルールが含まれる完全な HTTP(S) ロードバランサです。名前には hello-ingress が含まれます。

2. 名前に hello-ingress が含まれるロードバランサをクリックします。

Ingress リソース用に作成された Google Cloud グローバル HTTP(S) ロードバランサのプロトコル、ポート、パス、バックエンド サービスに関する要約情報が表示されます。

ラボを終了する

ラボが完了したら、[ラボを終了] をクリックします。ラボで使用したリソースが Google Cloud Skills Boost から削除され、アカウントの情報も消去されます。

ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信] をクリックします。

星の数は、それぞれ次の評価を表します。

• 星 1 つ = 非常に不満
• 星 2 つ = 不満
• 星 3 つ = どちらともいえない
• 星 4 つ = 満足
• 星 5 つ = 非常に満足

フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。

フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート] タブをご利用ください。

Copyright 2020 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。