再起動・4倍の遅延・デプロイ中の502――Kubernetesで自分のサービスだけが不調なとき、障害8パターンを自分で再現して修正する

Kubernetes入門の次は、自分のサービスに不調が起きたとき。

再起動・遅延・502・止まったデプロイといった症状だけを見て、kubectlと指標から原因を特定して修正します。ノートPC上のローカルKubernetesで障害を8種類発生させ、修正後に同じ負荷をかけて前後の数値を測定します。

Kubernetesの講義の多くは、クラスターを構築して機能を一つずつ学びます。この講義では、すでに誰かが構築してくれたKubernetes上で、自分のサービスに不具合が起きたときの対処を扱います。症状（再起動・遅延・5xx・空の応答・停止したデプロイ）の一つから始め、どの層の問題なのかをkubectlとカーネルの指標で絞り込み、修正後、同じ負荷をかけて前後の数値を測ります。画面に表示される数値やメッセージはすべて、実習環境で実際に実行した際の出力です。

この講義を終えると

• 再起動するPodでlastStateからOOMKilled・終了コード137を確認し、アプリのログに理由が残らないのはなぜかを説明します。

• JVMヒープ上限とコンテナのメモリ制限を調整し、無言の強制終了ではなく、アプリ自身が知らせるようにします。

• 停止していないのに遅くなったサービスで、cpu.stat を使って CPU スロットリングを直接数え、kubectl top の平均値に惑わされません。

• 生存・準備・起動のプローブを区別し、起動の遅いアプリの再起動ループを止めます。

• 404・502・503・504を見て、応答した主体（Ingressかアプリか）を切り分け、パスの書き換え・Serviceセレクター・ポート・DNS名の問題を特定します。

• 自動スケーリング（HPA）が追いつくまでの時間を計測し、最小台数で備えるとともに、終了猶予とドレインによってデプロイ中の停止をゼロにします。

• シークレットキーの誤記で停止したデプロイを、rollout statusと進行期限で見つけ出します。

このような方におすすめです

• Kubernetes入門講座を受講し、今度はKubernetes上で自分のサービスに異常が起きたとき、原因を突き止めたいバックエンド開発者

• クラスターは他のチームが運用し、自分はマニフェストとアプリだけを担当する開発者

• 障害のたびに「インフラの問題ですか？」と尋ねて、待つだけだった方

カリキュラム（7セクション・40講義・約300分）

• セクション0. 最初の成功：5分で最初の障害 — 完成デモ：Loop Marketの障害8件を症状だけを見て解決、5分で最初の原因を特定：再起動を繰り返すcatalogはOOMKilled、実習環境とチェックポイント：up.shとcheckpoint.sh、kubectlの最低限の武器：get・describe・events・logs --previous、診断の流れをまとめた1枚と進行ボード：症状 → 層 → コマンド

• セクション1. メモリ・JVM — OOMKilledはどのように起きるのか：コンテナのメモリ上限、アプリのログに残らない理由：exit 137とlastState、JVMメモリ＝ヒープ＋それ以外：MaxRAMPercentage、修正と確認：上限内でヒープを設定、再起動前→後、メモリ要求量と上限：割り当てと制限、セクションの確認：解決した障害1/8、再起動回数の前→後

• セクション 2. CPUスロットリング — 障害2の再現：誰も停止していないのに遅延が4倍、CPUリクエスト量と上限：100ms周期と割り当て量、cpu.statでスロットリングを直接カウント、topは38mなのになぜ遅いのか：平均の落とし穴、修正と前後の測定：遅延・スロットリングの修正前→後、上限をなくすか引き上げるか：判断基準とセクションの確認（2/8）

• セクション3. 検査と再起動 — 障害4の再現：新バージョンだけ75秒で4回再起動、readiness・liveness・startupの違い、イベントから原因を読み解く方法と旧バージョンが耐えた理由、startupProbeでの修正と再起動前→後（3/8）、applyで戻したのに残った設定：replaceとロールバックの落とし穴

• セクション4. リクエスト経路と名前 — 障害1の再現：昨日まで動いていた /catalog が404、Ingress → Service → Podをたどる、診断して修正：パスの書き換え（4/8）、Serviceのセレクターがずれてエンドポイントが空になった場合、502・503・504 — 誰が応答したのか、障害7の再現：アドレスの入力ミス catalog-api とDNS名のルール（5/8）

• セクション5. オートスケーリングとデプロイ — 障害5を再現：負荷が集中したのに最初の30秒は1台、HPAの計算式：リクエスト量に対するパーセンテージ、なぜ遅れるのか：メトリクスの周期とスケーリングの判断、Podの起動は2秒、対策：最初から最低3台で開始、p95 885ms → 457ms(6/8)、障害6を再現：デプロイ中に12件の失敗、ドレイン・終了猶予で失敗12件 → 0件(7/8)

• セクション6. 設定・キャップストーン — 障害8の再現：シークレットキーの誤記と停止したデプロイ、停止したデプロイを見つける：rollout statusとmaxSurge（8/8）、キャップストーンの案内：診断チェックリスト1枚、キャップストーンA：初見の障害セットを一人で診断する、キャップストーンB：複合した症状を一人で診断する、キャップストーンの解答と全体の変更前→変更後、次のステップ

実習環境

実習では、ノートPC上のローカルKubernetes（kind）に、仮想ショッピングモール「ループマーケット」の2つのサービス（catalog・order）を立ち上げます。up.shを一度実行するだけで、クラスター・Ingress・メトリクス収集・サービスが起動し、checkpoint.shを使えば、各講義の開始状態をすぐに再現できます。障害注入スクリプト8個、キャップストーン用の障害セット2個、負荷ツール、診断チェックリストが実習教材に含まれています。

事前知識

• Pod・Deployment・Serviceについて聞いたことがある（入門講座レベル）

• ターミナルでコマンドを実行した経験

• Dockerが動作するMacまたはLinux（DockerにCPU 4個・メモリ6GB以上を推奨）

この講義で扱わないこと

• クラスターのインストール・運用（kubeadm、ノード管理）

• Helm・デプロイツール・サービスメッシュ

• 分散トレーシング・オブザーバビリティツールの構築

• クラウドマネージドKubernetesの設定

案内

動画のナレーションはAI合成音声です。画面上のコマンド・指標・結果は、実習環境で実際に実行した際の出力です。すべてのデータは教育用の仮想データであり、数値は実行環境によって異なる場合があります。