Pod リソース設定の最適化（過剰予約・逼迫・未設定の改善）

概要

クラスター全体（104 Pod / 19 Namespace）のリソース使用状況を調査した結果、以下の問題が確認されました。

---

🔴 リソース逼迫・OOM リスク

1. prometheus（monitoring）— メモリ逼迫

• Request: 1536Mi / Limit: 2Gi
• 実使用: 〜987Mi〜1.01GiB（Limit の約 50%）、スパイク時に 1.07GiB（Limit の 53%）
• 今後データ量が増えると OOM リスクあり
• 推奨: Limit を 3Gi に引き上げるか、データ保持期間・スクレイプ間隔を見直す

2. mimir-distributed-ingester-0（monitoring）— メモリ変動大

• Request: 512Mi / Limit: 2Gi
• 実使用: 通常 〜547〜593Mi、直近1時間で 675MiB まで急上昇
• 推奨: Request を 600Mi 程度に引き上げてスケジューリングの安定性を確保

3. beyla（monitoring）— メモリ Request に対して実使用が大幅超過

• Request: 128Mi / Limit: 384Mi
• 実使用: 〜251〜330MiB（Request の約 2〜2.5倍、Limit の 65〜86%）
• Limit に近い状態で稼働しており、OOM リスクが高い
• 推奨: Request を 256Mi、Limit を 512Mi 以上に引き上げる

4. kustomize-controller（flux-system）— CPU throttling 発生

• Request: 100m / Limit: 1000m
• 実使用: 〜13m（通常は低い）
• CPU throttling 率: 6.96%
• 推奨: バースト時の挙動を継続監視

5. node-exporter（monitoring）— CPU throttling 発生

• Request: 25m / Limit: 200m
• 実使用: 〜0.8m（非常に低い）
• CPU throttling 率: 最大 21.6%（wssxm ノード）
• スクレイプ時のバーストが原因と推測
• 推奨: Limit を 300m 程度に引き上げる

---

🟡 リソース過剰予約（コスト削減余地）

1. flux-system 各コントローラー（helm / image-automation / image-reflector / notification / source）

• Request: 100m CPU / 64Mi メモリ、Limit: 1000m CPU / 1Gi メモリ
• 実使用 CPU: 0.4〜3.5m（Request の 0.4〜3.5%）
• 実使用メモリ: 17〜36MiB（Request の 26〜56%）
• CPU Request が実使用の 30〜250倍
• 推奨: CPU Request を 10〜20m、Limit を 200m 程度に削減

2. keycloak-0（keycloak）— CPU 過剰

• Request: 500m / Limit: 1500m
• 実使用 CPU: 〜1m（Request の 0.2%）
• 推奨: CPU Request を 50〜100m に削減

3. cloudnative-pg（cloudnative-pg）— CPU 過剰

• Request: 100m / Limit: 100m（Guaranteed QoS）
• 実使用 CPU: 〜2.3m（Request の 2.3%）
• 推奨: CPU Request/Limit を 20m 程度に削減（Guaranteed QoS を維持する場合は Request=Limit のまま値を下げる）

4. keda 各コンポーネント（keda）

• Request: 100m CPU / 100Mi メモリ、Limit: 1000m CPU / 1000Mi メモリ
• 実使用 CPU: 0.2〜1.9m（Request の 0.2〜1.9%）
• 実使用メモリ: 10〜32MiB（Request の 10〜32%）
• 推奨: CPU Request を 10〜20m、メモリ Request を 32〜64Mi に削減

5. metrics-server（kube-system）— メモリ過剰

• Request: 200Mi / Limit: 1Gi
• 実使用メモリ: 〜24MiB（Request の 12%）
• 推奨: Request を 32Mi、Limit を 128Mi 程度に削減

---

⚪ リソース未設定（BestEffort QoS）

以下のコンテナは Request/Limit が未設定のため、ノードのリソース逼迫時に最初に OOM Kill される可能性があります。

コンテナ	Namespace	実使用メモリ（参考）
karpenter controller	karpenter	〜192MiB
cilium-agent	kube-system	〜168〜269MiB
aws-load-balancer-controller	kube-system	〜35〜48MiB
cilium-envoy	kube-system	—
cilium-operator	kube-system	—
eks-pod-identity-agent	kube-system	—
hubble-relay	kube-system	—
hubble-ui	kube-system	—
external-dns	external-dns	—
keycloak-db-1 postgres	keycloak	—
config-reloader サイドカー	monitoring	—

特に karpenter・aws-load-balancer-controller・cilium-agent は重要なインフラコンポーネントのため、Request/Limit の設定を強く推奨します。

---

対応優先度サマリー

優先度	分類	主なコンテナ	推奨アクション
🔴 高	OOM リスク	beyla, prometheus	Limit 引き上げ
🔴 高	CPU Throttling	node-exporter, kustomize-controller	CPU Limit 引き上げ
🔴 高	未設定（重要コンポーネント）	karpenter, cilium-agent, aws-load-balancer-controller	Request/Limit 追加
🟡 中	CPU 過剰予約	keycloak, flux-system, keda, cloudnative-pg	CPU Request 削減
🟡 中	メモリ過剰予約	metrics-server	メモリ Request/Limit 削減
⚪ 低	未設定（その他）	external-dns, hubble-* 等	Request/Limit 追加

---

元スレッド: https://panicboat.slack.com/archives/C0BQE7KHUCE/p1786922296196709?thread_ts=1786922296.196709&cid=C0BQE7KHUCE