/
Kubernetesリソース計算機
カテゴリ

Kubernetesリソース計算

PodのCPU・メモリ要件をリアルタイムに試算・可視化するKubernetesリソース計算ツールです。完全クライアントサイド解析により、機密マニフェストも安全にサイジングできます。

QoS判定エンジン
クラウド予約領域
構成プリセット
運用モード

ワークロードプロファイラー

基準CPU使用量
450m (0.45 cores)
クイック選択
基準メモリ使用量
1,536 MiB (1.50 GiB)
クイック選択
QoS設計戦略
Burstable
CPU Limit/Request比率2.00x
メモリLimitバッファ+25%
クラウド事業者
最大Pod数
DaemonSet CPU
DaemonSet メモリ
Podリソース要求の補足: 563m / 1,920Mi
6 Pod総数
必要ノード数1ノードm6i.xlarge
Podリソース要求563m CPU1,920 MiB RAM
適用QoSクラスBurstableadj: 883
月額推定コスト$140.16730 月間稼働時間
単一ノード割当可能リソース配分図
4 vCPU / 16 GiB Raw
CPU配分バランス (Total: 4000m)割当可能枠: 3670m (91.8%)
Kube-Reserved: 80mDaemonSet Overhead: 250mWorkload Pods: 3378m空きリソース（Slack）
kube-reserved (80m)DaemonSet (250m)Podワークロード (3378m)空きリソース（Slack）
メモリ配分内訳 (Total: 16384 MiB)割当可能枠: 13022 MiB (79.5%)
Kube-Reserved RAM: 2762MiBDaemonSet RAM: 600MiBWorkload RAM: 11520MiB空きリソース（Slack）
kube-reserved (2762 MiB)DaemonSet (600 MiB)Podワークロード (11520 MiB)空きリソース（Slack）
Podサイジング診断
制約ボトルネックBalanced / Density Aligned
CFSスロットリング状態Moderate (Burst headroom available)
エビクション動作Medium (Protected up to request ceiling)
AST構文解析ステータス
フォーマット形式: VISUALIZER
主要メトリクス
3.38 vCPU単位 / 11.25 GiB
6 稼働レプリカ数
リソース効率・収容力
92.0% コア / 88.5% RAM単位
Balanced / Density Aligned
実効リソース配分量
$140.16
1 台の m6i.xlarge

完全ブラウザ内処理

すべての高速演算はブラウザのメモリ上でのみ完結し、軽快に動作します。

サーバー送信ゼロの安全性

入力データや構成定義は端末内に保持され、外部サーバーへの通信は一切発生しません。

本番環境対応エクスポート

最適化されたマニフェスト形式で出力され、そのまま本番クラスタにデプロイ可能です。

技術リファレンス・アーキテクチャガイド

Kubernetes Resource Calculator & Pod Sizing ガイド — 技術リファレンス

クライアントサイドでのリアルタイム解析および可視化機能を備えたインタラクティブなKubernetesリソース計算ツール（Pod CPU・メモリサイジング設計）。

Kubernetes Resource Calculator & Pod Sizing ガイド — 技術リファレンス — クライアントサイド完全ローカル実行アーキテクチャ図
Kubernetes Resource Calculator & Pod Sizing ガイド — 技術リファレンス — クライアントサイド完全ローカル実行アーキテクチャ図

主要パラメータと設定項目

ベースラインPod CPUコア使用率（P95ミリコア）ミリコア（mCPU）/ vCPU小数値

コールドスタート時の異常値を除外し、本番環境の定常トラフィック下で7日間のPrometheusまたはDatadog観測ウィンドウから取得した95パーセンタイル（P95）持続CPUコア負荷。Linux CFS（Completely Fair Scheduler）の100msクォータ集約周期に照らして評価されます。

初期値: 250m
ピークヘッドルーム＆日内変動バーストバッファ率（%）パーセンテージ（%）

Request_CPU = Baseline_CPU * (1 + Headroom_Percent / 100) で算出される動的安全マージン。本番環境のSRE（Site Reliability Engineering）ベストプラクティスでは、Podのエビクション（強制退去）やノードレベルのスケジューリング失敗を防ぎつつ日内トラフィックの急増を吸収するため、20%〜30%のヘッドルーム確保が推奨されています。

初期値: 25%
ベースラインPodワーキングセットメモリ（RSS + アクティブキャッシュ）メガバイト（MiB）/ ギガバイト（GiB）

Kubernetesの container_memory_working_set_bytes メトリックから取得されるアクティブなRSS（Resident Set Size）および回収不能メモリ。回収可能なページキャッシュとは異なり、Linux cgroup v1/v2のメモリプレッシャー制御がトリガーされる前の実質的なベースライン閾値となります。

初期値: 512Mi
対象PodのQoSクラス仕様Kubernetes QoSクラス（Guaranteed | Burstable | BestEffort）

Linuxカーネルの oom_score_adj スコアを決定するQoS（Quality of Service）クラス。Guaranteedは cpu.limits == cpu.requests かつ memory.limits == memory.requests を満たす必要があり、oom_score_adj は-997〜-998（エビクション優先度が最も低い）が割り当てられます。Burstableは requests < limits（動的 oom_score_adj: 1000 - 1000 * mem_req / node_mem）、BestEffortは両方とも未指定（oom_score_adj: 1000、最初にエビクション対象）となります。

初期値: Burstable
対象ワーカーノードのインスタンス仕様コンピュートインスタンス種別（vCPU / GiB RAM）

ホストのベアメタルまたは仮想マシンのハードウェア仕様（例: 8 vCPU・32 GiB RAMのAWS m6i.2xlarge、またはGCP n2-standard-8）。クラウドプロバイダーの段階的控除式 Allocatable = Raw_Capacity - Kubelet_Reserved - System_Reserved - Eviction_Hard_Threshold (100Mi) に基づき、実割り当て可能容量（Allocatable）が算出されます。

初期値: 8 vCPU / 32 GiB RAM
デプロイメントの水平レプリカ数整数（Pod数 / スケールターゲット）

アベイラビリティゾーン間の高可用性およびN+1 / N+2耐障害冗長性を確保するための目標レプリカ数。ワーカーノードのビンパッキング計算に直接影響します: Nodes_Needed = max(ceil(Total_CPU_Req / Allocatable_CPU), ceil(Total_Mem_Req / Allocatable_Mem), ceil(Total_Replicas / Effective_Max_Pods))。

初期値: 12

現場のベストプラクティス・実践Tips

マルチスレッドランタイムでCFS CPU Limitsを撤廃しP99レイテンシ急落を防止

'resources.limits.cpu' を定義すると、Linux Completely Fair Scheduler（CFS）のクォータ機構（100msの cpu.cfs_period_us 周期に基づく cpu.cfs_quota_us）が有効化されます。マルチスレッドランタイム（GoのGoroutine、JVMのGCスレッド、Node.jsのワーカープールなど）は、ノード内の全vCPUに並行してタスクを分散します。たとえば8スレッドが同時に12.5ms実行されると、実時間わずか13ms程度で100ms分のクォータを消費し尽くし、Linuxカーネルは残り87msの間プロセス全体を強制スロットリングします。これにより、ホストノードのCPU使用率が20%程度であるにもかかわらず、人為的なP99レイテンシスバイクや上流タイムアウトが発生します。低レイテンシが要求されるマイクロサービスにおけるSREベストプラクティスは、P95実績値＋ヘッドルームに見合った十分なCPU requestsを設定し、CPU limitsは設定せず未指定（無制限）のままとし、メモリリーク対策としてメモリlimitsのみ厳格に設定することです。

GKE/EKSのノードAllocatableサイジングに段階的控除曲線を適用

クラスタの総キャパシティをハードウェアの公称仕様（Rawスペック）のまま算出することは絶対に避けてください。クラウドプロバイダーは公式の段階的計算式に従ってシステム予約分を控除します: 予約メモリ（Reserved_RAM）= 最初の0〜4GiBの25% + 4〜8GiBの20% + 8〜16GiBの10% + 16〜128GiBの6% + 128GiB超過分の2%、さらに100MiBのハードエビクション閾値が差し引かれます。例えば32 GiBのワーカーノード（AWS m6i.2xlargeやGCP n2-standard-8等）では、25%(4) + 20%(4) + 10%(8) + 6%(16) + 0.1GiB = 1.0 + 0.8 + 0.8 + 0.96 + 0.1 = 3.66 GiB が差し引かれ、実際の割当可能メモリ（Allocatable RAM）は約28.34 GiBしか残りません。ビンパッキング計算でこの控除を考慮しないと、ノード起動負荷によるPodの即時プリエンプションやスケジューリング待ち（Pending）が頻発します。

高密度ノード設計におけるAWS VPC CNIのMaxPods IP枯渇を回避

クラスタのノード必要数は、CPUやメモリの不足だけでなく、CNIネットワークインターフェースの制約によってボトルネックとなるケースが多々あります。デフォルトのAWS VPC CNIプラグイン環境では、EC2インスタンスあたりの最大Pod数はENI（Elastic Network Interface）の制限によって決まります: MaxPods = (ENI数 - 1) * (ENIあたりIPv4アドレス数 - 1) + 2。例えばm6i.large（2 vCPU, 8 GiB）は最大3つのENI、各ENIあたり10個のIPしかサポートしないため、コンテナがどれほど軽量であってもノードあたり最大29 Podに制限されます。Nodes_Needed = max(ceil(Total_CPU_Req / Allocatable_CPU), ceil(Total_Mem_Req / Allocatable_Mem), ceil(Total_Replicas / Effective_Max_Pods)) でワーカーノード数を計算する際、実効MaxPods上限を考慮しないと、計算リソースに空きがあるにもかかわらず残りのレプリカがスケジューリング不能になる事態を招きます。

固定oom_score_adjを持つGuaranteed QoSでステートフルデータストアを保護

メモリ不足（メモリプレッシャー）が発生した際、LinuxカーネルのOOM Killerは /proc/[pid]/oom_score に基づいて終了対象プロセスを評価します。KubernetesはPodのQoSクラスを oom_score_adj にマッピングします。Guaranteed Pod（cpu.limits == cpu.requests かつ memory.limits == memory.requests）には -997 または -998 が付与され、カーネル自体が致命的なメモリ枯渇に陥らない限りエビクションから実質的に保護されます。Burstable Podには max(floor(1000 * mem_request / node_capacity), 1000 - 1000 * mem_request / node_capacity) で算出される2〜999の動的スコアが割り当てられ、BestEffort Podは 1000 に固定されて即座に強制終了されます。ノードのメモリ枯渇による連鎖フェイルオーバーを防ぐため、PostgreSQL、Redis、Kafka、Ingress ControllerなどのクリティカルなPodは必ずGuaranteedとして設定してください。

ブラウザ内暗号的サンドボックスとO(n)確定論的ビンパッキングシミュレーション

ゼロトラストインフラストラクチャのプライバシーを担保するため、リソースサイジングおよび多次元ベクトルビンパッキングシミュレーションは、O(n)計算量のFirst-Fit-Decreasingアルゴリズムを用いてクライアント側のブラウザランタイム内でのみ実行されます。クラスタのリソーストポロジ、Podリソース定義、レプリカ数はクライアントメモリ内に完全にサンドボックス化され、配置エントロピー生成にはWeb Crypto APIの暗号論的擬似乱数生成器（CSPRNG）プリミティブを活用しています。サーバー側へのテレメトリ送信や外部ログ出力は一切発生せず、SOC 2 Type IIおよびRFC監査済みの機密性基準に完全準拠しています。

よくある落とし穴とトラブルシューティング

⚠️アプリメトリクス上はメモリ上限未満であるにもかかわらずPodが終了コード137（OOMKilled）で停止する

終了コード137は、SIGKILL（128 + 9）によってプロセスが強制終了されたことを示します。この問題は、アプリケーションランタイム（Node.jsのヒープやGoのランタイムメモリなど）が報告する仮想メモリや管理対象ヒープ使用量と、Linuxカーネルのcgroup v1/v2メモリコントローラが監視する container_memory_working_set_bytes との乖離によって発生します。カーネルはメモリマップトファイル（mmap）、アクティブなI/Oページキャッシュ、ランタイムヒープ外のネイティブ割り当てを含めてカウントします。memory.current が memory.max（limits.memory）を超過すると、cgroupコントローラはアプリへの事前通知なしに即座にOOM Killを実行します。解決策: アプリ層のランタイムメトリクスではなく、Prometheusの container_memory_working_set_bytes{pod=...} を確認してください。観測されたP95ワーキングセット値より25%〜35%高い値を resources.limits.memory に設定するか、アプリ側のmmapファイルディスクリプタやネイティブスレッドプールのメモリ割り当てを見直してください。

⚠️クラスタのCPU使用率が低いにもかかわらずマルチスレッドアプリで深刻なP99レイテンシスバイクが発生する

これは典型的なLinux CFS（Completely Fair Scheduler）クォータスロットリングの罠です。resources.limits.cpu を設定すると、kubeletは100,000μs（100ms）周期に基づいて cpu.cfs_quota_us をプログラムします。マルチスレッドアプリケーション（Java JVMの並列GC、runtime.GOMAXPROCS に基づき動作するGoのgoroutine、マルチワーカ型Webサーバーなど）は、ホストノードの全コアにスレッドを並行展開します。仮に8コアノード上のPodに1000m（1コア相当 = 100ms分のクォータ）の制限を設定した場合、8スレッドが同時に稼働すると実時間わずか12.5msで100ms分のクォータを消費し尽くし、カーネルは残り87.5msの間コンテナ内の全スレッドを一時停止（スロットリング）させます。解決策: Prometheusメトリック container_cpu_cfs_throttled_periods_total / container_cpu_cfs_periods_total を調査してください。スロットリング発生率が5%を超えている場合は、resources.limits.cpu を完全に削除するか、requestsの3倍程度まで引き上げてください。また、ランタイムのスレッドプール（例: Goの GOMAXPROCS やJavaの ActiveProcessorCount）をPodのCPU requestsと厳密に一致するように設定してください。

⚠️ノードにアイドル容量があるにもかかわらずレプリカが「0/N nodes available: Insufficient cpu」でPending状態のまま停止する

Kubernetesのスケジューリング判定は、実際のリアルタイムCPU消費量ではなく、Podリソースの「requests」定義値に対して厳密に評価されます。例えば2000mのCPU requestsを持つPodが4つ8 vCPUノードにスケジューリングされた場合、コンテナが実際には5%程度でアイドル稼働していても、kube-schedulerの計算上ノードのCPUは100%割り当て済み（コミット済み）となります。そのため、追加で1000mを要求する5つ目のPodは拒否され「Pending」状態のままになります。さらに、各ノード上で動作するDaemonSet（calico-node、aws-node、fluentbit、datadogなど）もユーザーPodの配置前にAllocatable容量を消費します。解決策: kubectl describe node <ノード名> を実行して「Allocated resources」セクションを確認してください。CPU requestsを実際のP95定常使用量＋20%のヘッドルームに設定し直して適正化（ライトサイジング）することで、スケジューラのコミット枠が解放され、不要なクラスタノードを追加することなくPending状態のワークロードを効率的にビンパッキング配置できます。

よくある質問 (FAQ)

KubernetesにおけるCPUとメモリのrequestsおよびlimitsの計算方法は？▼

CPUおよびメモリのrequestsを計算するには、まずPrometheusやDatadogを用いて7日以上の本番稼働期間における定常状態のP95消費量を算出します。スケジューラによるエビクションを防ぎ、日内トラフィックの急増を吸収するため、requestsにはP95に20〜30%のバッファを加えた値（Request = P95 * 1.25）を設定します。メモリlimitsについては、一時的なヒープ拡張やメモリマップトファイル（mmap）のバッファを吸収し、Linux cgroupの memory.max 閾値到達による強制終了を防ぐため、requestsより20〜30%高い上限値を設定します。CPU limitsに関しては、低レイテンシが要求されるマイクロサービスでは、Linux CFSクォータスロットリングを防ぐためにlimitsをrequestsの2〜3倍に設定するか、あるいはlimitsを未指定（無制限）にし、クラスタオートスケーリングと厳格なメモリ上限を併用することが業界のベストプラクティスとされています。

KubernetesにおけるGuaranteedとBurstable QoSクラスの違いは何ですか？▼

Guaranteed QoSは、Pod内の全コンテナにおいてCPUとメモリのrequestsがそれぞれのlimitsと完全に一致していること（cpu.limits == cpu.requests かつ memory.limits == memory.requests）が条件となります。これにより oom_score_adj に -997〜-998 が割り当てられ、ノードのメモリ枯渇時にもエビクションからほぼ完全に保護されます。一方、Burstable QoSは、requestsがlimitsよりも厳密に小さい場合や、CPU limitsが未指定の場合に適用され、動的に計算された 2〜999 の oom_score_adj が付与されます。ノードでメモリプレッシャーが発生した場合、kubeletおよびLinuxのOOM Killerは、まずBestEffort Pod（oom_score_adj: 1000）を最優先で終了し、次にメモリrequestsを超過しているBurstable Pod、そして最後にGuaranteed Podを終了します。

本番環境のKubernetes PodでCPU limitsは常に設定すべきですか？▼

いいえ、マルチスレッド構成のマイクロサービスにおいて、CPU limitsの設定は逆効果になることが多々あります。resources.limits.cpu を設定すると、LinuxカーネルのCFS（Completely Fair Scheduler）が100ms周期のミリ秒単位ハードクォータ（cpu.cfs_quota_us）を適用します。マルチスレッドランタイム（Go、Java、Node.jsのワーカープール等）が複数コアにまたがってバースト処理を行うと、10〜20ms程度でクォータを使い果たし、残りの80〜90msの間カーネルによって処理がスロットリングされます。これにより、ホストノードのCPUが60%以上アイドル状態であるにもかかわらず、人為的なP99レイテンシ悪化や接続タイムアウトが発生します。本番アーキテクチャでは、十分なCPU requestsを確保した上でCPU limitsは設定せず、OOMによる連鎖障害を防ぐためにメモリlimitsのみを厳格に設定する構成が推奨されます。

Kubernetes Podが終了コード137（OOMKilled）で異常終了する原因は何ですか？▼

終了コード137は、LinuxシグナルSIGKILL（128 + 9 = 137）がOOM Killerによって発行され、プロセスが強制終了されたことを意味します。これには主に2つの要因があります: 1) コンテナレベルのcgroup制限超過。container_memory_working_set_bytes が resources.limits.memory を超えた場合、カーネルのcgroupコントローラが違反コンテナを即時強制終了します。2) ホストノードの物理メモリ枯渇。ノードの空きRAMがkubeletのハードエビクション閾値（デフォルト100MiB）を下回った場合、システムのOOM Killerが最も高い oom_score_adj を持つプロセス（通常はBestEffortやrequestsを超過しているBurstable Pod）を選択して終了させます。

KubernetesはノードOS用にCPUとメモリをどの程度予約（リザーブ）しますか？▼

クラウドプロバイダーは、kube-reserved および system-reserved の段階的控除曲線を用いてシステムリソースを確保します。AWS EKSやGCP GKEにおけるメモリ予約は、公式の段階的計算式に準拠しています: 最初の4 GiBの25%、次の4 GiB（4〜8 GiB）の20%、続く8 GiB（8〜16 GiB）の10%、その後の112 GiB（16〜128 GiB）の6%、そして128 GiBを超える分の2%が差し引かれ、さらに100 MiBのハードエビクション閾値が予約されます。CPUについても、Linuxカーネル、systemd、kubelet等のデーモンを保護するため、1コア目の約6%、2コア目の1%、3〜4コア目の各0.5%、4コアを超える分の各0.25%がAllocatable容量から差し引かれます。

Kubernetesクラスタに必要なワーカーノード数の計算方法は？▼

クラスタ全体の必要ノード数は、多次元ベクトルビンパッキング式を用いて算出します: Nodes_Needed = max(ceil(Total_Pod_CPU_Req / Allocatable_Node_CPU), ceil(Total_Pod_Mem_Req / Allocatable_Node_Mem), ceil(Total_Replicas / Effective_Max_Pods))。まず、ハードウェアスペックからクラウドの段階的システム予約分およびDaemonSetの消費分を差し引き、真の割当可能容量（Allocatable）を割り出します。次に、全Podレプリカのrequests合計を集計します。最後に、クラスタがCPUバウンド、メモリバウンド、またはCNI IPのPod密度制限（AWS VPC CNIのENI制限等）のいずれに制約されているかを判定し、切り上げ計算（ceil）を行ってN+1の高可用性を担保するノード数を決定します。

関連開発者ツール

全ツール一覧 →
等比数列・等比級数計算機（一般項 & 和）Mathematics

等比数列の第n項、有限部分和、および無限等比級数の和を計算。収束性診断、逆算ソルバー、項一覧テーブルを完備。

ツールを開く→
経済的発注量（EOQ）計算finance

経済的発注量（EOQ）、最適ロットサイズ、年間在庫保管費用を瞬時に計算。発注点や数量割引の損益分岐点を分析し、在庫調達コストを最小化します。

ツールを開く→
ダンク必要垂直跳び計算health

公式10フィート（約305cm）リングでのダンクに必要な垂直跳びを、指高（スタンディングリーチ）、ボール保持力、両手跳躍時の肩沈み込み、ダンク種別クリアランスから生体力学的に精密算出。滞空時間、踏切初速、セイヤーズ式最大瞬発力（ピークパワー）まで網羅して瞬時にシミュレーションします。

ツールを開く→
仕込み水・捏ね上げ温度（DDT）計算culinary

製パンにおける最適な仕込み水温度を高精度に算出。粉温・室温・摩擦熱を考慮した3要素・4要素の目標捏ね上げ温度（DDT）計算式、クラッシュアイスの代替配合率、ミキサー別の摩擦熱校正に対応しています。

ツールを開く→
二次曲線 計算＆グラフ描画math

楕円・放物線・双曲線などの二次曲線（円錐曲線）の一般形および標準形方程式を瞬時に解析。焦点、準線、頂点、離心率の算出から計算手順の導出、高精度グラフ描画まで対応した計算ツールです。

ツールを開く→
樹高計算（クリノメーター）ユーティリティ

クリノメーター（傾斜計）の上下2点視準角と斜距離から立木の全高を高精度に計算。目高や地表面の傾斜角補正、樹冠率、伐倒時の安全離隔ゾーンまで瞬時に算出します。

ツールを開く→