概要

このラボでは、Google Kubernetes Engine（GKE）でアプリケーションを設定してから、HorizontalPodAutoscaler を使用してウェブ アプリケーションを自動スケーリングします。その後、タイプの異なる複数のノードプールを操作し、taint と toleration を適用して基盤となるノードプールで Pod のスケジュールを制御します。

目標

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

• 自動スケーリングと HorizontalPodAutoscaler を構成する
• ノードプールを追加し、Pod の反アフィニティを適用するためにノードに対して taint を構成する
• Pod のマニフェストに toleration を追加して、Node taint の例外を構成する

ラボの設定

Qwiklabs にアクセスする

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

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

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

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

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

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

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

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

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

Google Cloud Shell の有効化

Google Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。

Google Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールで、右上のツールバーにある [Cloud Shell をアクティブにする] ボタンをクリックします。

   

2. [続行] をクリックします。

環境がプロビジョニングされ、接続されるまでしばらく待ちます。接続した時点で認証が完了しており、プロジェクトに各自のプロジェクト ID が設定されます。次に例を示します。

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

• 次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

出力:

Credentialed accounts: - @.com (active)

出力例:

Credentialed accounts: - google1623327_student@qwiklabs.net

• 次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project =

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: gcloud ドキュメントの全文については、 gcloud CLI の概要ガイド をご覧ください。

タスク 1. ラボの GKE クラスタに接続してサンプルのワークロードをデプロイする

このタスクでは、ラボの GKE クラスタに接続し、クラスタ内の一連の Pod に関する Deployment マニフェストを作成します。

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

1. Cloud Shell で次のコマンドを入力して、ゾーンとクラスタ名の環境変数を設定します。

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

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

すでに作成されている web.yaml Deployment ファイルを使用して、サンプル アプリケーションをクラスタにデプロイします。

apiVersion: apps/v1 kind: Deployment metadata: name: web spec: replicas: 1 selector: matchLabels: run: web template: metadata: labels: run: web spec: containers: - image: gcr.io/google-samples/hello-app:1.0 name: web ports: - containerPort: 8080 protocol: TCP resources: # You must specify requests for CPU to autoscale # based on CPU utilization requests: cpu: "250m"

このマニフェストは、HTTP サーバーのポート 8080 でリッスンするサンプル ウェブ アプリケーション コンテナのイメージを使用して、Deployment を作成します。

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/Autoscaling/

4. 次のコマンドを実行して、このファイルから Deployment を作成します。

kubectl create -f web.yaml --save-config

5. web Deployment に対しポート 8080 を使用する、NodePort タイプの Service リソースを作成します。

kubectl expose deployment web --target-port=8080 --type=NodePort

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

kubectl get service web

実際の IP アドレスとポート番号は、以下の出力例とは異なる場合があります。

出力:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE web NodePort 10.11.246.185 8080:32056/TCP 12s

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 GKE クラスタにサンプル ウェブ アプリケーションをデプロイする

タスク 2. クラスタで自動スケーリングを構成する

このタスクでは、先ほどデプロイしたサンプル アプリケーションを自動スケーリングするようにクラスタを構成します。

自動スケーリングを構成する

1. Deployment のリストを取得して、サンプル ウェブ アプリケーションがまだ実行中かどうか確認します。

kubectl get deployment

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

出力:

NAME READY UP-TO-DATE AVAILABLE AGE web 1/1 1 1 5m48s

アプリケーションの web Deployment が表示されない場合は、タスク 1 に戻ってクラスタに再デプロイします。

2. 次のコマンドを実行して、サンプル アプリケーションを自動スケーリングするように構成します（最大レプリカ数を 4、最小レプリカ数を 1、CPU 使用率の目標を 1% に設定します）。

kubectl autoscale deployment web --max 4 --min 1 --cpu-percent 1

kubectl autoscale を使用するときは、アプリケーションの最大レプリカ数と最小レプリカ数、CPU 使用率の目標を指定します。

3. Deployment のリストを取得して、ウェブ アプリケーションの Deployment がまだ 1 つだけ存在することを確認します。

kubectl get deployment

出力:

NAME READY UP-TO-DATE AVAILABLE AGE web 1/1 1 1 8m21s

HorizontalPodAutoscaler オブジェクトを調べる

前のタスクで使用した kubectl autoscale コマンドによって、HorizontalPodAutoscaler オブジェクトが作成されます。このオブジェクトは、指定したリソース（スケール ターゲットと呼ばれます）を対象として、必要に応じてそのリソースをスケールします。

このオートスケーラーは、作成時に指定された平均 CPU 使用率と一致するように、スケール ターゲットのレプリカ数を定期的に調整します。

1. HorizontalPodAutoscaler リソースのリストを取得するには、次のコマンドを実行します。

kubectl get hpa

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

出力:

NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web 0%/1% 1 4 1 1m

2. HorizontalPodAutoscaler の構成を表形式で確認するには、次のコマンドを実行します。

kubectl describe horizontalpodautoscaler web

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

出力:

Name: web Namespace: default Labels: Annotations: CreationTimestamp: Tue, 08 Sep 2020... Reference: Deployment/web Metrics: ( current / target ) resource cpu on pods (as a percentage of request): 0% (0) / 1% Min replicas: 1 Max replicas: 4 Deployment pods: 1 current / 1 desired Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True ScaleDownStabilized recent recommendations [...] ScalingActive True ValidMetricFound the HPA was able to [...] ScalingLimited False DesiredWithinRange the desired count [...] Events:

3. HorizontalPodAutoscaler の構成を YAML 形式で表示するには、次のコマンドを実行します。

kubectl get horizontalpodautoscaler web -o yaml

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

出力:

apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: annotations: autoscaling.alpha.kubernetes.io/conditions: [...] autoscaling.alpha.kubernetes.io/current-metrics: [...] creationTimestamp: 2018-11-14T02:59:28Z name: web namespace: default resourceVersion: "14588" selfLink: /apis/autoscaling/v1/namespaces/[...] spec: maxReplicas: 4 minReplicas: 1 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web targetCPUUtilizationPercentage: 1 status: currentCPUUtilizationPercentage: 0 currentReplicas: 1 desiredReplicas: 1

自動スケーリングの構成をテストする

ウェブ アプリケーションが強制的にスケールアウトするように、アプリケーションに対して大きな負荷をかける必要があります。そこで、4 つのコンテナからなる Deployment を定義する構成ファイルを作成します。これらのコンテナは、サンプルのアプリケーション ウェブサーバーに対して HTTP クエリの無限ループを実行します。

ウェブ アプリケーションに負荷をかけるために、用意されている loadgen.yaml ファイルを使用して loadgen アプリケーションをデプロイします。

apiVersion: apps/v1 kind: Deployment metadata: name: loadgen spec: replicas: 4 selector: matchLabels: app: loadgen template: metadata: labels: app: loadgen spec: containers: - name: loadgen image: k8s.gcr.io/busybox args: - /bin/sh - -c - while true; do wget -q -O- http://web:8080; done

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

kubectl apply -f loadgen.yaml

このマニフェストをデプロイすると、web Pod のスケールが開始されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 loadgen アプリケーションをデプロイする

2. Deployment のリストを取得して、負荷生成ツールが実行中であることを確認します。

kubectl get deployment

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

出力:

NAME READY UP-TO-DATE AVAILABLE AGE loadgen 4/4 4 4 26s web 1/1 1 1 14m

3. HorizontalPodAutoscaler を調べます。

kubectl get hpa

loadgen Pod がトラフィックの生成を開始すると、web Deployment の CPU 使用率が上昇し始めます。以下の出力例では、CPU しきい値が 1% であるのに対して、CPU 使用率の目標は 35% になっています。

出力:

NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web 35%/1% 1 4 1 8m

4. 数分後に、もう一度 HorizontalPodAutoscaler を調べます。

kubectl get hpa

オートスケーラーによって web Deployment のレプリカが 4 つに増えました。

出力:

NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web 88%/1% 1 4 4 9m

5. ウェブ アプリケーションに対する負荷を停止するには、loadgen Deployment のレプリカ数を 0 にスケールダウンします。

kubectl scale deployment loadgen --replicas 0

6. Deployment のリストを取得して、loadgen がスケールダウンされたことを確認します。

kubectl get deployment

loadgen Deployment のレプリカ数は 0 になっています。

出力:

NAME READY UP-TO-DATE AVAILABLE AGE loadgen 0/0 0 0 3m40s web 2/4 4 2 18m 注: Deployment のリストをもう一度表示するには、2～3 分待つ必要があります。

7. Deployment のリストを取得して、ウェブ アプリケーションがスケールダウンされてレプリカ数が 1（オートスケーラーをデプロイしたときに構成したレプリカの最小値）になっていることを確認します。

kubectl get deployment

これで、ウェブ アプリケーションの Deployment は 1 つになりました。

出力:

NAME READY UP-TO-DATE AVAILABLE AGE loadgen 0/0 0 0 12m web 1/1 1 1 14m

タスク 3. ノードプールを管理する

このタスクでは、プリエンプティブル インスタンスを使用して新しいノードプールを作成します。その後、web Deployment がプリエンプティブル ノード上でのみ実行されるように制限します。

ノードプールを追加する

1. 次のコマンドを実行し、3 つのプリエンプティブル VM インスタンスを使用して新しいノードプールをデプロイします。

gcloud container node-pools create "temp-pool-1" \ --cluster=$my_cluster --zone=$my_zone \ --num-nodes "2" --node-labels=temp=true --preemptible

プリエンプティブル インスタンスが使用できないというエラーが表示された場合は、--preemptible オプションを削除して先に進みます。

2. ノードのリストを取得して、新しいノードが準備できていることを確認します。

kubectl get nodes

これでノードが 4 つになりました。

実際の名前は以下の出力例と異なります。

出力:

NAME STATUS ROLES AGE VERSION gke-standard-cluster-1-default-pool...xc Ready 33m v1.19.10-gke.1600 gke-standard-cluster-1-default-pool...q8 Ready 33m v1.19.10-gke.1600 gke-standard-cluster-1-temp-pool-1-...vj Ready 32s v1.19.10-gke.1600 gke-standard-cluster-1-temp-pool-1-...xj Ready 37s v1.19.10-gke.1600

ノードプールの作成時に temp=true ラベルを設定したため、追加したすべてのノードにこのラベルが付いています。このラベルがあることで、追加したノードを簡単に見つけて構成できます。

3. temp=true ラベルが付いているノードだけを一覧表示するには、次のコマンドを実行します。

kubectl get nodes -l temp=true

追加した 2 つのノードだけが表示されます。

実際の名前は以下の出力例と異なります。

出力:

NAME STATUS ROLES AGE VERSION gke-standard-cluster-1-temp-pool-1-...vj Ready 3m26s v1.19.10-gke.1600 gke-standard-cluster-1-temp-pool-1-...xj Ready 3m31s v1.19.10-gke.1600

taint と toleration を適用してスケジュールを制御する

スケジューラが一時的なノードで Pod を実行しないように、一時的なプールの各ノードに taint を追加します。taint は、Pod が特定のノードで実行可能かどうかを決定する効果（NoExecute など）に関連付けられた Key-Value ペアとして実装されます。taint の Key-Value を容認するよう構成されているノードだけが、Pod を実行するようスケジュールされます。

1. 次のコマンドを実行して、新しく作成した各ノードに taint を追加します。

temp=true ラベルを使用すると、この変更をすべての新しいノードに同時に適用できます。

kubectl taint node -l temp=true nodetype=preemptible:NoExecute

taint を追加したノード上でアプリケーションの Pod を実行するには、Deployment の構成に tolerations キーを追加する必要があります。

2. web.yaml ファイルを編集するには、次のコマンドを実行します。

nano web.yaml

3. テンプレートの spec セクションに次のキーを追加します。

tolerations: - key: "nodetype" operator: Equal value: "preemptible"

このファイルの spec セクションは、以下のようになります。

... spec: tolerations: - key: "nodetype" operator: Equal value: "preemptible" containers: - image: gcr.io/google-samples/hello-app:1.0 name: web ports: - containerPort: 8080 protocol: TCP resources: # You must specify requests for CPU to autoscale # based on CPU utilization requests: cpu: "250m"

4. web Deployment で強制的に新しいノードプールを使用するには、テンプレートの spec セクションに nodeSelector キーを追加します。これは、先ほど追加した toleration キーと並行して行います。

nodeSelector: temp: "true" 注: GKE は、ノードが属するノードプールの名前を含む cloud.google.com/gke-nodepool というカスタムラベルを各ノードに追加します。このキーを nodeSelector の一部に使用して、Pod を適切なノードにのみにデプロイすることもできます。

web.yaml Deployment 全体は、以下のようになります。

apiVersion: apps/v1 kind: Deployment metadata: name: web spec: replicas: 1 selector: matchLabels: run: web template: metadata: labels: run: web spec: tolerations: - key: "nodetype" operator: Equal value: "preemptible" nodeSelector: temp: "true" containers: - image: gcr.io/google-samples/hello-app:1.0 name: web ports: - containerPort: 8080 protocol: TCP resources: # You must specify requests for CPU to autoscale # based on CPU utilization requests: cpu: "250m"

5. CTRL+X キーを押した後、Y キーと Enter キーを押してファイルを保存し、nano エディタを終了します。

6. 次のコマンドを実行して、この変更を適用します。

kubectl apply -f web.yaml

このファイルを適切に編集できない場合は、あらかじめ準備されている web-tolerations.yaml というサンプル ファイルを代わりに使用してください。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ノードプールを管理する

7. Pod のリストを取得します。

kubectl get pods

実際の名前は以下の出力例と異なる場合があります。

出力:

NAME READY STATUS RESTARTS AGE web-7cb566bccd-pkfst 1/1 Running 0 1m

6. 変更を確認するには、次のコマンドを使用して実行中の web Pod を調べます。

kubectl describe pods -l run=web

nodetype=preemptible が一覧表示されている Tolerations セクションは、（省略された）出力の下部に表示されます。

出力:

Node-Selectors: temp=true Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300s nodetype=preemptible Events:

この出力から、新しいプリエンプティブル ノードでは Pod が taint 値を容認することがわかります。つまり、新しいプリエンプティブル ノードでの Pod の実行をスケジュールできます。

7. 再度ウェブ アプリケーションを強制的にスケールアウトするには、loadgen Deployment のレプリカ数を 4 に戻します。

kubectl scale deployment loadgen --replicas 4

直接スケールできるのはウェブ アプリケーションだけですが、loadgen アプリケーションを使用することで、各アプリケーションに適用される taint、tolerations、nodeSelector の設定の違いが、スケジュール対象ノードの選択にどのような影響を及ぼすかを確認できます。

8. ワイド出力形式を使用して Pod のリストを取得し、Pod を実行しているノードを確認します。

kubectl get pods -o wide

このコマンドを実行すると、loadgen アプリケーションが default-pool ノードでのみ実行されており、ウェブ アプリケーションが temp-pool-1 のプリエンプティブル ノードでのみ実行されていることが確認できます。

taint を設定すると Pod はプリエンプティブル ノードで実行されなくなるため、loadgen アプリケーションはデフォルト プールでのみ実行されます。tolerations を設定すると、ウェブ アプリケーションはプリエンプティブル ノードで実行されます。nodeSelector を設定すると、ウェブ アプリケーション Pod が強制的にプリエンプティブル ノードで実行されます。

NAME READY STATUS [...] NODE Loadgen-x0 1/1 Running [...] gke-xx-default-pool-y0 loadgen-x1 1/1 Running [...] gke-xx-default-pool-y2 loadgen-x3 1/1 Running [...] gke-xx-default-pool-y3 loadgen-x4 1/1 Running [...] gke-xx-default-pool-y4 web-x1 1/1 Running [...] gke-xx-temp-pool-1-z1 web-x2 1/1 Running [...] gke-xx-temp-pool-1-z2 web-x3 1/1 Running [...] gke-xx-temp-pool-1-z3 web-x4 1/1 Running [...] gke-xx-temp-pool-1-z4

ラボを終了する

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

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

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

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

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

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

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