【ITニュース解説】How I find and fix Kubernetes Exit Codes and Misconfigurations for free

システムエンジニアを目指す皆さんにとって、現代のITインフラを支える技術の一つであるKubernetesは、非常に強力なツールである。しかし、その多機能さゆえに、一度問題が発生すると原因を特定し、解決するのは容易ではない。特に、稼働中の複雑なシステムでは、重要な警告信号が膨大な量のログやイベントの情報の陰に隠れてしまい、見つけ出すのが困難な場合が多い。アプリケーションが停止してしまう前に、これらの信頼性に関わる問題を事前に検知できれば、運用は格段に楽になるだろう。

Preq（プリークと読む）は、まさにそのような課題を解決するために作られたオープンソースツールだ。これは、Kubernetesにおける信頼性問題を見つけ出す検出器として機能し、クラスターのログ、イベント、設定を、コミュニティで共有されている「失敗パターンカタログ」（Common Reliability Enumerations、略してCRE）と照らし合わせてチェックする。Preqを使うことで、設定ミスや一般的なアンチパターン、バグといった問題の兆候を早期に捉え、夜中の急なトラブル対応に追われることなく、あらかじめ対処できるようになる。

Preqのインストールは非常に簡単で、KubernetesのプラグインマネージャーであるKrewを通じて行う。Krewがセットアップされていれば、kubectl krew install preqという一つのコマンドを実行するだけで、すぐにPreqが利用可能になる。特別な設定は不要で、最新のCREルールが組み込まれており、ルールも自動で更新されるため、常に最新の問題パターンに対応できる。

Preqはkubectlプラグインとして提供されるため、インストール後はkubectl preqコマンドを通じて直接実行できる。これにより、様々なKubernetesリソースとそのログをスキャンすることが可能だ。例えば、特定のPodのログや関連イベントをチェックしたい場合はkubectl preq my-pod-abc123と入力する。Preqは、そのPodのログやイベントをCREルールライブラリと照合する。Serviceを対象にする場合、kubectl preq service/my-serviceと実行すると、そのServiceが管理するPodを特定し、それらのPodのログやイベントを検査して既知の問題がないかを確認する。JobやCronJobに関しても同様で、これらのリソースやそれらが作成するPodの実行ログやイベントを詳しく調べられる。PreqプラグインはKubernetes APIを利用しているため、ログやイベントが関連付けられているあらゆるリソースタイプに対して柔軟に機能し、問題を検出できる。

現在のPreqのリリースは主にログとマニフェスト（設定ファイル）の検査を対象としているが、工夫すれば設定ファイルやクラスターイベントにも活用できる。ConfigMapを直接スキャンしたい場合は、kubectl preq -n <namespace> configmap/<name-of-config-map>のようにコマンドを実行する。また、KubernetesのイベントをストリーミングでPreqにフィードすることも可能で、これは特定のkubectl get eventsコマンドとjqを組み合わせることで実現できる。ConfigMap以外のDeploymentのようなワークロード設定ファイルも、特定の形式に変換してPreqに渡すことでスキャンが可能だ。

Preqの核となるCREには、コミュニティメンバーによって作成された多くの障害パターンが登録されている。具体的な例をいくつか挙げよう。「CRE-2025-0119」は、アップデート中に多数のPodがダウンし、ロールアウトが停止したり、利用可能なレプリカが不足したりする問題を示す。「CRE-2025-0071」は、CoreDNSに準備ができていないPodやエンドポイントがない場合に、クラスターのDNS解決が失敗するパターンを指し、CoreDNSの利用可能なレプリカがゼロになったり、PodがCrashLoopBackOff状態になったりする兆候が見られる。「CRE-2025-0048」は、コントロールプレーンがノードの完全修飾ドメイン名（FQDN）を解決できないために、ワーカーノードがNotReady状態になる問題である。そして「CRE-2025-0125」は、Podの急速な起動中にkubeletがクラッシュし、ノードがNotReadyになり、Podの退避を伴うノードレベルの完全な停止を引き起こす深刻な問題を示す。

特に、コンテナが予期せず終了する際の「終了コード」は、システムエンジニアにとって重要な情報源だ。Preqは、これらの一般的な終了コードに対するCREルールも提供しており、コンテナがクラッシュした原因を特定するのに役立つ。

終了コード「137」は、通常、プロセスがSIGKILLシグナルによって強制終了されたことを意味する。Kubernetesでは、これは多くの場合、コンテナが割り当てられたメモリ制限を超過し、OSのOOM（Out Of Memory）キラーによって強制終了されたことを示唆する。Podのステータスで「Reason: OOMKilled」と表示されていれば、この可能性が高い。この問題の解決策は、コンテナのメモリ制限と使用状況を確認し、kubectl top podコマンドでメモリ使用量が多いPodを特定することだ。メモリ制限を増やすか、アプリケーション自体を最適化してメモリ使用量を減らすことが必要となる。Preqは、頻繁なOOMキルを警告することで、ユーザーに影響が出る前に対応を促す。

終了コード「127」は、「コマンドが見つからない」ことを意味する。これは、コンテナ内でプロセスが実行しようとしたファイルやコマンドが、コンテナのファイルシステム内に存在しない場合に発生する。コンテナの起動コマンドやエントリポイントが間違って設定されている際によく見られるエラーだ。kubectl describe podコマンドでPodの詳細を確認すると、Kubernetesが「command not found」に関するメッセージをイベントログに記録していることが多い。解決策は、コンテナの仕様やDockerfile内のコマンドを修正し、イメージに必要なプログラムが正しい場所に存在することを確認することである。Preqは、イベントや終了メッセージ内の「exited with code 127」や一般的なエラーテキストをスキャンすることで、この問題を早期に検出できる。

終了コード「134」は、プロセスがSIGABRT（アボートシグナル）を受け取ったことを示す。これは、アプリケーション自身がクラッシュしたことを意味し、多くの場合、アサーションの失敗やabort()関数の呼び出し、あるいは致命的なエラーの後に終了させられた場合に発生する。解決策としては、コンテナのログを調べて、終了直前のエラーメッセージやスタックトレースを確認することが重要だ。Preqは、この134という終了コードの発生を強調し、それが既知のパターンであるかどうかを指摘してくれる。

そして、終了コード「139」は、悪名高いセグメンテーション違反（SIGSEGV）を示す。これは、プロセスがアクセスすべきではないメモリ領域にアクセスしようとした際に（無効なポインタ、バッファオーバーフローなど）、OSによって強制終了された状態である。これは、ほとんどの場合、アプリケーションコード（または使用しているライブラリ）のバグが原因で発生する。対処としては、アプリケーションログの確認や、デバッグのためにコアダンプを有効にすることが主な手段となる。Preqは、この139という終了コードが発生したことを警告してくれるが、コードのバグ自体を修正することはできない。しかし、クラッシュを見逃さないように確実に知らせてくれる点は非常に価値がある。

これらの終了コードを持つPodをクラスター全体で迅速にスキャンするには、特定のjqフィルターとpreqを組み合わせたコマンドを使うことができる。このコマンドは、終了したPodの状態から終了コード、終了時刻、Podの名前などを抽出し、Preqにフィードして検出を行う。

Preqを日々のワークフローに組み込むことは、問題がダウンタイムを引き起こす前に捕捉できるという理想的な状況を実現し、問題の平均検出時間（MTTD）を大幅に短縮できる。例えば、CI/CDパイプラインにPreqを統合し、新しいアプリケーションのデプロイ後にその名前空間や新しいPodに対してkubectl preqを実行するステップを追加することを検討できる。また、定期的なプロアクティブスキャンとして、kubectl preq -jコマンドでCronJobのテンプレートを生成し、これを活用してPreqコマンドを定期的に実行するように設定することも可能だ。さらに、インシデントや障害が発生した際には、もしそれが新しいタイプの問題であれば、新しいCREルールを作成し、コミュニティに貢献することも考慮すべきだ。Preqのフレームワークは、一度解決した問題を二度と繰り返さないように、その知識をルールとして体系化することを可能にする。

まとめとして、PreqはKubernetesユーザーにとって強力な味方となるツールだ。コミュニティが蓄積してきた障害モードに関する豊富な経験を、オンデマンドで実行可能な実用的な洞察へと変換してくれる。PreqをCI/CDパイプライン、定期的なスキャン、そしてトラブルシューティングセッションに組み込むことで、問題がユーザーに影響を及ぼすインシデントに発展する前に、プロアクティブに検出し、解決できるようになるだろう。

なお、もし、多数のノードやクラスターにわたる分散検出エンジン、Web UI、インシデント追跡などのより深い統合、分散エンジン管理のためのコントロールプレーン、そして独自のCREルールセットといった、エンタープライズ向けの機能に興味があれば、商用版のPrequelも存在するので、そちらも検討してみる価値がある。