Kubernetesは柔軟性と効率性を約束していますが、多くのエンジニアにとって、リソースリクエストとリミットの管理は強力なマシンの微調整というよりも、頑固な官僚主義との格闘のように感じられます。

一見空いているクラスターが単一のPodのスケジューリングを拒否したり、一見「アイドル状態」のワークロードが悲惨なほどスロットルされる理由に疑問を持ったことがあるなら、あなたは一人ではありません。

Kubernetesコミュニティはこれらの不満について声高に語ってきました。Redditでは、「Podリクエストが私を狂わせている」のようなスレッドに、リソースの誤設定、奇妙なスケジューラの決定、さらにはアプリをクラッシュさせようと決意したかのような垂直Pod自動スケーラー（VPA）の推奨事項について不満を漏らす数十人のエンジニアが集まっています。

この記事では、これらの実話をいくつか紹介し、その背後にあるYAMLを示し、正気を保つためのいくつかのガードレールを提案します。

ストーリー1：「私のPodはアイドル状態なのにスロットルされている」

あるエンジニアは、CPU使用率が低いにもかかわらず、Podのパフォーマンスが低下している理由が分かりませんでした。原因はCPUリミットでした。Podがリソースを十分に活用していなくても、リミットに達するとスロットリングがトリガーされることがあります。

問題のYAML：

apiVersion: v1
kind: Pod
metadata:
  name: throttled-app
spec:
  containers:
    - name: app
      image: my-app:latest
      resources:
        requests:
          cpu: "500m"
          memory: "256Mi"
        limits:
          cpu: "500m"   # hard cap == request
          memory: "256Mi"

ここでは、リクエストとリミットが同じ値です。CPUスケジューラはバーストを許可しないため、短時間のスパイクでもスロットリングが発生します。

より良いアプローチ：

resources:
  requests:
    cpu: "500m"
    memory: "256Mi"
  limits:
    cpu: "1"         # allow burst above baseline
    memory: "512Mi"

ストーリー2：「VPAがクラスターを爆発させた」

別の投稿では、Vertical Pod Autoscaler（VPA）が理論上は良さそうに見える値を推奨したものの、ワークロードを不安定にしたことが説明されていました。場合によっては、メモリリクエストが急増し、スケジューラが他のPodを退避させることになりました。

YAMLの例（VPAが生成する可能性のあるもの）：

resources:
  requests:
    cpu: "4"       # way higher than actual baseline
    memory: "8Gi"  # overestimation leads to wasted nodes

突然、すべてのPodが重量級になりたがり、クラスターはワークロードを効率的にパッケージングできなくなりました。

対策：

• まずVPAを推奨モードで実行する：

updatePolicy:
  updateMode: "Off"   # only suggest, don't apply

• 実際のメトリクス（Prometheus、Datadog など）と推奨事項をクロスチェックする。

ストーリー3：「スケジューラが私のリクエストでテトリスをプレイする」

よくある不満は、リクエストが利用可能なノードの形状と一致しないためにPodが保留状態のままになることです。あるRedditユーザーは、わずかに大きすぎるメモリリクエストによって、集約すれば十分なリソースがあるにもかかわらず、Podがスケジュール不可能になった経験を共有しました。

スケジュール不可能なPod：

resources:
  requests:
    cpu: "200m"
    memory: "5Gi"   # no node had exactly this much free memory

その間、クラスターには2〜3Giの未使用のギャップがたくさんありました。

学んだ教訓： リクエストはクラスター全体の容量ではなく、ノードに適合することが重要です。これは機内の頭上収納スペースに荷物を詰めるようなものです：少し大きすぎるスーツケースは、飛行機が半分空いていても収まりません。

ストーリー4：「ガードレールと現実のバランスを取る」

一部のエンジニアは、ベストプラクティスからではなく、絶望から単純にすべてのリクエストとリミットを同一に設定していると告白しました。これは簡単ですが、多くの場合有害です：Podを硬直した形状に閉じ込め、スケジューリングの柔軟性をブロックし、スロットリングを保証してしまいます。

代わりに、いくつかの実用的なルールが役立ちます：

• 小さく始める：リクエストは基本的な定常状態の使用量を反映すべきです。
• リミットは慎重に使用する：ハードな保護が必要な場合のみ（例：マルチテナント環境）。
• 観察して反復する：メトリクス駆動のチューニングは推測よりも優れています。

結論：コントロールとカオスのバランス

Kubernetesのリソース管理は公平性と予測可能性をもたらすために設計されました。しかしRedditコミュニティが示すように、多くの場合、それは逆に感じられます：無駄、スロットリング、そして予測不可能性です。

教訓は何でしょうか？デフォルト設定や「ベストプラクティス」を盲目的に従わないことです。本番環境でリクエスト、リミット、VPA、QoSと格闘してきたエンジニアたちの話に耳を傾けましょう。そして、そのコミュニティの苦労から得た知恵を、自分自身のメトリクスとテストと組み合わせてください。

リソースリクエストはまだあなたを悩ませるかもしれませんが、少なくともあなたが一人ではないことを知ることができます—そして今、CloudPilot AIを導入してカオスを制御する手助けを得ることもできます。

💡 朗報： CloudPilot AIの新しいインテリジェントワークロードオートスケーラーは、再起動なしでPodを自動的に適切なサイズに調整し、クラスターが効率的かつ確実に実行されるようにします。コストを継続的に最適化し、アプリケーションのパフォーマンスを向上させ、SREチームを手動調整から解放します。

早期アクセスベータ版を開始しました — あなたのプラットフォーム/SREチームはあなたに感謝するでしょう！