1. 導入：なぜリソース設定が重要なのか
Kubernetes環境において、Podのリソース設定は「システムの安定性」と「コスト最適化」の両面で最も重要なタスクの一つです。RequestsとLimitsを適切に定義しないと、特定のPodがノードのリソースを独占して他のPodを圧迫する「騒がしい隣人問題（Noisy Neighbor）」が発生したり、メモリ不足による意図しない強制終了（OOMKilled）が頻発したりします。本記事では、実務でトラブルを未然に防ぐためのリソース管理の勘所を解説します。
2. 基礎知識：RequestsとLimitsの役割
Kubernetesのリソース管理には、大きく分けて2つの指標があります。
Requests（予約量）：Pod起動時に最低限保証されるリソース量です。スケジューラはこの値を元に、どのノードにPodを配置するかを決定します。
Limits（最大制限）：Podが消費可能なリソースの上限です。CPUはこれを超えるとスロットリングされ、メモリはこれを超えるとOOMKilled（Out Of Memory）が発生してPodが停止します。
これら設定値の組み合わせにより、Podの「QoSクラス（Quality of Service）」が決まります。最も優先度が高いのはRequestsとLimitsが等しい「Guaranteed」クラスであり、本番環境のクリティカルなサービスではこの設定が推奨されます。
3. 実装と解決策
実務では、アプリケーションの負荷テストを行い、適切なベースラインを測定した上で設定値を決定します。まずは以下のYAMLをテンプレートとして活用してください。
4. サンプルプログラム：リソース制限を定義したDeployment
以下は、推奨されるリソース設定を適用したマニフェスト例です。
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-service
spec:
replicas: 3
selector:
matchLabels:
app: api-service
template:
metadata:
labels:
app: api-service
spec:
containers:
- name: app-container
image: my-app:latest
resources:
requests:
# 起動時に確保する最小リソース（スケジューリングの基準）
cpu: “250m”
memory: “512Mi”
limits:
# バースト時の上限値（これを超えるとCPU制限またはOOMKilled）
cpu: “500m”
memory: “1Gi”
# ライフサイクル管理のヒント：Podの準備完了を正しく制御する
readinessProbe:
httpGet:
path: /healthz
port: 8080
5. 応用・注意点：現場で陥りやすい罠
実務でリソース設定を行う際、以下の点に注意してください。
CPUの単位について：「m」はミリコアを指します。「500m」は0.5コアを意味します。CPUはスロットリングが発生しても即座にクラッシュはしませんが、アプリケーションのレスポンス遅延に直結します。
メモリのOOMKilled回避：メモリはCPUと異なり、Limitsを超えた瞬間にカーネルによってプロセスが停止されます。JavaやNode.jsなどのGC（ガベージコレクション）を行う言語では、LimitsをJVMのヒープサイズよりも少し余裕を持って設定することが重要です。
Vertical Pod Autoscaler (VPA) の活用：手動設定が難しい場合は、VPAの推奨値機能を使って、実際の稼働実績に基づいたRequests/Limitsの推奨値を取得し、マニフェストにフィードバックする運用を推奨します。
適切なRequests/Limits設定は、インフラエンジニアにとっての「守り」の要です。まずは監視ツールで現在のリソース消費傾向を可視化することから始めてみてください。
コメント