livenessprobeとは？初心者向けにわかりやすく解説する完全ガイド共起語・同意語・対義語も併せて解説！

この記事を書いた人

高岡智則

年齢：33歳性別：男性職業：Webディレクター（兼ライティング・SNS運用担当）居住地：東京都杉並区・永福町の1LDKマンション出身地：神奈川県川崎市身長：176cm 体系：細身〜普通（最近ちょっとお腹が気になる）血液型：A型誕生日：1992年11月20日最終学歴：明治大学・情報コミュニケーション学部卒通勤：京王井の頭線で渋谷まで（通勤20分）家族構成：一人暮らし、実家には両親と2歳下の妹恋愛事情：独身。彼女は2年いない（本人は「忙しいだけ」と言い張る）

livenessprobeとは？基本を知ろう

livenessprobeは Kubernetes の機能の一つで、コンテナが生きているかどうかを定期的に判断する仕組みです。もしコンテナが応答しなくなったり、内部でエラーが連続して発生したりしたときに、自動的に再起動するきっかけになります。これにより、サービスの停止時間を短く保つことができます。

この仕組みは livenessProbe という名前の設定として、各コンテナのスペックの中に配置されます。名前は英語の綴りの違いだけで意味は同じですが、正確には livenessProbe として YAML に記述します。以下では、なぜ必要か、どう動くか、そして基本的な使い方を中学生にも分かる言葉で解説します。

livenessprobe があると何が良いのか

アプリが動作していても、内部で死んでいる状態や応答不能状態になることがあります。生存性を見守る livenessprobe は、そういった状態を検知するとコンテナを再起動します。再起動によって新しいプロセスが立ち上がり、問題が解消されることが期待できます。これにより、ユーザーが気づく前にサービスの連続性を保つことができます。

livenessprobe の3つの検査タイプ

現場で使われる主な 3 つの検査方法があります。それぞれの特徴を知って適切に選ぶことが大事です。

httpGet： HTTP/HTTPS のエンドポイントを叩いて健康状態を確認します。エンドポイントが 200 番台を返せば OK、そうでなければ NG と判断します。
exec：コンテナ内でコマンドを実行して、終了コードや出力で健康を判定します。難易度は高いですが、細かい判定が可能です。
tcpSocket：指定したポートへ TCP 接続を試みて、接続が成功するかどうかで判断します。ネットワーク回線やアプリの起動直後などに有効です。

基本の設定と YAML の書き方

livenessprobe はコンテナの spec の中に記述します。代表的な設定項目は以下のようなものです。

設定項目	説明
initialDelaySeconds	最初の検査を開始するまでの待機時間。起動直後にすぐ検査しないようにするための値です。
periodSeconds	検査を行う頻度。秒単位で設定します。
timeoutSeconds	検査を完了とみなすまでの時間。長すぎると遅延の原因になります。
failureThreshold	連続して失敗したときに死活をNGと判断する回数。高すぎると問題を見逃す可能性があります。
successThreshold	連続して成功したときに回復とみなす回数。通常は 1 で十分です。
httpGet	HTTP/HTTPS の検査を行う場合の設定。path や port、場合により scheme を指定します。
path	検査対象のエンドポイントのパス。
port	検査を行うポート番号。
scheme	http か https。必要に応じて指定します。
exec	コンテナ内のコマンドを実行する場合の設定。command 配列を使います。
tcpSocket	TCP ソケット検査の設定。port を指定します。

具体的な例

以下は最も基本的な HTTP ベースの livenessProbe の例です。読みやすさを優先して改行を入れていますが、実際には YAML 形式で設定します。

apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: myapp
image: myimage
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 20

設定を試すときのコツ

最初は簡単なエンドポイントを作ってテストしましょう。やりすぎると検査自体が負荷になることがあるため、検査の頻度 periodSeconds とタイムアウト timeoutSeconds を現実的な値に設定することが大切です。

注意点とベストプラクティス

・ readinessProbe と livenessProbe は役割が違います。readinessProbe はリクエストを受け付けられる準備ができたかを示し、livenessProbe は生存性を示します。両方を適切に使い分けることが重要です。
・過剰な検査はアプリの再起動を引き起こし、逆にサービスを不安定にします。適切な頻度とタイムアウトを設定しましょう。
・エラーレスポンスの原因を特定するために、検査対象のエンドポイントは安定して動作するように設計してください。

テストのヒント

実際に動かしてみるときは、故意にエンドポイントを落とす、あるいはコマンドを失敗させるなどして、livenessProbe が正しくコンテナを再起動するか確かめてください。ログを確認して、再起動回数が過剰になっていないかもチェックしましょう。

livenessprobeの同意語

生存性プローブ: Kubernetesにおけるliveness probeの正式な日本語表現。コンテナが生存しているかを定期的に判定し、異常を検知すると再起動を促します。
生存性チェック: 生存性を検証する意味の表現。公式用語としては『生存性プローブ』のほうが一般的ですが、同義として使われることがあります。
生存確認プローブ: 生存を確認する目的の表現。機能はliveness probeと同じで、文脈により使用されます。
ライブネスプローブ: liveness probeのカタカナ表記。技術文書や解説で見かけることがあります。
Liveness Probe: 英語表記そのままの名称。日本語説明と併せて使われることが多いです。
生存性ヘルスチェック: 生存性を指すヘルスチェックの表現。意味は近しいが、公式用語としては混同を招く場合があります。

livenessprobeの対義語・反対語

死活検知: liveness の対義語として捉えた場合の概念。コンテナが生存しているかではなく、死亡・停止の状態を検知するイメージです。実務で一般的ではないものの、対義語として理解を深めるために挙げます。
ダウン検知: コンテナが落ちている（ダウンしている）状態を検知する意味。liveness が生存を確認するのに対し、ダウン検知は死活状態の反対を示します。
停止状態検知: コンテナやプロセスが停止している状態を検知する観点の表現。生存しているかを判定する liveness の反対のイメージです。
未起動検知: まだ起動していない、未稼働の状態を検知する観点。生存性を前提としない状態を示します。
非生存性検知: 生存していない状態を検知する抽象的な対義語。概念的な表現として捉えてください。
準備完了検知: Ready probe（準備完了検知）に近い概念。liveness とは異なるチェックで、リクエストを受け付ける準備が整っているかを判定します。対義語というより補完的な対概念です。