一般的な Kubernetes 終了コードの解釈

この記事はWeChatの公開アカウント「DCOS」から転載したもので、著者はzouyeeです。この記事の転載についてはDCOS公式アカウントまでご連絡ください。

1. 終了コード履歴

終了コードの歴史は、Unix オペレーティングシステムの初期の頃にまで遡ります。 Unix システムでは、プロセス終了コードは、プロセスが終了したときに親プロセスに渡される整数値であり、プロセスの終了ステータスを示すために使用されます。この整数値は通常 0 から 255 までで、0 はプロセスが正常に終了したことを示し、他の値は通常、さまざまなエラーや異常な状態を示すために使用されます。

プロセス終了コードは、もともと親プロセスが子プロセスの実行結果を理解するための簡単なメカニズムを提供するために設計されました。これにより、親プロセスは、エラー状態の処理や他の操作の続行など、子プロセスの終了コードに基づいて適切なアクションを実行できるようになります。

Unix システムでは、特定の終了コード値には通常、次のような特定の意味があります。

0: エラーなしで正常に実行されたことを示します。
1: 通常は一般的なエラーを示します。
2: コマンドの構文エラーを示します。
127: コマンドが見つからなかったことを示します。

Unix オペレーティングシステムが進化し、さまざまな実装が時間の経過とともに進化するにつれて、プロセス終了コードの意味は変化する可能性がありますが、基本的な概念は同じままです。

Linux システムでは、プロセス終了コードの使用方法は Unix システムの場合と同様です。 Linux は Unix のプロセス管理メカニズムを継承し、これを基に拡張および改善しています。したがって、Linux のプロセス終了コードは、プロセスの実行ステータスを理解して診断するのに役立つ重要な概念です。

プロセス終了コードの歴史は、初期の Unix システムにまで遡ります。これは Unix および Linux オペレーティングシステムにおける重要な概念であり、プロセス間通信のためのシンプルで効果的なメカニズムを提供します。アプリケーションまたはコマンドが致命的なエラーにより終了または失敗すると、128 シリーズの終了コード (128+n) が生成されます。ここで、n はシグナル番号です。 n SIGTERM、SIGKILL など、すべてのタイプの終了コードが含まれます。

2. 終了コード 127

終了コード 127 は Kubernetes 固有のエラーコードではなく、Linux や Unix 系オペレーティングシステムで使用される標準の終了コードです。もちろん、Kubernetes ではこれがよく見られますが、これは通常、コンテナ内で実行されているコマンドまたはバイナリが見つからなかったことを意味します。

標準的な終了コードには次のようなものがあります。

写真

一般的な原因

終了コード 127 の一般的な原因をいくつか見てみましょう。

コマンドまたはバイナリがインストールされていません。Kubernetes コンテナのコマンドフィールドに指定された実行可能ファイルが、コンテナのファイルシステムにインストールされていません。必要なバイナリまたはコマンドが利用可能であることを確認する必要があります。
パスまたはコマンドが正しくありません。Pod 定義で指定されたコマンドが正しくないか、指定されたパスに存在しません。これはエラーの最も一般的な原因の 1 つであり、通常は Dockerfile またはポッド仕様のエントリポイントまたはコマンド入力が正しくないことが原因で発生します。
依存関係が不足しています。コンテナー内で実行されているアプリケーションまたはスクリプトには、関連する依存関係がインストールされていません。必要な依存関係がすべてコンテナイメージに含まれていることを確認する必要があります。
スクリプトがシェルインタープリターコマンドとして指定されている場合は、スクリプトが有効 (たとえば、#!/bin/bash) であり、コンテナー内で使用可能であることを確認する必要があります。
シェルスクリプトの構文エラーシェルスクリプトがコード 127 で終了する場合は、スクリプトに構文エラーや実行を妨げる可能性のあるその他の問題がないか確認してください。
権限が不十分です。コンテナ内でコマンドを実行しているユーザーには、指定されたコマンドを実行するために必要な権限がない可能性があります。コンテナが適切な権限で実行されていることを確認してください。
イメージの互換性の問題使用するコンテナイメージがホストアーキテクチャおよびオペレーティングシステムと互換性があることを確認します。イメージが一致しないと、arm マシンで x86 イメージを実行するなど、コマンドが見つからない場合があります。
ボリュームマウントコマンドがボリュームにマウントされたファイルである場合は、ボリュームマウントが正しく構成され、必要なファイルにアクセスできることを確認します。
環境変数一部のコマンドは特定の環境変数に依存する場合があります。必要な環境変数が正しく設定されていることを確認してください。
Kubernetes RBAC ポリシー RBAC が有効になっている場合は、指定されたコマンドを実行するために必要な権限があることを確認する必要があります。

トラブルシューティング方法

問題をトラブルシューティングするには、次のコマンドを使用して Pod のログを確認します。

 kubectl logs -f <pod-name>

また、Pod のステータスを確認することもできます。これにより、Pod の現在の状態、最近のイベント、エラーメッセージなど、Pod に関する詳細情報が提供されます。

 kubectl describe pod <pod-name>

シェル (BusyBox など) を含むデバッグコンテナを Pod に接続することもできます。これにより、コンテナに入り、環境、パス、コマンドの可用性を手動で検査できます。

BusyBox を使用したデバッグの例:

 containers: - name: my-container image: my-image:latest command: ["/bin/sleep", "infinity"] - name: debug-container image: busybox:latest command: ["/bin/sh"] tty: true stdin: true

K8s の上位バージョンであれば、一時的なコンテナである Ephemeral Containers も使用できます。これは、Kubernetes v1.16 でアルファとして導入された新しい機能です。一時コンテナの機能を有効にすることも非常に簡単です。 kubernetes v1.16 以降のバージョンでは、kube-api および kubelet サービスに起動パラメータ --feature-gates=EphemeralCnotallow=true を設定し、再起動します。

ログを注意深く確認し、上記の指示に従ってトラブルシューティングを行うことで、終了コード 127 の問題の原因を特定できるはずです。

修正方法

終了コード 127 の一般的な原因とそのトラブルシューティング方法がわかったので、次にその修正方法を見てみましょう。

コマンドまたはバイナリがインストールされていません

必要なコマンドまたはバイナリが不足している場合は、コンテナイメージにインストールする必要がある場合があります。必要なソフトウェアをインストールするには、Dockerfile またはビルドプロセスを変更します。

例：

 FROM alpine:latest RUN apk --no-cache add <package-name>

パスまたはコマンドが正しくありません

Pod 定義でコマンドを指定する場合は、バイナリへの絶対パスを使用することを検討してください。これにより、現在の作業ディレクトリに関係なく、ランタイムがバイナリを見つけることができるようになります。

例：

 containers: - name: my-container image: my-image:latest command: ["/usr/local/bin/my-command"]

依存関係が欠落している

コマンドを実行できない理由は、コンテナイメージに追加のソフトウェアをインストールする必要があることが原因である可能性があります。コマンドに追加のセットアップまたはインストール手順が必要な場合は、メインコンテナが起動する前に init コンテナを使用してそれらのタスクを実行できます。

例 (init コンテナを使用してパッケージをインストールする):

 initContainers: - name: install-package image: alpine:latest command: ["apk", "--no-cache", "add", "<package-name>"] volumeMounts: - name: shared-data mountPath: /data

シェルインタープリタ

スクリプトをコマンドとして指定する場合は、スクリプトが有効であり (たとえば、#!/bin/bash)、コンテナー内で使用可能であることを確認してください。

例：

 #!/bin/bash

ボリュームマウント

Pod の構成をチェックして、ボリュームが正しくマウントされていることを確認します。ボリューム名、マウントパス、サブパスが正しいことを確認します。

例：

 volumes: - name: my-volume emptyDir: {} containers: - name: my-container image: my-image:latest volumeMounts: - name: my-volume mountPath: /path/in/container

同時に、Pod 定義で指定されたボリュームが存在し、使用可能であることを確認する必要があります。永続ボリューム (PV) の場合は、そのステータスを確認する必要があります。 emptyDir またはその他のタイプのボリュームの場合は、正しく作成およびマウントされているかどうかを確認する必要があります。ボリュームマウントでサブパスが使用される場合は、指定されたサブパスがソースディレクトリまたはファイルに存在することを確認する必要があります。

例：

 volumeMounts: - name: my-volume mountPath: /path/in/container subPath: my-file.txt

3. 終了コード 137

Kubernetes では、終了コード 137 はプロセスが強制的に終了されたことを示します。 Unix および Linux システムでは、プロセスがシグナルによって終了すると、終了コードはシグナル番号に 128 を加えた値で決定されます。シグナル番号は 9 で、これは「SIGKILL」を意味するため、128 に 9 を加えると終了コードは 137 になります。

Kubernetes クラスター内のコンテナがメモリ制限を超えると、Kubernetes システムによって「OOMKilled」エラーで強制終了されることがあります。これは、メモリ不足のためにプロセスが強制終了されたことを示します。このエラーの終了コードは 137OOM で、「メモリ不足」を意味します。

Pod のステータスが「OOMKilled」と表示される場合は、次のコマンドで確認できます。

 kubectl describe pod <podname>

OOMキラー

OOMKiller は、メモリを大量に消費するプロセスを強制終了することで、システムのメモリ不足を防ぐ Linux カーネルのメカニズムです。システムのメモリが不足すると、カーネルは OOMKiller を呼び出して、メモリを解放し、システムの実行を継続するために強制終了するプロセスを選択します。

カーネルには 2 つの異なる OOM Killer があります。 1 つはグローバル OOM Killer であり、もう 1 つは cgroup メモリコントローラベースの OOM Killer (cgroup v1 または cgroup v2) です。

簡単に言えば、カーネルが物理メモリページの割り当てで問題に遭遇すると、グローバル OOM Killer がトリガーされます。カーネルがメモリページを割り当てようとして (カーネル用か、ページを必要とするプロセス用かのいずれか)、最初は失敗すると、カーネルはさまざまな方法でメモリを再利用して整理しようとします。この試行が成功するか、少なくとも何らかの進捗があった場合、カーネルは割り当ての再試行を継続します。ページを解放できなかったり、処理が進まなかったりすると、多くの場合、OOM Killer がトリガーされます。

OOMKiller は終了するプロセスを選択すると、そのプロセスに正常に終了するように要求する信号を送信します。プロセスがシグナルに応答しない場合、カーネルはプロセスを強制的に終了し、そのメモリを解放します。

注: メモリの問題により終了したポッドは、必ずしもノードから削除されるわけではありません。再起動ポリシーが「常に」に設定されている場合、ポッドの再起動が試行されます。

システムレベルでは、Linux カーネルはホスト上で実行されている各プロセスの oom_score を維持します。プロセスが強制終了される可能性は、スコアの高さによって異なります。

oom_score_adj 値を使用すると、ユーザーは OOM プロセスをカスタマイズし、プロセスを強制終了するタイミングを定義できます。 Kubernetes は、Pod のサービス品質 (QoS) を定義するときに oom_score_adj 値を使用します。

K8s は、Pod に対して 3 種類の QoS を定義しており、それぞれに対応する oom_score_adj 値があります。

保証: -997
ベストエフォート: 1000
バースト可能: min(max(2, 1000 — (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

Pod が QoS 保証型の場合、その oom_score_adj 値は -997 なので、ノードのメモリが不足すると最後に終了される Pod になります。 BestEffort Pod は値 1000 に設定されているため、最初に終了します。

Pod の QoS を表示するには、次のコマンドを使用します。

 kubectl get pod -o jsnotallow='{.status.qosClass}'

以下は、PodGuaranteed QoS タイプを定義するコンピューティングポリシーです。

Pod 内の各コンテナには、メモリ制限とメモリ要求が必要です。
Pod 内の各コンテナのメモリ制限は、メモリ要求と同じである必要があります。
Pod 内の各コンテナには、CPU 制限と CPU 要求が必要です。
ポッド内の各コンテナの CPU 制限は、CPU 要求と同じである必要があります。

終了コード 137 には、次の 2 つの一般的な状況があります。

1. 最も一般的な理由は、リソースの制限に関連しています。多くの場合、Kubernetes はコンテナに割り当てられたメモリ制限を超えます。

2. 別のケースは手動介入です。ユーザーまたはスクリプトがコンテナプロセスに「SIGKILL」シグナルを送信し、この終了コードが生成されます。

トラブルシューティング方法

ポッドログを確認する

OOMKilled エラーを診断する最初のステップは、Pod ログをチェックして、メモリ関連のエラーメッセージがあるかどうかを確認することです。

 kubectl describe pod <podname> State: Running Started: Fri, 12 May 2023 11:14:13 +0200 Last State: Terminated Reason: OOMKilled Exit Code: 137 ...

Pod ログをクエリすることもできます。

 cat /var/log/pods/<podname>

もちろん、（標準出力）を使用することもできます。

 kubectl logs -f <podname>

メモリ使用量の監視

Prometheus や Grafana などの監視システムを使用して、Pod とコンテナのメモリ使用量を監視します。これにより、どのコンテナがメモリを過剰に消費し、OOMKilled エラーをトリガーしているかを特定できます。コンテナホスト上で dmesg を使用して、その時点の oomkiller シーンを表示することもできます。

メモリアナライザの使用

pprof などのメモリプロファイラーを使用して、過剰なメモリ使用の原因となっている可能性のあるメモリリークや非効率的なコードを特定します。

修正方法

OOMKilled Kubernetes エラーの一般的な原因とその修正方法を以下に示します。

コンテナのメモリ制限に達しました

これは、コンテナーで指定されたメモリ制限設定が正しくないことが原因である可能性があります。解決策としては、メモリ制限の値を増やすか、負荷増加の根本原因を調査して修正することです。一般的な原因としては、特に Pod 内で複数のコンテナが実行されている場合に大量のメモリリソースを消費する可能性がある大きなファイルのアップロードや、トラフィック量の急増などが挙げられます。

アプリケーションのメモリリークによりコンテナのメモリ使用量が上限に達しました

メモリリークの原因を突き止めるには、アプリケーションをデバッグする必要があります。

すべてのポッドで使用されるメモリの合計がノード上の使用可能なメモリを超えています

ノード上の使用可能なメモリを増やすことでノードメモリを増やすか、より多くのメモリを持つノードに Pod を移行します。ノード上で実行されているポッドのメモリ制限を調整して、メモリ制限内に収まるようにすることもできます。 Pod が使用するメモリの最小量を指定するメモリ要求設定にも注意する必要があることに注意してください。設定値が高すぎると、使用可能なメモリが効率的に使用されない可能性があります。リソース割り当てに関する提案については、「VPA コンポーネント」を参照してください。

メモリ要求と制限を調整する際、ノードが過負荷になると、Kubernetes は次の優先順位で Pod を終了します。