Kubecost解説：請求書を動かすKubernetes FinOps

Kubecostは、OpenCostの上に構築されたKubernetesのコスト按分・最適化プラットフォームで、クラスターのテレメトリとクラウドプロバイダーの請求データを組み合わせ、支出をネームスペース、ワークロード、チームという実在のオーナーに帰属させます。請求書に見積もりではなくオーナーが必要になったら導入すべきツールですが、その数字が信頼できるのはクラウド課金の整合後であり、節約につながるのは運用のリズムと組み合わせたときだけです。

ほとんどのプラットフォームチームは、Kubernetesのコストに頭を悩ませた経験があります。毎月のクラウド請求書が届き、財務部門が「なぜ増えたのか」と尋ねても、エンジニアリングは「ワークロードが増えたから」としか答えられない。請求書が示すものと、プラットフォームチームが説明できることとの間にあるこのギャップこそ、FinOpsが運用コストの最適化のために解決を目指す問題です。本当の問いは、そのためにエンタープライズ製品が必要かどうかです。ほとんどのチームにとって、答えはノーです。OpenCostとKubecostは、ツールを運用のリズムと組み合わせて使えば、プラットフォームチームに必要な可視性を提供できます。

コスト圧力は現実のもの

Kubernetesのコスト管理は、もはや単一のクラスターや単一のクラウドだけの話ではなくなりました。多くのチームはクラスター群を運用しており、複数のクラウドプロバイダーをまたぐことも珍しくなく、オンプレミスのコントロールプレーンとマネージドサービスを組み合わせている場合もあります。コンテナはノード間を移動し、ノードはゾーン間を移動し、同じワークロードがレイテンシやコンプライアンスの要件のために複数のリージョンで実行されることもあり、コストの按分はさらに難しくなります。

業界のデータは長年同じ問題を示しています。2021年のCNCF FinOpsサーベイでは、ほとんどのチームが自社のKubernetes支出を確実に測定できておらず、主な問題は過剰プロビジョニングと責任の所在の不明確さでした。2025年も同じ話で、AWS・GCP・Azure上の2,100以上の組織から得た実クラスターデータを使ったCast AI 2025 Kubernetes Cost Benchmarkでは、CPU平均使用率は10%、メモリ使用率は**23%**にとどまっていました。これらの数字はアンケートではなく、本番テレメトリから得られたものです。問題は4年経っても変わっておらず、フリートの規模が大きくなるにつれてむしろ鮮明になっています。

本当の問題は、Kubernetesが高すぎることではありません。ほとんどのチームが、自分たちが何にいくら使っているのかを十分に可視化できていないことです。

Kubecostとは何か？

Kubecostは、コストの按分、最適化、ガバナンスを担うKubernetesプラットフォームです。2024年にIBMが買収して以降、Kubecostはオープンソース版とエンタープライズ版の両方を提供しています。中核はOpenCostの上に乗っており、複数のマイクロサービスからなるクラスター内エージェントスタックとして動作します。データコレクター、クラウドコストインジェスター、予測サービス、ノードごとのネットワークコストDaemonSet、そして高速なClickHouseベースのアグリゲーターです。Kubernetesのテレメトリとクラウドプロバイダーの請求データを組み合わせて、Kubecostは詳細なコスト按分ビューを提供します。クラウドの課金連携を構成して整合させることで精度は向上します。

このプラットフォームは3つの柱で構成されています。

• コストの按分 は、ネームスペース、ラベル、サービス、ワークロード、またはCollection単位で支出を集計します。Kubecost v3では、Kubernetesと外部クラウド側のコストを重複排除した単一の単位にまとめるグルーピング概念が追加されました。コストはCPU、メモリ、永続ボリューム、GPU、ネットワークトラフィックを横断して追跡されます。
• 最適化のレコメンデーション は、実際の使用量に基づいた適正サイズのリクエストを提案し、より安価なノードタイプを提案し、ワンサイズのデフォルト値ではなく分位点ベースの制御をチームが設定できます。レコメンデーションは履歴として残し、CSVやPDFとしてエクスポートできます。
• アラートとガバナンス は、構成可能なバジェットアクション、スケジュール済みレポート、Slack/メール通知として提供されます。アラートは独立したサブシステムではなく、関連する予算設定に紐づきます。

Kubecostインストールの流れ

コストデータの収集はクラスター内部から始まります。起動時にFinOpsエージェントは価格用ConfigMapを監視するためにKubernetes APIにウォッチを張り、カスタム価格ルールを再起動なしで適用できるようにします。また、ノードごとに価格を解決します(クラウドプロバイダーの価格が利用できない場合は計算値にフォールバックします)。次に各Network Costs DaemonSetポッドからメトリクスを収集し、新しいバイナリスナップショットを作成し、構成されていればAzure Blob StorageやAWS S3などの外部ストレージに書き出します。

Network Costs DaemonSetは、netlinkソケット経由でカーネルのconntrackテーブルを購読し、各フローの方向別バイト・パケットカウンターを解析し、Kubernetes APIウォッチを通じてポッド・ノード・サービス・エンドポイントの状態をインメモリのマップとして維持します。このマップを使って、観測した接続を特定のワークロードに紐付けます。

これらのエージェントが内部スナップショットを共有ストレージに送る一方で、Cloud Cost Ingestorは外部の財務データを管理します。スケジュールに従って実行され、クラウドプロバイダーの請求エクスポートに接続し、日次のCSVを取り込み、過去データを補完します。クラウドプロバイダーは請求データを数時間遅れでリリースするため、Kubecostは少し待ってからクラスターデータをクラウド請求と整合させます。つまり直近1〜2日のコストデータは見積もりにすぎず、それより古いデータは(クラウド課金連携が正常に動作している前提で)完全に整合されたものになります。

Aggregator はメインエンジンで、組み込みのClickHouseデータベースを使用します。マルチクラスター構成では、複数のエージェントクラスターからのスナップショットを集約します。複数のConfigMapを参照して構成を読み込み、何もなければデフォルトにフォールバックします。エージェントのスナップショットを取り込み、構成されていれば外部の請求CSVも取り込み、それらを多段のSQLパイプラインに通して重複コストを整合・重複排除し、他のマイクロサービスが消費する最終的なコストテーブルを生成します。AggregatorはまたClickHouseにテーブルごと・解像度ごとのTTLを設定してデータ保持を管理し、細粒度のウィンドウは数日で期限切れになる一方、ロールアップは数週〜数か月保持されます。

最後に、Forecasting Service は予測的コスト監視ツールとして機能し、このデータを使ってコスト予測を生成します。同時に、Cluster Controller はAggregatorの最適化インサイトを使って、適正サイズのレコメンデーションをクラスターに直接適用するなどのアクションを実行します。

まずは実在のオーナーに按分する

Kubecostは、各ノードで稼働しているポッドにノードコストを按分します。通常はリソースリクエストで重み付けし、その結果をネームスペース、ラベル、サービス、ワークロード、またはCollection単位でCPU、メモリ、PV、GPU、ネットワークにわたって集計します。

このアプローチを効果的にするのは、技術的なセットアップだけではなく、優れた組織化です。各ネームスペースは、チーム、プロダクト、または部門といった実在のオーナーに紐付けるべきです。このマッピングが整っていれば、按分ビューはスプレッドシートなしでも、どのチームがどのコストに責任を持つかを示します。team、cost-center、productのようなラベルを既に使っているチームは、同じ目的でそれらを使えますし、Collectionsを使うとラベルベースのビューが扱いやすくなります。

ラベルは時とともに変わり、ネームスペースは増え、誰かはいずれdefaultにデプロイします。週次でラベル付けされていないバケットを見直すことで、データの正確さと有用性を保てます。

実際の使用量に対してリクエストを適正化する

これは請求書を最も大きく動かすレバーです。開発者はCPUとメモリのリクエストを保守的に設定し、その後一度も見直さないことが多く、リクエストと使用量のギャップはそのまま請求額に表れます。冒頭で引用した「CPU 10%／メモリ23%」のベンチマークは、財務から数字を求められたときに使える説得力のある根拠です。

確実に節約を見つけられるパターンは、ワークロードごとにリクエストと実使用のCPUとメモリを数週間プロットし、各ワークロードのリクエストを実使用に合わせて下げていくことです。あるサービスメッシュ環境の実例では、プロキシのサイドカーが各100ミリコアに設定されていました。理論上はノードあたり約200ポッドを収容できたはずですが、各ポッドが自身のリクエストに加えて100ミリコアのサイドカーリクエストを持っていたため、スケジューラーは約90ポッドで割り当て可能CPUを使い切ってしまいました。リクエストの適正化を行った結果、ノードあたりのポッド密度はアプリケーションの変更もノードフリートの変更もなしに3倍になりました。

Kubecost 3.0はこのループをさらに緊密にします。Container Request Sizing InsightsはUI上に使用量の可視化を直接表示し、レコメンデーションをアーカイブでき、CSV/PDFエクスポートにラベルが含まれ、分位点ベースのコントロールにより予測しやすいサービスにはより厳しい推奨パーセンタイルを、バーストするワークロードには緩やかなパーセンタイルを設定できます。エンタープライズ層では、カスタムプロファイル、停止コントロール、監査履歴、推奨削減額と実現削減額の比較を備えたAutomated Container Request Sizing UIがクラスター横断で動作します。オープンソース層ではEKSプライマリクラスターで最大250コアまでの無料枠が利用できます。

本番では、分位点ベースのレコメンデーションポリシーが通常最も効果的です。

• CPUリクエストは過去1週間または1か月の実CPU使用量の90パーセンタイルに設定し、安全マージンを加えます。Kubernetes VPAのデフォルトはCPUで約15%です。CPUは時分割で共有されるので、空きがあればカーネルはバーストするワークロードに追加のキャパシティを使わせます。稀なスパイクのためにパディングを増やしても、たいていリクエストが増えるだけで大した効果はありません。
• メモリリクエストはピーク使用量の高いパーセンタイルに設定し、安全マージンを加えます。メモリは時分割共有ではないため、上限を超えると緩やかな劣化ではなくOOMキルが起きます。ピークの90パーセンタイル前後を狙い、マージンを加えます。VPAのデフォルトはメモリで約20%です。

これらの設定はQoSクラスを決めます。ポッドがGuaranteedと見なされるのは、すべてのコンテナのCPUとメモリのリクエストがリミットと等しい場合だけです。どれか一つでもそうでなければ、ポッド全体はBurstableとして扱われ、いずれのコンテナもリクエストやリミットを設定していない場合はBestEffortとして扱われます。この設定はほとんどのワークロードでうまく機能します。厳しいレイテンシSLAを持つ重要なワークロードに限ってGuaranteedクラスを予約し、CPUとメモリのリクエストをリミットと一致させましょう。その場合は多少のヘッドルームを無駄にする可能性がありますが、最良のエビクション保護と、必要であれば排他的なCPUピン留めを得られます。

この自動化に踏み切る前にもう一段のフィードバックが欲しい場合は、VPAを数週間レコメンデーションのみのモードで動かすか、オープンソースのKRRを使えます。KRR、VPAレコメンデーションモード、Kubecostの推奨を比較する方が、単一ツールの数字を信じるより信頼できます。

キャパシティ対リクエストを北極星指標に

クラスター効率について最も語ってくれる比率は、CPUとメモリ両方の 総ポッドリクエスト ÷ 総ノード割り当て可能容量 です。支払っているうちのどれだけがそもそもポッドから要求されているか、を表します。これはKubecostのリクエスト適正化が依拠する指標でもあります。Kubecostは複数のターゲットを同梱しており、レコメンデーションはこれらに対して計算されます。Production 0.65、Development 0.80、High Availability 0.50(Cluster Right-Sizing API)です。これを下回ると、誰も要求していないキャパシティを抱えていることになります。上回ると、そのクラスタークラスが保持すべきヘッドルームを使い切っていることになります。Kubecostはまた、文脈に応じてサイジングに用いる使用率を選択します。Developmentはトレンドの85パーセンタイル、Productionは98パーセンタイル、HAは99.9パーセンタイル、そして1日ウィンドウでのみです。それより長いウィンドウでは最大使用量が使われます。よく引用される「85パーセンタイル」は、Developmentの1日デフォルトに過ぎず、普遍的な設定ではありません。

監視すべきはこの比率で、それを動かすのはオートスケーラー(Karpenter、Cluster Autoscaler)ですが、リクエストが正直であってこそです。だからこそKubecostのリクエスト適正化は、あらゆるオートスケーリングの話の上流に位置します。オートスケーラーはリクエストに反応し、Kubecostはリクエストが現実を反映しているかを教えてくれます。

直近数日のデータは設計上方向性を示すだけです。整合には1日分の請求データが必要なので、約48時間のウィンドウではノードがオンデマンドでないと証明できない限り、コストはパブリックなオンデマンド料金のままです。Spotはそれ以前に正確になりますが、それは別途設定したAWS Spot Data Feed経由のみです(Cloud Billing Integrations)。効率はコストとは独立に、整合済みの価格と切り離して読みましょう。 Node Group Sizing(旧Cluster Right-Sizingがv3.0で再構築されたもの)はこれをアクションに変えます。クラスター内のCPU、RAM、GPU使用率を構成可能なウィンドウでノード容量に対して分析し、ノードグループごとにノード数の変更やインスタンスタイプの切り替えを推奨します。プリセットプロファイルか、カスタムメトリック(usage.max/p95/p85/avgまたはrequest.max/avg)から実行され、リソースごとのターゲット使用率しきい値を持ち、平均要求リソースを下回ることはありません。各プロバイダーの標準ラベルでノードグループを検出するので、EKS、AKS、GKEでセットアップなしに動作します(v3.xドキュメント)。

動き続ける必要のない常時稼働ワークロードを見つける

按分と適正化を片付けたら、必要でないのに一日中、毎日動いているワークロードに目を向けましょう。あるプラットフォームチームのレビューでは、ワークロードの31%が一日のほぼ全時間でCPUを25%未満しか使っていなかったにもかかわらず、Kubernetesのコストはその年に約18%上昇していました。これはエンジニアがキャパシティのチューニングとアラート対応に時間を費やし、各チームがそれぞれ異なる方法でオートスケーリングのルールを設定していたためです。

トリアージは3つに分けられます。本当にオーバースペックな本番サービスは、上記の適正化ループに戻すべきです。非本番環境(dev、integration、demo)は週末や夜間に動かす必要はほとんどなく、スケジュールに従ったscale-to-zeroが、このカテゴリで最もROIの高い変更です。リトライ耐性のあるバッチおよびステートレスワークロードは、約2分の中断通知と引き換えに約90%の割引を得られるSpotインスタンスの候補です。

Kubecostは、十分に活用されていないワークロードを見つける助けになります。Kubecost 3.0のAdvanced Filtersを使えば、UI上でAND/OR条件によりネームスペース、ラベル、サービスでワークロードを素早く並べ替えられます。別の場所でやる必要はもうありません。

コミットメントのカバレッジと利用率を別々に追う

予約キャパシティと節約コミットメントは、不要なクラウドコストの典型的な原因です。チームはこれらを無視してフルのオンデマンド料金を支払うか、購入したまま使用されているかを確認し忘れ、もはや必要のないリソースの割引を使い残してしまいます。注意すべき重要な指標は2つあり、混同しやすいです。

• カバレッジ は、通常の使用量のうちコミットメントで保護されている割合のことです。
• 利用率 は、コミットメントのうち実際に使っている割合のことです。

クラウドプロバイダーごとにツールは異なりますが、どれも3つの主要なタイプに収まり、計算は基本的にどこでも同じです。

良いアプローチは、100%を狙うのではなくコミットメント利用率を80%〜95%に保つことです。100%を狙うと、未使用のインスタンスを取り除く、インスタンスタイプを変える、トラフィック減に対応する、といった通常の変更の余地がなくなります。四半期レビューでは効率的に見えるかもしれませんが、日々の運用では問題を起こします。カバレッジについては60%〜75%を目標にすると妥当です。この範囲は良い割引を得るには十分高く、四半期ごとの変更を許す程度に低く保たれます。これらの範囲はクラウドプロバイダーが定めた規則ではなく、実務経験に基づいたものです。

Kubecostでは、コストは実際のクラウド請求書が用意できるまで、まずクラウドプロバイダーのパブリックなオンデマンド料金で見積もられます。請求書が利用可能になると、通常は約48時間以内に、Kubecostは見積もりを実コストで更新します。この更新にはReserved Instances、Savings Plans、コミット型割引、Spot価格、そしてEnterprise Discount Programなど特別なレートがあればそれも含まれます。

代わりに商用FinOpsプラットフォームを使うべきなのはいつか？

ほとんどのチームはオープンソースのChartから始めるべきです。ニーズが大きくなってから商用層を検討すれば十分です。

数クラスターでネームスペースごとの按分、基本的なレコメンデーション、Slackアラートだけが必要なら、オープンソース版で十分です。しかし複数クラウドにまたがる多数のクラスターを管理していて、自動修正が必要、ベンダー管理の履歴が欲しい、または財務チームに詳細で整合された割引数値を提供する必要があるなら、商用プラットフォームは見合います。判断はこれらのニーズに基づくべきで、ダッシュボードの見た目に基づくべきではありません。

運用の現実

• ClickHouseと統合エージェントが旧スタックを置き換える。 v3では、2.xのDuckDBストアがClickHouseデータベースに置き換えられました。これにより、按分とクラウドコストのAPIクエリは大規模でも大幅に高速かつ信頼性が高くなります。またPrometheusの必要性がなくなり、メモリ使用量が減りデプロイが楽になる一方で、OpenCost標準のメトリクスは引き続き提供されます。

• 履歴はデフォルトではなく意図的な選択。 ストレージバックエンドが何であれ、保持期間が期間比較レポートを作成できる上限を決めます。月次レポートには少なくとも30日、前年比較には1年が必要です。クラスター内保持のコストが階層化パイプラインを構築するエンジニアリング時間より早く高くなるなら、コールドデータをオブジェクトストレージに階層化しましょう。

• 整合の遅延は構造的なもの。 24〜48時間の請求整合遅延はクラウドプロバイダーの請求エクスポートの性質であって、Kubecostの性質ではありません。それを前提に運用モデルを組み、昨日ではなく先週について議論しましょう。

• マルチクラスターには戦略が必要。 オープンソースKubecostはクラスター間のフェデレーションが可能ですが、その体験は商用のマルチクラスターアグリゲーターよりも荒削りです。5〜6クラスターを超えるなら、クラスターごとにKubecostを動かして外部(例えば自前のウェアハウス)で集約するか、商用のマルチクラスター経路にお金を払うかを早めに決めましょう。どちらも擁護できますが、その間を漂うのはダメです。

• EKSアドオンは手早く始める方法を提供する。 Kubecost v3の無料枠には30日で10万USドルの支出上限がありますが、Amazon EKS最適化Kubecostバンドルは、AWSではこの支出上限の対象外として記載されています。

• 運用モデルこそが成果物。 チームがKubecostをインストールしても定期的なレビューを設定しなければ、FinOpsツールを持たないチームと同じように漂流します。標準的なアプローチは、プラットフォームエンジニア、財務アナリスト、ローテーションのSREといった小規模なFinOpsグループを設置し、毎週集まってキャパシティ対リクエスト比をレビューし、最も過剰プロビジョニングされているワークロードを特定し、月次コストに大きな変化のあるネームスペースを確認することです。小規模なチームでは、プラットフォームエンジニアとCTOで2週に一度30分のレビューでも同じ成果を得られます。

実務的な提言

Kubernetesプラットフォーム向けにFinOpsアプローチを検討していて、商用製品を選ぶ契約上の義務がないなら、オープンソースのKubecost 3.xでのパイロットから始めましょう。インストールは半日程度で完了できます。少なくとも1つのネームスペースを指定オーナーに割り当て、1つのチームに2週間リクエスト対使用量のダッシュボードを提供し、キャパシティ対リクエスト比をプラットフォームチームから見えるチャンネルで共有してください。これらの指標の定期レビューが習慣になれば、FinOpsを実現したことになります。そうでなければ、商用プラットフォームを採用しても根本的な問題は解決しません。