Observability

2025年版Kubernetesリソース管理の極意：デフォルト制限とHPAの先を行く

Kubernetesにおけるワークロードのプロファイル作成、CPU/メモリのリクエスト、制限、HPAを2025年に向けてマスターする方法—ベストプラクティス、YAMLスニペット、実際の事例を交えて解説。

Younes Hairej

11分2025年4月15日

A futuristic silhouette walks a glowing tightrope suspended above digital clouds and a neon grid, balancing two weights labeled “CPU” and “Memory,” with floating holographic tech icons surrounding the scene.

はじめに

Kubernetesにおけるリソース管理は常にバランスを取る事を考える作業が多々ありました2025年に向けてそのアプローチは変わりつつあります。クラスターが大規模化し、マルチテナント環境が増加する中で、単に任意のCPU制限やデフォルトのHPA設定を適用するだけではもはや十分ではなくなってきています。Aokumoでは、2つの極端な状況を目の当たりにしてきました。ひとつは、過度に厳しい制限によってスロットリングされたワークロード、もうひとつは「ノイジー・ネイバー（騒がしい隣人）」によってクラスターが不安定化するケースです。

では、どうすればこれらを回避できるのでしょうか？その秘密は、ワークロードを深く理解することにあります。それはCPU集中的なのか、メモリに依存しているのか、それともバースト処理が多いバッチジョブなのか、原因を理解するところから始まります。

そして次に必要なのは観測可能なデータに基づいてリクエスト、制限、オートスケーリングのルールを設定することです。

この記事では、CPU制限に関する議論、Horizontal Pod Autoscaler（HPA）の進化する役割、リソース設定の一般的な落とし穴、そして実践的なベストプラクティスを深掘りします。Aokumoの洞察やX（旧Twitter）での最新のコミュニティの議論を交えて解説します。

本記事は、リソース設定に関わるプラットフォームエンジニア、SRE、DevOps担当者に向けて書かれていますが、ITマネージャーにとっても、現場のチームが直面している課題の深刻さと調整の複雑さを理解する助けになるでしょう。

1. ワークロードパターンの理解

リクエスト、制限、HPAを設定する前に、まずは以下の質問に答えるための以下のような情報収集と分析をしましょう：

安定 vs. バースト: ポッドは起動時にスパイクしてから安定しますか？
CPU vs. メモリ依存: 数値処理をしているのか、大きなデータセットをメモリに保持していますか？
実行時間と同時実行数: 短期間で実行されるジョブがCPUを圧迫するのか、それとも長時間稼働するサービスが徐々に負荷をかけていくのか？

Aokumoのヒント: Prometheus（またはMetrics Server + カスタムエクスポーター）を統合し、ポッドごとのCPU/メモリの使用状況を数日間にわたって可視化します。繰り返し発生するスパイクを探しましょう。たとえば、多くのアプリケーションは起動時に300%のCPUを使い、その後50%に落ち着く場合があります。このようなパターンを観察して、リクエストが実際のベースラインを反映し、ピークだけを反映しないようにしましょう。

2. CPU制限の議論

制限が悪影響を与える理由

不必要なスロットリング: Kubernetesは制限を厳格に適用します。たとえば、ポッドが100mをリクエストし、200mを超えると制限されます。これにより、クラスタに余裕があってもレイテンシーがスパイクし、ライビネスプローブ（Liveness Probe）の失敗が発生することがあります。
誤ったリソース制限: 「3車線の道路があるにも関わらず車を1車線のみ1台だけ通すのは無駄な制限」ですね。道路は空いていて車は通るスペースがあるにも関わらず、リソースを使い切ることができないということが起こるように制限することが健康的なリソース使用を妨げます。

それでも制限が必要な場合

マルチテナンシーとノイジーネイバー: 1つのジョブが暴走すると、共有クラスタで他のテナントに大きな影響を与える可能性があります（SaaSプラットフォーム、内部開発/テストクラスタなど）。
規制された環境やコスト制限された環境: 一部のマネージドサービス（例: IBM Code Engine）では、請求や隔離のために制限が必要です。
ツールによるポリシー適用: RancherやPopeyeなどは、自動的に制限を挿入したり確認したりする場合があり、これを無効にするとその組織でのスタンダードに矛盾が生じる可能性があります。

マルチテナント環境での実装

マルチテナントクラスタでは、クリティカルなポッドに対してQoS=Guaranteed（リクエスト=制限）を設定し、排除時に優先されるようにします。スロットリングを最小限に抑えるために、リクエストの3倍などの寛容な制限を使用し、container_cpu_cfs_throttled_seconds_totalを監視して動的に調整します。また、ResourceQuotaを組み合わせて、名前空間ごとの使用量の上限を設定します。

コミュニティの見解

X（旧Twitter）では、Kubernetesのアーキテクトたちが、200～350%のCPU使用率を処理するために、CPU制限とHPAのどちらが最適かを積極的に議論しています。多くの人はピーク時にHPAを使いつつ、正確なリクエストを設定することを支持していますが、複数のテナントが共有する環境では制限が有用であると指摘しています。@k8s_engineerは「重要なのは、通常運用時にスロットリングを避けるために制限を高めに設定しリソース不足を防ぐために制限を低めに設定することだ」と述べています。

Aokumoの見解

「制限なし」をデフォルトにしないでください。代わりに、ワークロードを分析し測定に基づいて、許容可能な閾値を超える真の最悪のスパイクが確認された場合にのみ制限を適用してください。そして、常にスロットリングを監視してください（container_cpu_cfs_throttled_seconds_total）。

3. HPAとリソースリクエスト：適切に連携させる

HPA（Horizontal Pod Autoscaler）は、CPUのリクエストの割合に基づいてスケーリングを行います。リクエストが低すぎると、90%の使用率でも、余分に1つのポッドしかスピンアップしない場合があります。

正確なリクエスト = HPAの基盤: 履歴データやCAST AIなどのツールを使って、リクエストの推奨値を決めましょう。
K8s 1.30アップグレード: コンテナごとの安定したメトリックスにより、HPAは細かいデータを使用するようになり、ポッドの集計CPUを推測する必要がなくなります。
オートスケーラーの調整: 完全なリソース管理のために、HPA（水平スケーリング）とVPA（Vertical Pod Autoscaler）の「推奨」モード（リクエスト調整用）を連携させ、クラスターオートスケーラーがHPAによるスケーリングに対応できるようにして、保留中のポッドを防ぎましょう。

落とし穴: リクエストが設定されていない場合、HPAは何もしません（「未定義の使用率」）。 ヒント: HPAは常に適切なリクエストと組み合わせて使いましょう。例えば、サービスが約50mでアイドル状態にあり、ピークが500mの場合、リクエストを200mに設定し、ターゲットCPU利用率を60%に設定します。

4. よくある課題とその解決策

5. ベストプラクティスとツール

測定してから設定する

リクエストを設定する前に、72時間のCPU/メモリプロファイルを取得する。
可視化ダッシュボードで「開始時のスパイク」と「安定状態」を識別する。

可視化の設定

Prometheus、Grafana、AlertManagerを使用して、リソース使用量を追跡する完全なモニタリングスタックを導入する。
container_cpu_usage_seconds_total や container_memory_working_set_bytes を時間経過で表示するダッシュボードを作成する。
rate(container_cpu_cfs_throttled_seconds_total[5m]) のような重要なPrometheusクエリを設定して、スロットリングイベントを検出する。
管理された代替案として、Sysdig MonitorやDatadogを使用して、運用の負担を減らしながらより深いリソースのインサイトを得る。

リクエスト = 最小値、制限 = 安全網

リクエストは常に設定する。
孤立化が必要な場合にのみ制限を設定し、制限値は余裕を持たせる（例：リクエスト = 200m、制限 = 600m）。

HPAの調整

UWebサービスには、targetCPUUtilizationPercentage を 50～70% に設定する。
バッチやバーストジョブの場合は、カスタムまたは外部メトリクス（QPS、キューの長さなど）を検討する。
K8s 1.30では、複数のコンテナがあるポッドでも安定したコンテナ単位のメトリクスを活用する。
古いKubernetesバージョン（1.30以前）を使用している場合、ContainerResourceではなくResourceメトリクスを使用する。

プローブの設定

起動が遅いアプリケーションにはstartupProbesを追加し、早期の再起動を避ける。
periodSecondsやfailureThresholdを、実際の負荷パターンに合わせて調整する。

Rightsizing & Cost Optimization

CAST AIやKubecostなどのツールを使用して、リクエストと制限の自動推奨を得る。
Winter Soldier（Devtron）やvClusterの休止機能を使用して、非本番環境で「スリープモード」を自動化する。
過剰にプロビジョニングされたポッドを特定し、過去の使用状況に基づいてリクエストを20～40%削減する。
クラスターオートスケーラーを使用して、非重要なワークロードにスポットインスタンスを検討し、コストを削減する。

ポリシーとクォータ管理

名前空間ごとにLimitRangesを定義し、最小、最大、デフォルトのリクエスト/制限を設定する。
ResourceQuotasを実施し、誤ったチームがクラスターリソースを使い果たさないようにする。
マルチテナントクラスターでは、重要なポッドが「Guaranteed」QoSクラスを確保できるように適切な制限を設定する。

6. Code Examplesコードの例

1. 定性ウィンドウを使用したHPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-service-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-service
minReplicas: 3
maxReplicas: 12
metrics:
- type: ContainerResource
containerResource:
name: cpu
container: app # per-container metrics (K8s ≥1.30)
target:
type: Utilization
averageUtilization: 60
behavior:
scaleDown:
stabilizationWindowSeconds: 300 # wait 5 min before down‑scaling
policies:
- type: Percent
value: 20
periodSeconds: 60
scaleUp:
stabilizationWindowSeconds: 60 # wait 1 min before up‑scaling
policies:
- type: Pods
value: 2
periodSeconds: 60
- type: Percent
value: 50
periodSeconds: 60
selectPolicy: Max

2. ネームスペース LimitRange

apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
namespace: team-apps
spec:
limits:
- type: Container
default:
cpu: "400m"
memory: "512Mi"
defaultRequest:
cpu: "100m"
memory: "128Mi"
min:
cpu: "50m"
memory: "64Mi"
max:
cpu: "2000m"
memory: "2Gi"

7. 負荷テスト戦略

リソース設定とHPAの動作を負荷の下で検証するために、次のアプローチを検討してください:

合成HTTPテストツール（K6、Fortio、Locustなど）を使用して、実際のAPIトラフィックパターンをシミュレートする
リソース消費シミュレーターを使用して、CPU/メモリ使用量を直接ターゲットにする
ノードストレステストを実施して、リソースの圧力下でのPodの退避とQoSの動作を検証する

重要なのは、徐々に負荷をかけるテストと突然の負荷変化をテストし、設定がさまざまなトラフィックパターンに適切に反応するか確認することです。

8. ケーススタディ: ピークスタートアップワークロード

あるフィンテック顧客は、各Podで30秒間400％のCPUスパイクが発生し、その後60％に落ち着くデータ取り込みジョブを実行していました。リクエストを100m、リミットを200m、HPAターゲットを75％に設定していましたが、ポッドは初期化時に繰り返し再起動し、HPAは作動しませんでした。

Aokumoのアプローチ:

30秒のスパイクを測定 → startupProbeを60秒のタイムアウトで追加
リクエストを250m（平均+1σ）に引き上げ、リミットを600mに設定
HPAを新しいリクエストに基づき60％に調整

結果: 再起動ゼロ、負荷下で3→12ポッドへのスムーズなオートスケーリング、無駄なCPU使用を20％削減

結論

2025年には、すべてのリソース設定に一律の設定は通用しません。実際のワークロードパターンに基づいてリクエスト、リミット、HPAルールを設定することで、スロットリングを回避し、ノイジー・ネイバーを抑え、真のオートスケーリングを実現できます。

次のステップ:

１ワークロードを72時間プロファイルする

リミットを調整する前にベースラインのリクエストを設定する
コンテナごとのメトリクスを使用してHPAを調整する
CAST AI、Kubecostなどのツールでリソースの最適化を自動化する
アプリの挙動に合ったプローブを強化する

実践的な支援が必要ですか？AokumoのKubernetesの専門家による無料リソース監査をスケジュールし、クラスターを自己調整型パワーハウスに変えましょう。スロットリングの問題を特定し、コストを最適化し、ワークロードに最適なスケーリング戦略を実装するお手伝いをいたします。

まとめ