Liveness/Readiness Probe


2 min read
Liveness/Readiness Probe

Kubernetesによるヘルスチェックには、Liveness ProbeとReadiness Probeと呼ばれる二つのものがあります。これらは混乱しがちな一方、日本語による情報が多くない(2018/07/26現在で、Google検索の1ページ目にヒットするのが4件ほど)ため、ここで一つ情報をまとめておきます。

共通

Liveness ProbeとReadiness Probeの設定は共通で、DeploymentPodのマニフェスト内で、containersの中にlivenessProbereadinessProbeとしてそれぞれProbe specを記述します。

次の項目を設定することが出来ます。

  • failureThreshold
    • Success状態の時、何回失敗したらFailureになるか。最小で1回。
    • Default: 3
  • initialDelaySeconds
    • コンテナが起動してからヘルスチェックを始めるまでの秒数。
    • Default: 0
  • periodSeconds
    • ヘルスチェックの間隔。最小で1秒
    • Default: 10
  • successThreshold
    • Failure状態の時、何回成功したらSuccessになるか。最小で1回。
    • Default: 1
  • timeoutSeconds
    • ヘルスチェックのタイムアウト秒数。最小で1秒。
    • Default: 1
  • httpGet
    • ヘルスチェックでアクセスするhttpエンドポイントの情報を書く。

httpGetの項目は次の様な項目を持ったobjectを書きます。

  • host
    • 対象のホスト名。
    • Default: PodのIP
  • httpHeaders
    • リクエストのカスタムヘッダ指定。{name: HEADER_NAME, value: HEADER_VALUE}の形のオブジェクトの配列で書く。
  • port
    • アクセスするポート番号または名称
  • path
    • アクセスするパス。
  • scheme
    • アクセスする際のスキーム。
    • Default: HTTP

Liveness Probe

一つ目はLiveness Probeです。公式ドキュメントには次の様に書いてあります。

livenessProbe: Indicates whether the Container is running. If the liveness probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a liveness probe, the default state is Success.

Liveness Probeの役割はその名の通り、アプリケーションの生存確認です。コンテナ起動後の状態はSuccessで、FailureになるとKubernetesはコンテナをkillします。コンテナがkillされた後は、Podのrestart policyに従います。
よく使用されるエンドポイントパスは/healthzです(最後のzがどこから来たのか、知ってる人がいたら教えてください)。

Go言語でのLiveness Probe用エンドポイントのサンプルを次に示します。

func livenessProbeHandler(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("OK"))
}

Readiness Probe

もう一つのヘルスチェックがReadiness Probeです。公式ドキュメントの説明は次の通りです。

readinessProbe: Indicates whether the Container is ready to service requests. If the readiness probe fails, the endpoints controller removes the Pod’s IP address from the endpoints of all Services that match the Pod. The default state of readiness before the initial delay is Failure. If a Container does not provide a readiness probe, the default state is Success.

ReadinessProbeは、サービスがリクエストを受け付けられる状態かどうかを確認します。例えば、DB接続の初期化処理に時間がかかる場合など、アプリケーションは生きているがまだ対応出来ない、という状態を判断します。コンテナ起動後の状態はFailureで、SuccessになるとKubernetesはPodのIPを、セレクタがマッチするサービスの対象として追加します。また、SuccessからFailureになった場合は、同様にサービスからIPを削除します。これにより、準備が出来ていないPodはServiceによるロードバランシングの対象から外れることとなります。
よく使用されるエンドポイントパスは/readinessです。

Go言語でのサンプルは次の様なものです。

func readinessProbeHandler(w http.ResponseWriter, r *http.Request) {
    if err := db.Ping(); err != nil {
        w.WriteHeader(http.StatusServiceUnavailable)
        w.Write([]byte("error: DB connection"))
        return
    }
    w.WriteHeader(http.StatusOK)
    w.Write([]byte("OK"))
    return
}

Future Pattern
Previous article

Future Pattern

Future Patternは非同期処理パターンの一つで、ある処理を別のスレッドなどで実行し、結果を後で(=未来で)受け取るような処理に用いられるデザインパターンです。 特徴としては、外側に見えている関数などの処理を実行するオブジェクトは、処理を別スレッドに委譲し、後で結果を得ることの出来るFutureと呼ばれるオブジェクトを即座にメインロジックへと返却することです。 言葉で書いても、何だかよくわからないので、コードを見てみましょう。 /* package, import part */ func main() { in := make(chan int) out := Double(in)

MetalLBを使用してオンプレでもtype: LoadBalancerを使用する
Next article

MetalLBを使用してオンプレでもtype: LoadBalancerを使用する

TL;DR MetalLBを使用することでオンプレ(not on OpenStack)に構築したk8sでもtype: LoadBalancerを使用できる type: LoadBalancer kubespray等を使用して、Kubernetesをオンプレ(on OpenStackを除く)で構築した場合、通常、type: LoadBalancerを使用することができません。これは、type: LoadBalancerは通常CloudProviderにより管理されており、オンプレ(on OpenStackを除く)でk8sを構築した場合にはCloudProvider連携が無いためです。


GO TOP

🎉 You've successfully subscribed to something tech.!
OK