初心者でも Kubernetes のうれしいことが分かる-ヘルスチェック

オウルです。

前回の Kubernetes の Pod の続きなります。僕が思う Kubernetes のうれしいと思う機能の1つがヘルスチェック機能です。今回は、そのうれしいヘルスチェック機能を紹介します。

↓ 前回の記事です。

ヘルスチェック

ヘルスチェックにより Kubernetes にデプロイされたアプリケーションコンテナは常に動作している状態を維持します。アプリケーションコンテナが常に動作している状態を維持するということは、つまり「生存確認」と「応答確認」が必要となります。「生存確認」だと最初に思いつくのはアプリケーションのプロセスですね。

しかし、アプリケーションのプロセスが起動していても動作しているとは言えない状態があります。例えばデッドロックなんかはプロセスは起動したままですが、デッドロックなので応答することはできません。でも、きっと Kubernetes のヘルスチェック機能は、そのあたりを解決してくれるはずです。ではどういったヘルスチェック機能なのか見ていきたいと思います。

監視対象の単位

前回、Pod は Kubernetes クラスターでアプリケーションを動作させる(デプロイする)最小単位というお話をしました。ではヘルスチェックの監視対象の単位は Pod かな?!違うのです。コンテナです。つまり Pod に2つのコンテナが含まれていた場合は、それぞれのコンテナをヘルスチェックすることができます。そして異常があったコンテナの Pod を spec.restartPolicy に従って Pod を再起動します。

では本題に入ります。Kubernetes には Liveness probe と Readiness probe という2種類の異なる役割を果たすヘルスチェック機能があります。

Liveness probe

The kubelet uses liveness probes to know when to restart a Container. For example, liveness probes could catch a deadlock, where an application is running, but unable to make progress. Restarting a Container in such a state can help to make the application more available despite bugs.

翻訳

kubeletはコンテナをいつ再起動するかを知るために Liveness probes を使います。例えば、Liveness probes は、アプリケーションが実行されているが進行することができないデッドロックをキャッチする可能性があります。このような状態でコンテナを再起動すると、バグがあってもアプリケーションをより利用しやすくするのに役立ちます。

簡単に言うと Liveness probe は Pod が正常に動作しているかを確認するヘルスチェックです。異常があった場合は spec.restartPolicy に従って Pod を再起動します。具体例でイメージしてみます。

Web アプリケーション

自分が開発した Web アプリケーションのヘルスチェックをする場合を考えてみます。http リクエストを送って HTTP レスポンス ステータスコード 200 を返すようなメソッドがあればヘルスチェックとして利用できそうです。つまり HTTP レスポンス ステータスコード 200 が返ってきたらアプリケーションが処理したという判断ができます。

どうでしょう?少し具体的にイメージできると、さらなる質問がでてきますよね。ヘルスチェックする方法は、http だけなの?1回失敗したら再起動するの?もう少し細かく例えば10秒間隔で5回失敗したら再起動みたいな設定はできないの??

安心してください、できますよ(何か聞いたことあるようなフレーズだな)

3種類のヘルスチェック方法

ttp Get

上の具体例にあげたように、Web アプリケーションや Web API に有効なヘルスチェック方法です。もう少し詳細に言うと HTTP GET リクエストを送信して HTTP レスポンス ステータスコードが 200 ~ 399 であれば監視に成功、それ以外の場合は失敗と判断します。

自作の Web アプリケーションをヘルスチェックをするときには、ヘルスチェック用のメソッドを実装するときには色々考慮する必要がありそうです。

例えば、僕が今、学習している ASP.NET Core ではアプリケーションが正常処理した結果を HTTP レスポンス ステータスコード 400や401 で返す実装もあり得るためです。ASP.NET Core Identity で認証している場合はサインイン以降のアクションには [Authorize] 属性をつけて認証済み以外はアクセスできないようにすることができますが、その判定は Web アプリケーションが正常に処理したからこその HTTP レスポンス ステータスコード 401 です。そのため ASP.NET Core のヘルスチェックメソッドには [AllowAnonymous] 属性をつけて誰でもアクセス可としておく必要があります。

CPソケット

TCPソケットを開いて接続に成功したら監視成功です。僕はTCP ソケットといえばデータベースを思い浮かべますが、例えば SQLServer の接続で IPAddres or hostname,1433 で失敗したから、すぐに再起動ってのはちょっとあれですよね。要は監視に失敗して再起動するまでの条件が重要ということです。

xec スクリプト

exec スクリプトは、コマンド・スクリプトを実行して終了コードで判定します。

Restart policy

コンテナ停止時には3つの動作を指定することができます。デフォルトは、「Always」です。

Always

Pod が停止すると、常に Pod を再起動します。

OnFailure

Pod の停止が予期せぬ停止(終了コード0以外)の場合、Pod を再起動させます。

Never

Pod が停止しても、Pod を起動させません。

Readiness probe

The kubelet uses readiness probes to know when a Container is ready to start accepting traffic. A Pod is considered ready when all of its Containers are ready. One use of this signal is to control which Pods are used as backends for Services. When a Pod is not ready, it is removed from Service load balancers.

翻訳

kubeletは Readiness probe を使ってコンテナがいつトラフィックの受け入れを開始する準備ができているかを確認します。Pod は、そのすべてのコンテナの準備が整ったときに準備完了と見なされます。このシグナルの用途の1つは、どのPodをサービスのバックエンドとして使用するかを制御することです。ポッドの準備ができていない場合、ポッドはサービスロードバランサーから削除されます。

簡単に言うと Readiness probe は Pod が動作するための準備が完了しているかを確認するヘルスチェック機能です。

kuard でLiveness probe の動作を見る

まず、前回使用した kuard Pod は一度削除してください。

kuard デプロイ

Liveness probe を含めた Pod マニフェストを作成して kunard をデプロイします。

前回と同様に http://localhost:8080/ にアクセスして下の画面が表示されれば OK です。

次に左ペインにある Liveness probe をクリックしてください。

おぉ、10秒間隔で監視結果ログが追加されます。ヘルスチェックが行われてますね。

Liveness probe の設定項目

initialDelaySeconds

コンテナが起動してから Liveness probe が開始されるまでの秒数です。

periodSeconds

Liveness probe を実行する頻度(秒数)。デフォルトは10秒です。最小値は1です。

timeoutSeconds

Liveness probe がタイムアウトするまでの秒数デフォルトは1秒です。最小値は1です。

successThreshold

Liveness probe が失敗した後に成功したと見なされるための最小連続成功回数。デフォルトは1です。最小値は1です。

failureThreshold

Pod が起動してLiveness probe が失敗した場合、Kubernetesは失敗の閾値を超えないようにします。Readiness probe を併用している場合は、再起動後の Pod は「未準備」とマークされます。デフォルトは3です。最小値は1です。

Liveness probe を失敗させてみる

kuard の Liveness probe の監視ログが表示されている上に、”Succeed | Fail ” のリンクがあります。”Fail” をクリックしてみましょう。しばらくするとkuard の監視ログが全て消えて、またID 1 から表示されるはずです。

まとめ

今回は Kubernetes のヘルスチェック機能、特に Liveness probe を実際に手を動かして見てみました。簡単にまとめると次のようになります。

  • ヘルスチェックの単位はコンテナ
  • Restart policy で Pod 停止後の動作を指定
  • 2種類(Liveness probe と Readiness probe)の役割の異なったヘルスチェックがある
  • 3種類(http、tcp、exec)のヘルスチェック方法がある

ヘルスチェック機能は自作でもできないことはないですが、再起動までの条件を細かく設定できること、初回起動時のトラフィックのルーティングを制御できることなどが標準機能ということは大きなメリットだと思います。

「初心者でも Kubernetes のうれしいことが分かってしまう」シリーズ
  1. Dockerのうれしいこと
  2. 6つのうれしいこと-概要編
  3. 最小単位のPod
  4. ヘルスチェック
  5. セルフヒーリング(ReplicaSet)
  6. 宣言的更新を提供するコントローラー(Deployment)
「Raspberry Pi 4でKubernetes」シリーズ
  1. Raspberry Pi 4でk8s-パーツ購入編-
  2. Raspberry Pi 4でk8s-OSセットアップ編-
  3. Raspberry Pi 4でk8s-k8s cluster編-

おすすめ書籍

▼ Kubernetesの入門書
『入門 Kubernetes』

1.6,5 のバージョンで解説(リポジトリ、注釈は翻訳時の最新1.9で更新)されています。バージョンは少し古いですが、初心者の入門書(おえるべきポイントはしっかり網羅されてる)としては、途中で挫折しない適度なボリューム(本の厚さ)で、とっかかりとしては良い本になっています。

▼ Kubernetesの入門~応用までをカバー
『Kubernetes完全ガイド (impress top gear)』

僕は「入門 Kubernetes」⇒「Kubernetes完全ガイド」(現在進行形)という進み方をしていますが、より本番環境を想定した方法を学べます。特にWeb 系だと、https で使用する Ingress リソースなどもしっかり説明してくれています。「入門 Kubernetes」には、詳しい説明がなかったので個人的にはすごく助かっています。

▼ Docker / Kubernetesの入門
『Docker/Kubernetes 実践コンテナ開発入門』

コンテナオーケストレーションプラットフォームである Kubernetes を学ぶときには、どうしても Docker の知識が必要となってきます。それをまとめているのが、この本です。途中で挫折しない適度なボリューム(本の厚さ)で、とっかかりとしては良い本になっています。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA