この記事は デジタル創作サークル 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 にコンテナが利用不可であることを知らせることができるものです。
設定例:
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 のルーティングからは外されます。
設定例:
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 のままになります。
設定例:
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
コマンドの実行で検証する
さて、ここからは検証方法の解説です。
まずは、コンテナの中で特定のコマンドを実行することにより検証する方法です。
設定例:
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 リクエストを送信し、その応答によって確認します。
設定例:
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 ソケットを使用するタイプです。
コネクションが確立できる場合はコンテナを正常とみなし、失敗する場合は異常とみなします。
設定例:
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 ↓