Kubernetesは現代のクラウドネイティブアーキテクチャにおいて不可欠なコンテナオーケストレーションツールであり、アプリケーションの高可用性とスケーラビリティを実現するための基盤を提供します。本記事では、Podの再起動処理における技術的課題と、レジリエンスを確保するためのベストプラクティスを解説します。特に、Podの終了フロー、多コンテナ環境での制御、HTTPサーバーの graceful shutdown およびコントローラーのリーダー選挙最適化など、Kubernetesの內部メカニズムを深く掘り下げます。
KubernetesはPodの終了を通知する際、SIGTERMシグナルを送信します。デフォルトでは、grace periodが30秒と設定されており、アプリケーションがこの期間內に終了処理を完了しなければ、SIGKILLで強制終了されます。ただし、eviction APIやノードリソースの制限によって、設定されたgrace periodが無視される可能性があります。また、主コンテナとsidecarコンテナは同時に終了し、sidecarは起動順序の逆順で終了します。
Kubernetes 1.29以降、sidecarコンテナの終了順序を制御できるようになりました。終了時に起動順序の逆順で実行されるため、リソース解放の順序を明確にできます。ただし、すべてのコンテナが同じgrace periodを共有するため、すべてのコンテナがその期間內に終了処理を完了する必要があります。
graceful shutdownを実裝しても、Kubernetesが終了シグナルを送信する前に流量を古いPodにルーティングする可能性があります。これにより、リクエストのロスが発生するリスクがあります。これを迴避するには、pre-stop hookで終了を遅延させ、readiness probeで新Podの就緒を確認する必要があります。また、startup probeを用いて起動フェーズと通常フェーズの探針を區別することで、起動時の過剰な健康チェックを防ぎます。
リーダー選挙はListリソースを用いて実行され、デフォルトではleaderElectionDurationが15秒、retryPeriodが2秒です。leaderElectionReleaseOnCancelを有効化し、終了時にリーダー権を放棄することで、切換時間を3秒に短縮できます。ただし、leaderElectionDurationを短すぎるとsplit brainのリスクが高まるため、適切なバランスが求められます。
PDBは、再起動中に不可用になるPodの數を制限する機能です。例えば、最大1つのPodが不可用になるように設定することで、ノードメンテナンスや流量切換時の可用性を確保できます。ただし、PDBは予備Podを自動的に作成しないため、少なくとも2つのPodが存在する必要があります。また、minAvailableを0に設定すると、Podが起動できない場合、メンテナンス操作が妨げられる可能性があります。
SIGTERMを処理し、grace period內にクリーンアップを完了する必要があります。terminationGracePeriodSecondsを設定し、pre-stop hookで終了を遅延させ、readiness probeで流量切換を確実にする。startup probeとreadiness probeを區別し、起動フェーズの過剰なチェックを迴避。KubernetesにおけるPodの再起動処理は、アプリケーションのレジリエンスと可用性を確保する上で不可欠です。信頼性の高い設計には、graceful shutdownの実裝、リーダー選挙の最適化、PDBの適切な設定が重要です。これらの技術を組み合わせることで、クラウドネイティブ環境での安定した運用が可能になります。