第4章：ノード/ランタイム運用
ノードはワークロードの実行基盤であり、kubelet とコンテナランタイム（例: containerd）を含みます。
本章では、ノードのライフサイクル管理と、ランタイム運用の論点を整理します。
学習目標
- Node の障害モード（NotReady、ディスク逼迫、OOM 等）と切り分け観点を説明できる
- ノード保守（パッチ、ドレイン、置き換え）の標準手順を定義できる
- ランタイム運用（イメージ、ログ、GC）の観点を整理できる
扱う範囲 / 扱わない範囲
扱う範囲
- kubelet の運用観点（状態監視、ログ、再起動、設定変更）
- containerd/CRI-O 等の運用観点（イメージ管理、ログ、GC）
- ノード保守（cordon/drain、ロールアウト、キャパシティ管理）
- ノードプール設計（ラベル/taint、分離の入口）
扱わない範囲
- OS チューニングの網羅（カーネルパラメータ等）
- 特定ディストリビューションの詳細手順
定義（この章の用語）
- Node: Pod が稼働する実行基盤（OS、kubelet、ランタイム等を含む）
- kubelet: Node 上で Pod を起動/監視するエージェント
- コンテナランタイム（CRI）: containerd/CRI-O 等。イメージ管理やコンテナ実行を担う
- drain: Node 上の Pod を退避させ、保守（パッチ/再起動/置き換え）を安全に実施するための操作
背景（なぜ重要か）
- ノード障害は頻度が高く、放置すると小さな劣化（ディスク逼迫等）が広範囲の障害に波及します。
- 運用の安全性は「手順の固定」と「段階的な実施」で決まります。属人化した保守は再現できません。
ノード運用の論点
- キャパシティ管理: CPU/メモリ/ディスク/Pod 数、IP 枯渇
- 保守: パッチ適用、再起動、置き換え（Immutable/AutoScaling との関係）
- 変更の安全性: drain、PDB、段階的な更新
- 観測性: Node/Runtime のメトリクス、ログ、イベントの集約
手順/例：ノード保守を Runbook 化する（最小）
- 事前確認: 影響範囲、PDB、退避先キャパシティ、実施順（ノードプール単位）を確認する
- 影響限定:
cordon/drainで退避し、必要なら段階的に実施する - 保守実施: パッチ/再起動/置き換え（方式は環境に依存。Immutable 方式も選択肢）
- 事後確認: Node Ready、主要ワークロードの復旧、監視の欠測がないことを確認する
- 証跡: 実施日時、対象ノード、実施内容、検証結果を記録する（変更管理）
判断の目安（例）:
- 一定時間 NotReady が継続し、原因が不明確な場合は「修理」より「置き換え」を優先します（MTTR を短くするため）。
- DiskPressure 等の逼迫は、暫定的に削減して復旧しても再発しやすいため、恒久的な対策（ログ/イメージ/容量設計）とセットで扱います。
失敗例（例）:
- PDB を確認せずに drain し、重要ワークロードが同時に停止する
- ノードを手作業で修理し続け、原因・再発防止が記録されない
代替案（例）:
- インプレース保守が難しい場合は、ノードを使い捨て（置き換え）前提の運用へ寄せます（ノードプール運用/自動修復の活用）。
注意点（運用）
- drain は「安全に退避できる」ことが前提です。PDB や分散配置が弱い場合は、先に設計/標準を見直してください。
- ノード上のログや Events は揮発しやすいため、障害調査に必要なログは集中管理しておきます（第9章）。
実務チェック観点（最低5項目）
- Node NotReady/ディスク逼迫/メモリ逼迫を早期検知する監視がある
- ノード保守手順（cordon/drain/置き換え）が Runbook 化されている
- ランタイムのイメージ GC/ログローテーションの運用方針がある
- ノードプール分離（重要系/汎用、GPU 等）が要件に基づき定義されている
- 障害時の暫定復旧（退避、隔離、スケールアウト）の判断基準がある
よくある落とし穴
- ノード保守が属人化し、手順/証跡が残らない
- ログ/イメージの肥大化でディスク逼迫が常態化する
まとめ / 次に読む
- 次に読む: 第5章：ネットワーク設計と運用