PR：この記事にはアフィリエイトリンクが含まれます。
Kubernetesの本番運用ではPodの起動確認に加え、通信を受けてよい状態か、負荷に応じて何個動かすか、CPUやメモリをどこまで使わせるかを一緒に考えます。設定同士が連動するためです。
Probeが失敗してPodがReadyにならないと、HPAが台数を増やしても応答は戻らないことがあります。Helmから配る設定も同じ流れに関わります。
| 本 | 内容と対象読者 | 発行年・ページ | 定価目安（税込） |
|---|---|---|---|
 Kubernetesの知識地図 —— 現場での基礎から本番運用まで | 基礎から本番運用まで。IaCやGitOps、更新、スケーリング、監視を含む全体像を整理したい人向け | 2023年・304ページ | 2,970円 |
 Kubernetesパターン 第2版 ― クラウドネイティブアプリケーションのための再利用可能パターン | Probe、リソース設計、Pod優先度、容量計画と水平・垂直・クラスタの自動スケール。基本を学んだ人向け | 2024年・392ページ | 3,960円 |
 Kubernetesで実践するクラウドネイティブDevOps | Helmからrequestsとlimits、ProbeやResourceQuotaを経てHPAとVPA、kubectlでの調査まで | 2020年・384ページ | 3,850円 |
 実践Helm─自作アプリをKubernetesクラスタに簡単デプロイ！ | Helmの基本、既存Chart、自作Chart、SubChart。Helmを集中的に学びたい人向け | 2019年・170ページ | — |
 Docker/Kubernetes実践コンテナ開発入門 改訂新版 | DockerからKubernetes配備、Helm・ロギング・高可用性・CIとCD・負荷テストまで | 2024年・600ページ | 3,960円 |
価格は税込定価を目安にしています。実際の販売価格は時期や店舗で変わるので、購入時には最新価格を確認してください。
運用は連鎖する
DeploymentはPod数と更新を管理し、Serviceは利用可能なPodへ通信を流します。Probeが通信対象を判定し、HPAがメトリクスからレプリカ数を調整します。連携する役割分担です。
起動直後のアプリがReadyにならない場合は、ProbeとCPU使用量を確認します。CPU不足で初期化が遅いならrequestsやlimitsも見直すところです。症状と設定を結び付けて考えたいですよね。
HelmはChartに設定をまとめて配布し、リリース単位で更新します。一か所を直しても次のリリースで値が戻ることがあります。Probeやリソース、HPAとの関係も追える形にしておくと、変更箇所を把握しやすくなります。
Probeの役割
Liveness Probeはコンテナ内のプロセスが動き続けているかを調べます。失敗が設定したしきい値を超えるとkubeletがコンテナを再起動するため、応答不能やデッドロックの検知に使います。
Readiness ProbeはPodがサービスの通信を受けてよい状態かを見ます。失敗中のPodはServiceの接続先から外れますが、コンテナの再起動はしません。起動中や一時的な処理待ちにも関係する判定です。
起動に時間がかかるアプリではStartup Probeが役立ちます。Startup Probeが成功するまでLivenessとReadinessの判定は始まりません。起動の遅さを異常終了と誤認しにくくする設定です。
Probeの間隔やタイムアウト、失敗回数を厳しくしすぎると、負荷上昇を障害と見なして再起動を繰り返します。外部データベースの一時停止までLivenessで判定すると、復旧を待つアプリが再起動される場合があります。
リソース管理
requestsはPod配置に必要なCPUとメモリの基準です。スケジューラは主にrequestsを見てノードを選ぶため、実使用量より大きく設定すると空きがあってもPodを配置できないことがあります。
CPUのlimitsを超えた処理はスロットリングを受けます。メモリのlimitsを超えたコンテナはOOMKilledになる可能性が高まります。同じ上限でもCPUとメモリでは挙動が異なります。
requestsは実使用量やHPAの目標を見ながら調整します。CPUのrequestsはHPAが使用率を計算する際の基準です。実態と大きくずれるとスケール判断も変わります。負荷試験や実測値を手掛かりに見直しましょう。
ResourceQuotaを設定するとNamespace全体で使えるリソース量やPod数に上限を設けられます。チーム間の使い過ぎを防げる一方、上限に達すれば新しいPodは作れません。配置に失敗したらイベントでクォータ到達を確認します。
HPAの動作条件
HPA（Horizontal Pod Autoscaler）はCPUやメモリなどのメトリクスに応じてPod数を調整します。CPU使用率を目標にする場合は実使用量とrequestsの比率が判断材料になります。
メトリクスの取得にはMetrics APIが必要です。CPUのrequestsが未設定のコンテナを含むPodではCPU使用率を計算できず、その指標を使ったHPAの判断が適切に働かない場合があります。現在値と取得エラーを一緒に確認します。
HPAでは最小・最大レプリカ数を指定でき、急な増減を抑えるルールも設定できます。スケールダウンを安定させると、短時間の負荷低下でPodが減りすぎるのを防げます。
HPAでPod数を増やしても、空きノードがなければPendingのままです。クラスタオートスケーラーによるノード拡張も確認し、配置状況とサービス遅延を追います。ReadyにならないPodはProbeや起動時間も調べます。
Helmのリリース
Helm ChartではKubernetesのマニフェストをテンプレート化し、環境ごとの値を渡してリソースを作成します。共通テンプレートと環境別のvaluesを分ければ、検証環境と本番環境の差を追いやすくなります。
Chartのバージョンやイメージタグを固定すると、同じリリースを再現しやすくなります。更新時はレンダリング結果を見て変更内容を確かめてから適用しましょう。変更範囲を絞れば問題の原因を追いやすくなります。
HPAを使うDeploymentではHelmのvaluesに固定レプリカ数を書き続けると、アップグレード時にHPAと競合する場合があります。台数をHPAに任せるならChart側でspec.replicasを出力しない設計が有効です。
Helmのリリース履歴から前の構成へ戻せます。ただし、データベースのスキーマや外部システムへの変更は自動で戻りません。アプリ、DB、設定の更新手順と戻し方を確認しておきましょう。
障害を調べる
利用者の症状と発生時刻を確認してからDeployment、Pod、Serviceの状態を追います。kubectl describeやイベントから、Probe失敗やイメージ取得、配置不能の理由を確認できます。
再起動が続くときは終了理由とコンテナログを確認します。OOMKilledではメモリ上限と実使用量、CPUスロットリングではlimitsと負荷を調べます。同じ遅延でも、原因によって直す設定は違うんですよね。
HPAの現在値と目標値から負荷への反応を確認します。レプリカ数とPodのReady状態を見れば、メトリクス取得の状況も分かります。PodがPendingならノード容量やResourceQuotaを調べましょう。
更新後はrollout完了に加えて、エラー率や遅延、再起動回数を確認します。リソース使用量も記録し、Helm更新前後の変更点を確かめれば、原因と戻す対象を絞れます。
結論
Probeが通信可否を判断し、requestsとlimitsが配置や実行の枠を作ります。HPAはメトリクスを見てPod数を調整し、Helmのリリース設計が変更の再現性を支えます。
障害時は再起動数に加えてイベントやログ、リソース使用量を確認し、HPAの判断とPodの配置先も照らし合わせます。変更後は遅延とエラー率を見届けましょう。ここまでが運用です。
Kubernetesの基本を学び終えてProbe、HPA、Helmを実務につなげたいなら、『Kubernetesで実践するクラウドネイティブDevOps』を第一候補にしてください。設計原則をさらに深める段階では『Kubernetesパターン 第2版 ― クラウドネイティブアプリケーションのための再利用可能パターン』を加えると、学びを運用判断に結び付けられます。
Amazon の PC をスコア化してみた
Amazonにある8〜14インチの小型WindowsタブレットやノートPCを、スペック別にスコア化して比較・ランキング。
