【Kubernetes】ヘルスチェック | 若手エンジニアのブログ

若手エンジニアのブログ

文系出身の若手女子エンジニアによる技術ブログ。
日々の経験や学びをアウトプットするためにブログを書いています。
バックエンド(Java+SpringFramework)を経てインフラエンジニアになりました。
今は育休中につき、本で勉強したことを中心にアウトプットしています。

Kubernetes(以下k8s)の標準ヘルスチェック機能について見ていく。

 

もくじ

1.k8sの標準ヘルスチェックとは

2.標準ヘルスチェックの考え方3パターン

  Startup Probe / Readiness Probe / Liveness Probe

3.ヘルスチェックの実現方式3パターン

  exec / httpGet / tcpSocket

4.ヘルスチェック実行タイミング設定5パターン

  initialDelaySeconds / periodSeconds / timeoutSeconds / successThredshold / failureThredshold

5.マニフェストファイルの記述イメージ

参考文献

 

1.k8sの標準ヘルスチェックとは

Pod内のコンテナ上で実行されているプロセスが、問題なく動作しているかチェックする機能は、

k8s標準で存在する。

ヘルスチェックはコンテナ毎に行われ、コンテナが1つ以上失敗した場合には、

そのコンテナを含むPod全体が失敗したとみなす仕組みとなっている。

 

ヘルスチェックをどのように行うかの設定は、

マニフェストファイルに記述することが可能である。

 

2.標準ヘルスチェックの考え方3パターン

標準ヘルスチェックは、大きく3つの考え方に分けられる。

 

◎Startup Probe

Pod内のコンテナアプリケーションの起動が完了したかチェック。

Startup ProbeがOKにならない限り、残りのLiveness ProbeとReadiness Probeのチェックは行われない。

 

◎Readiness Probe

Podがサービスインできる準備ができたかチェック。

Pod内のすべてのコンテナの準備が完了するまでは、Serviceからトラフィックが流されないようにしてくれる。

コンテナの準備の例としては、バックエンドのDBとの接続が完了したか、

起動に時間がかかるプロセスが起動終了したか等が挙げられる。

 

◎Liveness Probe

Podが正常動作しているかをチェック。

アプリケーション自体は起動しているが、プロセスにバグがあって処理を継続できないなどの時に、

プロセスを再起動してくれる。

ヘルスチェック失敗後、Podの再起動なしではプロセス回復が困難なコンテナなどに、利用される。

 

 

3.ヘルスチェックの実現方式3パターン

続いて、「2.ヘルスチェックの考え方3パターン」で示したヘルスチェックの考え方を、

実際に実現するための方法を紹介する。

 

実現方式は3パターンある。

どのパターンであっても、マニフェストファイルに記述することで、ヘルスチェックが走る仕組みとなっている。

◎exec(コマンド実行)

コンテナ毎にヘルスチェック用のコマンドを実行し、返却された終了コードによって確認を行う方式。

終了コードが0なら成功、0以外なら失敗とみなす。

 

◎httpGet(HTTPリクエスト)

HTTP GETリクエストをコンテナに送り、返却されるステータスコードによって確認を行う方式。

ステータスコードが200~399なら成功、それ以外なら失敗とみなす。

 

◎tcpSocket(TCPベース)

コンテナとTCPセッションを確立させることで、確認を行う方式。

TCPセッションが確立出来たら成功、出来なかったら失敗とみなす。

 

4.ヘルスチェック実行タイミング設定5パターン

k8sのヘルスチェックは、その実行タイミングも設定できるようになっている。

設定できる項目は5パターンある。

なお、いずれもオプション設定であり、明示的に設定しなかった場合はデフォルト設定が適用される。

 

◎initialDelaySeconds

初回ヘルスチェックを開始するまで、何秒待つか。

設定すると、待たなかった場合に、単純な起動遅れにも関わらず異常検出される、といったことを防げる。

デフォルトは0秒。最小値は0。

 

◎periodSeconds

ヘルスチェックを行う間隔(秒単位)。

例えば periodSeconds: 15 と設定した場合には、15秒おきにチェックすることになる。

デフォルトは10秒。最小値は1。

 

◎timeoutSeconds

ヘルスチェックがタイムアウトするまでの秒数。

デフォルトは1秒。最小値は1。

 

◎successThreshold

一度ヘルスチェックに失敗した後、成功と判断するまでの連続チェック可能回数。

Liveness Probeの場合は必ず1を設定する。

デフォルトは1秒。最小値は1。

 

◎failureThreshold

失敗と判断するまでのチェック回数。

チェックを行って一度失敗しても、偶然かもしれないので何度か再チェックを行うことができる。

再チェックを繰り返したが失敗が繰り返される場合をイエローカードとし、

イエローカードが〇回溜まったら、レッドカードとして正式に「ダメだった」と判断するようなイメージ。

「ダメだった」となった場合、Liveness ProbeならPodの再起動実施、

Readiness ProbeならPodの準備がまだできていないと通知することになる。

デフォルトは3。最小値は1。

 

5.マニフェストファイルの記述イメージ

上で見てきた、ヘルスチェックの考え方と実現方式、実行間隔の設定は、

マニフェストファイルの「spec.containers[]」部分に記述する。

 

例として、コマンド実行方式(exec)で、Liveness Probeを実現するためのマニフェストファイルを示す。

 

公式よりそのまま使わせて頂きました

piVersion: 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

赤字の部分が、ヘルスチェックに関する設定の箇所。

spec.containers[]

 └どの考え方に関する設定か(livenessProbe/readinessProbe/startup Probe)

    └どの実現方式を使うか(exec/httpGet/tcpSocket)

       └実現方式の細かな設定(ここでは、 cat /tmp/healthy というコマンドをコンテナ内で実行すると設定している)

    └ヘルスチェックの間隔に関する設定(ここでは、initialDeplaySecondsを5秒、periodSecondsを5秒と設定している)

 

なお、例はLiveness Probeのみを実現するマニフェストファイルだが、

複数のProbeを実現したければ、同様に並列記述すればよい。

 

■参考文献

・公式サイト

https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

・青山真也著『Kubernetes完全ガイド