Kubernetes 入門コース / Chapter 11

Kubernetesの運用監視

Probe・resources・メトリクス・ログを別の信号として読み、Podの正常性・資源・スケールを根拠付きで判断する章です。

この章で学ぶこと
  1. Readinessは配信可否、Livenessは再起動判断を担う。
  2. requestsは配置とHPA比率、limitsは利用上限を決める。
  3. 状態・Events・logs・metricsを同じ時系列で照合する。

01Probeは配信停止と再起動を分けて扱う

ReadinessはServiceから外す判定、Livenessはkubeletによる再起動判定である。

ReadinessとLivenessの役割の違い
失敗しても即座に同じ挙動にはならない。配信可否と再起動の目的を分けて設定する。

Readiness失敗中のPodはServiceのEndpointsから外れる。Liveness失敗はコンテナの再起動へつながるため、両者に同じ軽い確認だけを設定しない。

判断できるようになること:Probeは配信停止と再起動を分けて扱う。

02requests・limitsが配置とスケールの前提になる

requestsは必要量の宣言、limitsは使える上限。HPAはrequestsを基準に利用率を見る。

requests・limitsとHPAの関係
requestsを決めずにHPAの割合だけを見ると、スケール判断の土台がない。

schedulerはrequestsでNodeに配置できるかを判断する。CPUのlimit超過はスロットリング、メモリlimit超過はOOMKillにつながり得る。

判断できるようになること:requests・limitsが配置とスケールの前提になる。

03証跡を重ねて障害とスケールを判断する

単一コマンドで結論を出さず、Kubernetesの状態・イベント・アプリログ・利用量を照合する。

Pod障害を調べる証跡
画面が失敗した事実と、Kubernetesがなぜその状態にしたかを分けて読む。

`kubectl top`で傾向、`describe`でKubernetesの判断、`logs`でアプリ内部を確認する。HPAは`describe hpa`で目標と現在値、増減のEventsを確認する。

判断できるようになること:証跡を重ねて障害とスケールを判断する。

章のまとめ

  1. Readinessは配信可否、Livenessは再起動判断を担う。
  2. requestsは配置とHPA比率、limitsは利用上限を決める。
  3. 状態・Events・logs・metricsを同じ時系列で照合する。