13
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

この記事は デジタル創作サークル UniProject Advent Calendar 2025 および Kubernetes Advent Calendar 2025 7 日目の記事です。

みなさん、運用中に

  • エラーが起きてアプリケーションが正常に動作していない
  • 致命的なエラーは出ていないので動き続けている

なんてことありませんか?

今回はそんなことにならないようにする Probe のお話です。

Kubernetes における Probe とは

Kubernetes には、コンテナを指定したチェック方法でチェックし、Pod の状態を更新するための仕組みです。

種類としては、以下のようなものがあります。

  • Liveness Probe
  • Readiness Probe
  • Startup Probe

また、それぞれの Probe において、以下の方法で検証することができます。

  • コンテナ内でのコマンド実行による検証
  • HTTP リクエストによる検証
  • TCP による検証

詳しくみていきましょう。

Liveness Probe

Kubernetes のドキュメントにはこのように記述があります。

kubelet は、Liveness Probe を使用して、コンテナをいつ再起動するかを認識します。 例えば、アプリケーション自体は起動しているが、処理を継続することができないデッドロック状態を検知することができます。 このような状態のコンテナを再起動することで、バグがある場合でもアプリケーションの可用性を高めることができます。

要するに、コンテナ自体は死んでいないが、内部的には死んでいるという状況を検知し、kubelet にコンテナが利用不可であることを知らせることができるものです。

設定例:

pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
    - name: goproxy
      image: registry.k8s.io/goproxy:0.1
      ports:
        - containerPort: 8080
      livenessProbe:
        ## ...
        ## ここは後述する検証方法の部分で解説します。
        exec:
          command:
          - cat
          - /tmp/healthy
        initialDelaySeconds: 5
        periodSeconds: 5

Readiness Probe

Kubernetes のドキュメントにはこのように記述があります。

kubelet は、Readiness Probe を使用して、コンテナがトラフィックを受け入れられる状態であるかを認識します。 Pod が準備ができていると見なされるのは、Pod 内の全てのコンテナの準備が整ったときです。 一例として、このシグナルは Service のバックエンドとして使用される Pod を制御するときに使用されます。 Pod の準備ができていない場合、その Pod は Service のロードバランシングから切り離されます。

要するに、死んでいるとみなすほどで無かったとしても、一時的に利用不可であることを検知できます。
コンテナを再起動するほどでもない軽微なエラーを検証するときに役立ちます。

また、これが失敗している Pod は Ready にはなりますが、Service のルーティングからは外されます。

設定例:

pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
    - name: goproxy
      image: registry.k8s.io/goproxy:0.1
      ports:
        - containerPort: 8080
      readinessProbe:
        ## ...
        ## ここは後述する検証方法の部分で解説します。
        exec:
          command:
          - cat
          - /tmp/healthy
        initialDelaySeconds: 5
        periodSeconds: 5

Startup Probe

Kubernetes のドキュメントには、こう記述があります。

kubelet は、Startup Probe を使用して、コンテナアプリケーションの起動が完了したかを認識します。 Startup Probe を使用している場合、Startup Probe が成功するまでは、Liveness Probe と Readiness Probe によるチェックを無効にし、これらがアプリケーションの起動に干渉しないようにします。 例えば、これを起動が遅いコンテナの起動チェックとして使用することで、起動する前に kubelet によって 強制終了されることを防ぐことができます。

要するに、起動が遅いにもかかわらず Liveness Probe が実行されてコンテナが消されることを防ぐものです。
これが通らない限り、Container Creating のままになります。

設定例:

pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
    - name: goproxy
      image: registry.k8s.io/goproxy:0.1
      ports:
        - containerPort: 8080
      startupProbe:
        ## ...
        ## ここは後述する検証方法の部分で解説します。
        exec:
          command:
          - cat
          - /tmp/healthy
        initialDelaySeconds: 5
        periodSeconds: 5

コマンドの実行で検証する

さて、ここからは検証方法の解説です。

まずは、コンテナの中で特定のコマンドを実行することにより検証する方法です。

設定例:

pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
    - name: goproxy
      image: registry.k8s.io/goproxy:0.1
      ports:
        - containerPort: 8080
      livenessProbe:
        exec:
          command:
          - cat
          - /tmp/healthy
        ## ここは後述するおまけで解説します。
        initialDelaySeconds: 5
        periodSeconds: 5

ここでは、cat /tmp/healthyというコマンドが成功するかどうかで検証しています。
このコマンドが失敗した場合、コンテナは利用可能ではないとみなされ、Liveness Probe の仕様に基づき強制的に再起動されます。

HTTP リクエストによる検証

HTTP リクエストを送信し、その応答によって確認します。

設定例:

pod.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
    - name: liveness
      image: registry.k8s.io/e2e-test-images/agnhost:2.40
      args:
        - liveness
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
          httpHeaders:
            - name: Custom-Header
              value: Awesome
        initialDelaySeconds: 3
        periodSeconds: 3

この例では、

  • :8080/healthzに対して
  • HTTP ヘッダーCustom-Header: Awesomeをつけて

リクエストを送信します。
この応答が 200-300 番台のものでない限り、失敗したとみなします。

TCP による検証

Liveness Probe は TCP ソケットを使用するタイプです。
コネクションが確立できる場合はコンテナを正常とみなし、失敗する場合は異常とみなします。

設定例:

pod.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
    - name: liveness
      image: registry.k8s.io/e2e-test-images/agnhost:2.40
      args:
        - liveness
      livenessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 3
        periodSeconds: 3

HTTP の設定例と少し似ていますね。
この例では、ポート 8080 に対して接続を試みています。

名前付きのポート

このように、ポートに対して名前をつけている場合は、名前を使用して書くことができます。
これを行うことで、複数の設定項目を何度も修正する手間を省くことができます。

ports:
  - name: liveness-port
    containerPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port

おまけ: 頻度や閾値を設定する

Probe には、以下の設定項目を追加することにより、より細かい検証を行えます。

  • initialDelaySeconds - 最初に実行する検証までの間隔を指定できます。
  • periodSeconds - Probe が実行される頻度(秒数)です。ただし、最初だけは Readiness Probe がこれより短い間隔で行われることがあります。これは、Service のルーティングに早く参加させるためです。
  • timeoutSeconds - タイムアウトまでの秒数。
  • successThreshold - 失敗後、回復とするまでの成功回数の閾値。
  • failureThreshold - 失敗した回数の閾値。

最後に

特に自分で作成したアプリケーションをデプロイするときには、状態を確認することにより、いち早く障害に気づくことができたり、回復させることができます。
Probe をうまく使いこなして、快適な Kubernetes ライフを送りましょう!

また、当サークルでは ProxmoxVE や Kubernetes を運用しています。
もし興味がありましたら、下記 URL へ飛んでいただければと思います!

⭐︎ 公式 HP ↓

⭐︎ Discord ↓

13
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
13
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?