概要

このラボでは、Kubernetes の livenessProbe と readinessProbe をコンテナに対して構成してテストします。

目標

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

• livenessProbe を構成してテストする
• readinessProbe を構成してテストする

ラボの設定

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 クラスタに接続し、ラボの Cloud Shell にラボのリポジトリのクローンを作成します。

ラボの 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

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

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

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

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

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

cd ~/ak8s/Probes/

タスク 2. livenessProbe を構成する

livenessProbe を構成する

このタスクでは、実行状態から無効状態に移行したアプリケーションを検出する livenessProbe をデプロイします。アプリケーションが一時的にトラフィックを処理できないことがあります。たとえば、アプリケーションの起動時にサイズの大きなデータや構成ファイルを読み込む必要があるような場合です。

その場合において、ユーザーはアプリケーションの強制終了も、そのアプリケーションへのリクエストの送信もしたくありません。Kubernetes は readinessProbe を提供し、このような状況を検出して抑制します。準備状態ではないことを報告するコンテナを含む Pod は、Kubernetes サービスを介してトラフィックを受信しません。

readinessProbe は livenessProbe と同様の方法で構成されます。唯一の違いは、livenessProbe フィールドの代わりに readinessProbe フィールドを使用することです。

exec-liveness.yaml という名前の Pod 定義ファイルがあらかじめ用意されています。このファイルには、Busybox を実行する liveness という名前のシンプルなコンテナと、コンテナ内の /tmp/healthy ファイルに対して cat コマンドを使用して 5 秒ごとに liveness をテストする livenessProbe が定義されています。

liveness コンテナの起動スクリプトは起動時に /tmp/healthy を作成し、30 秒後にこれを削除して、livenessProbe が検出できるように停止をシミュレートします。

apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec spec: containers: - name: liveness image: k8s.gcr.io/busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5

1. Cloud Shell で次のコマンドを実行して、Pod を作成します。

kubectl create -f exec-liveness.yaml

2. 30 秒以内に Pod イベントを表示します。

kubectl describe pod liveness-exec

出力は、livenessProbe がまだ失敗していないことを示しています。

出力例の要約:

Type: Secret (a volume populated by a Secret) SecretName: default-token-wq52t Optional: false QoS Class: Burstable Node-Selectors: Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age ... Message ---- ------ ---- ... ------- Normal Scheduled 11s ... Successfully assigned liveness-e ... Normal Su...ntVolume 10s ... MountVolume.SetUp succeeded for ... Normal Pulling 10s ... pulling image "k8s.gcr.io/busybox" Normal Pulled 9s ... Successfully pulled image "k8s.g ... Normal Created 9s ... Created container Normal Started 9s ... Started container

この出力例は読みやすさを考慮して要約されています。実際の画面には、より詳しい情報が表示されます。

3. 35 秒後に Pod イベントを再度表示します。

kubectl describe pod liveness-exec

出力の下部に、livenessProbe が失敗したことと、コンテナが強制終了されて再作成されたことを示すメッセージが表示されます。

出力例の要約:

Type: Secret (a volume populated by a Secret) SecretName: default-token-wq52t Optional: false QoS Class: Burstable Node-Selectors: Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age ... Message ---- ------ ---- ... ------- Normal Scheduled 2m ... Successfully assigned liveness-e ... Normal Su...ntVolume 2m ... MountVolume.SetUp succeeded for ... Normal Pulling 49s ... pulling image "k8s.gcr.io/busybox" Normal Pulled 49s ... Successfully pulled image "k8s.g ... Normal Created 49s ... Created container Normal Started 49s ... Started container Normal Killing 49s ... Killing container with id docker://liveness:Container failed liveness probe.. Container will be killed and recreated. Warning Unhealthy 5s ... Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory

4. さらに 60 秒待機して、コンテナが再起動されたことを確認します。

kubectl get pod liveness-exec

出力には、livenessProbe によって検出された失敗に対応して RESTARTS が増分されたことが示されています。

出力例:

NAME READY STATUS RESTARTS AGE liveness-exec 1/1 Running 2 4m

5. livenessProbe のデモ Pod を削除します。

kubectl delete pod liveness-exec

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 livenessProbe を構成する

タスク 3. readinessProbe を構成する

Pod が正常に起動し livenessProbe によって正常と判断されても、その時点でトラフィックを受信できる準備が整っていない可能性もあります。これは、ロードバランサなどの Service のバックエンドとして機能する Deployment にはよくあることです。readinessProbe は、Pod とコンテナでトラフィックを受信できる準備が整っているかどうかを判断するために使用されます。

readinessProbe は livenessProbe と同様の方法で構成されます。構成の唯一の違いは、livenessProbe フィールドの代わりに readinessProbe フィールドを使用することです。readinessProbe は、特定のコンテナが準備ができていると見なされるかどうかを制御するもので、コンテナにトラフィックを送信できるかどうかを判断するために Service によって使用されます。

このタスクでは、readiness-deployment.yaml という Pod 定義ファイルがあらかじめ用意されています。このファイルは、ロードバランサとともにテスト ウェブサーバーとして機能する単一の Pod を作成します。

コンテナには readinessProbe が定義されており、コンテナ内の /tmp/healthy ファイルに対して cat コマンドを使用して 5 秒ごとに readiness をテストします。

各コンテナには、コンテナ内の同じファイルに対して cat コマンドを使用して 5 秒ごとに readiness をテストする livenessProbe も定義されていますが、コンテナが起動してから安定するまでに時間がかかる複雑な起動プロセスを持つアプリケーションをシミュレートするために起動の遅延が 45 秒に設定されています。

Service によるトラフィックの処理が開始されると、このパターンにより、トラフィックを処理する準備ができているコンテナにのみトラフィックが転送されるようになります。

apiVersion: v1 kind: Pod metadata: labels: demo: readiness-probe name: readiness-demo-pod spec: containers: - name: readiness-demo-pod image: nginx ports: - containerPort: 80 readinessProbe: exec: command: - cat - /tmp/healthz initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: readiness-demo-svc labels: demo: readiness-probe spec: type: LoadBalancer ports: - port: 80 targetPort: 80 protocol: TCP selector: demo: readiness-probe

1. Cloud Shell で次のコマンドを実行して、Pod を作成します。

kubectl create -f readiness-deployment.yaml

2. Cloud Shell で、readiness-demo-svc というロードバランサ サービスのステータスを確認します。

kubectl get service readiness-demo-svc

3. ブラウザ ウィンドウに IP アドレスを入力すると、サイトにアクセスできないことを示すエラー メッセージが表示されます。

4. Pod のイベントを確認します。

kubectl describe pod readiness-demo-pod

出力は次のようになり、readiness プローブが失敗したことが示されます。

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m24s default-scheduler Successfully assigned default/readiness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 2m23s kubelet Pulling image "nginx" Normal Pulled 2m23s kubelet Successfully pulled image "nginx" Normal Created 2m23s kubelet Created container readiness-demo-pod Normal Started 2m23s kubelet Started container readiness-demo-pod Warning Unhealthy 35s (x21 over 2m15s) kubelet Readiness probe failed: cat: /tmp/healthz: No such file or directory

liveness プローブと異なり、readiness プローブでは結果が正常でなくても Pod の再起動はトリガーされません。

5. 次のコマンドを使用して、readiness プローブが存在を確認しようとしているファイルを生成します。

kubectl exec readiness-demo-pod -- touch /tmp/healthz

Pod の説明の Conditions セクションで、Ready の値に True が表示されます。

kubectl describe pod readiness-demo-pod | grep ^Conditions -A 5

出力:

Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True

6. 次に、readiness-demo-svc 外部 IP が設定されているブラウザタブを更新します。「Welcome to nginx!」というメッセージが表示されるはずです。

アプリケーション コンテナに有意な readiness プローブを設定すると、Pod がトラフィックを受信できる準備が整っているときにのみ、トラフィックを受信するようになります。有意な readiness プローブの例としては、アプリケーションが依存するキャッシュが起動時に読み込まれているかどうかを確認することが挙げられます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 readinessProbe を構成する

livenessProbe と readinessProbe の動作をモニタリングする

次に、Deployment の Pod の準備状況が Service のアクティブなエンドポイントに対応していることを確認します。Pod が readinessProbe と livenessProbe のテストに失敗すると、準備ができていないものとしてマークされるため、エンドポイントが Service から削除されます。また、livenessProbe が復旧のために Pod の再起動プロセスを開始します。

再起動した Pod は、すぐには Ready とマークされません。その前に readiness テストに合格する必要があります。合格すると、再びエンドポイントが Service のプールに追加されます。

1. Pod のステータスを再度確認します。

kubectl get pods

個々の Pod が Ready と表示されます。タイミングによっては再起動している Pod があるかもしれませんが、再起動が開始されるまでには 2～3 分かかります。Ready と表示されている Pod は、エンドポイントが Service に関連付けられているはずです。

2. そのことを確認するには、アプリケーションに接続します。まず、ロードバランサ Service の詳細から外部 IP アドレスを取得して環境変数に保存します。

export EXTERNAL_IP=$(kubectl get services readiness-demo-svc -o json | jq -r '.status.loadBalancer.ingress[0].ip')

3. アプリケーションが応答するか確認します。

curl $EXTERNAL_IP

4. 次のコマンドを数分間、約 10 秒ごとに実行して、Deployment のステータスを確認し、ロードバランサにリクエストを送信します。

curl $EXTERNAL_IP kubectl get pods

レスポンスが継続的に返されます。livenessProbe によって障害が検出されて、個々のコンテナが定期的に再起動するにもかかわらず、失敗したり、タイムアウトになったりすることはありません。3 つのコンテナすべてがほぼ同時に再起動するとタイムアウトになる可能性がありますが、そのような状況はめったに発生しません。

livenessProbe と readinessProbe を組み合わせると、障害が発生したシステムを安全に再起動できます。その間トラフィックは、応答できることが確認されているコンテナにのみ転送されます。

ラボを終了する

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

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

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

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

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

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

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