NetflixはKubernetes環境における「孤立したPod問題」にどう取り組んでいるのか：カーネルパニック発生をnetconsoleで可視化

Kubernetes環境における孤立したPodとは何なのか。Netflixのエンジニアが孤立したPodの問題にどう取り組んでいるのか解説した。

[＠IT]

　Netflixでエンジニアのカイル・アンダーソン氏は2023年10月28日（米国時間）、エンジニアの苦労を軽減させる取り組みの一環として、Kubernetes環境における「孤立したPod（Orphaned Pod）」にどう取り組んでいるのか、公式ブログで解説した。

　Netflixは、同社が内製し、オープンソースで公開しているコンテナ管理プラットフォーム「Titus」を活用しており、Kubernetesと連携させてアプリケーションの実行やデプロイに取り組んでいる。孤立したPodの問題に取り組むことは、バッチを実行するエンジニアにとって「Podが終了してしまったが、バッチを再度実行して問題ないのか？」といった苦労を軽減することにもつながるとする。

　アンダーソン氏は、Kubernetes環境において孤立したPodが生まれる原因を解説し、問題に対する取り組みを紹介した。

Kubernetesにおける「孤立したPod」とは？

　Kubernetes環境における孤立したPodとは、Kubernetesクラスタの管理や監視のプロセスから切り離された状態にあるPodのことだ。KubernetesのNodeが何らかの理由で利用できなくなると、Node上で稼働していたPodは孤立した状態になり、最終的にはKubernetesのガベージコレクションにより削除される。

　Titusでは、カスタムコントローラーを実行してNodeとPodの履歴を保存し、ユーザーに表示する仕組みがある。NodeやPodが消失したことを表示する仕組みもあったが、アンダーソン氏にとっても閲覧するエンジニアにとっても納得できる画面ではなかったという。

KubernetesのNodeとPodが消滅したことを示す画面（提供：Netflix Technology Blog）

なぜNodeが削除されるのか

　アンダーソン氏によると、主にパブリッククラウド環境では、Kubernetesのクラウドコントローラーがサーバの実体（例えばAmazon EC2インスタンス）が何らかの理由でなくなったことを検知すると、コントローラーがNodeを削除するため、そのNode上のPodが孤立した状態になってしまうという。

　そこでNetflixでは、Nodeが終了した原因となる情報をPodに共有する方法として以下のアノテーションを導入した。

{
     "apiVersion": "v1",
     "kind": "Pod",
     "metadata": {
          "annotations": {
               "pod.titus.netflix.com/pod-termination-reason": "Something really bad happened!",
...

アノテーションのイメージ

　「pod.titus.netflix.com/pod-termination-reason」を導入してPodが消えた理由を記録する。ガベージコレクションコントローラーにこのアノテーションを認識させたり、予期せず消失する可能性のある全てのNodeやPodにも同様のアノテーションを追加したりしている。

　pod-termination-reasonアノテーションで、以下のようなアノテーションを付与することで、後でエンジニアが何が起きたのか判別するのに役立つという。

• This pod was preempted by a higher priority job ($id) （このPodは優先順位の高いジョブ ($id) に先取りされた）
• This pod had to be terminated because the underlying hardware failed ($failuretype)（基盤となるハードウェアに障害が発生したため($failuretype)、このPodは終了する必要があった）
• This pod had to be terminated because $user ran sudo halt on the node（$userがNode上でsudo haltを実行したため、このPodは終了した）

　だがアノテーションの仕組みを活用しても、カーネルパニックが起きた場合には対応できなかった。そこでアンダーソン氏は、カーネルパニックが起きたことを記録に残すため、Google Spannerの「カーネルパニック時にUDPパケットを送信する」という論文に触発され、Linuxの標準モジュールであるnetconsoleを活用することにした。

カーネルパニックを記録に残すnetconsoleの設定

　netconsoleは、事前にほとんどのIPヘッダが設定されている必要があり、送信元および送信先のMAC、IPおよびUDPポートを指定する必要がある（netconsole-setupコマンドを使用すると設定できる）。また設定オプションは動的に変更でき、エンドポイントが変更された場合に新しいIPを示すことができる。

Kernel panic - not syncing: buffer overrun at 0x4ba4c73e73acce54
[ 8374.456345] CPU: 1 PID: 139616 Comm: insmod Kdump: loaded Tainted: G OE
[ 8374.458506] Hardware name: Amazon EC2 r5.2xlarge/, BIOS 1.0 10/16/2017
[ 8374.555629] Call Trace:
[ 8374.556147] <TASK>
[ 8374.556601] dump_stack_lvl+0x45/0x5b
[ 8374.557361] panic+0x103/0x2db
[ 8374.558166] ? __cond_resched+0x15/0x20
[ 8374.559019] ? do_init_module+0x22/0x20a
[ 8374.655123] ? 0xffffffffc0f56000
[ 8374.655810] init_module+0x11/0x1000 [kpanic]
[ 8374.656939] do_one_initcall+0x41/0x1e0
[ 8374.657724] ? __cond_resched+0x15/0x20
[ 8374.658505] ? kmem_cache_alloc_trace+0x3d/0x3c0
[ 8374.754906] do_init_module+0x4b/0x20a
[ 8374.755703] load_module+0x2a7a/0x3030
[ 8374.756557] ? __do_sys_finit_module+0xaa/0x110
[ 8374.757480] __do_sys_finit_module+0xaa/0x110
[ 8374.758537] do_syscall_64+0x3a/0xc0
[ 8374.759331] entry_SYSCALL_64_after_hwframe+0x62/0xcc
[ 8374.855671] RIP: 0033:0x7f2869e8ee69
...

netconsole設定後にカーネルパニックが起きたときに送信されるUDPパケットのイメージ（1行につき1つのUDPパケット）

　アンダーソン氏は、netconsoleを設定後、以下の手順でKubernetesと連携させたという。

1. ポート6666でnetconsoleのUDPパケットを把握し、Nodeのカーネルパニックを監視する
2. カーネルパニックが発生したら、受信したnetconsoleパケットのIPアドレスに関連するKubernetesのNodeを調査する
3. 該当するNode上のPodに、カーネルパニックが起きたというアノテーションを付与し、Podを削除する
4. 3と同様にNodeにも実行する

　これにより、カーネルパニックが検出されると、PodとNodeが即座に終了するため、ガベージコレクションの処理を待つ必要もなくなり、PodやNodeに何が起きたか可視化するのにも役立ったという。

KubernetesのNodeとPodがカーネルパニックにより消滅したことを示す画面（提供：Netflix Technology Blog）

　アンダーソン氏は最後に「『カーネルパニックが原因でジョブが失敗した』ことは、エンジニアにとってうれしいものではない。しかし、カーネルパニック問題の修正を始めるのに必要な、システム全体の動作を監視する仕組みや、問題を理解して修正するために不可欠なツールや手段があると分かれば、エンジニアも満足するだろう」と述べている。