Kubecost Helmチャートとは?
Kubecostは、cost-analyzerリポジトリで公開されている公式Helmチャートを使ってインストールできます。このチャートは、HelmでKubernetesクラスタにKubecostをデプロイするためのパッケージです。デプロイメント、サービス、設定、関連コンポーネントなど、Kubecostに必要なKubernetesリソースを定義します。Helmはこれらのリソースを1つのリリースとして扱うため、Kubecostのインストール、アップグレード、設定、削除が容易になります。
チャートに含まれるもの:
Kubecost Helmチャートには、Kubecostの実行に必要なKubernetesリソースと設定可能な依存関係がパッケージされています。設定値に応じて、Kubecostアプリケーションコンポーネント、Prometheus連携、Kubernetesメトリクスコンポーネント、永続ストレージ、ServiceとIngress、監視リソース、ネットワークコスト収集、ネットワークポリシー、クラウドプロバイダーの料金連携などを含めることができます。
設定のベストプラクティス:
- Kubecost Helmチャートのバージョンを固定する: チャートのバージョンを明示的に指定して、デプロイを予測可能に保ち、新しいリリースによる予期せぬ変更を防ぎます。
- Helmの設定値をバージョン管理する: 設定の上書き内容はバージョン管理された
values.yamlファイルに保存し、認証情報などのシークレットはリポジトリの外に置きます。 - 環境ごとに別々のvaluesファイルを使う: チャートのマニフェストを複製・改変するのではなく、開発・ステージング・本番それぞれの環境別設定を管理します。
- 適切なリソースのrequestsとlimitsを設定する: クラスタの規模に応じてKubecostコンポーネントのCPUとメモリを設定し、実際に観測されたリソース消費量をもとに調整します。
- 本番環境では永続ストレージを設定する: データ保持、増加量、バックアップ、リカバリの要件に基づき、適切な永続ボリューム容量と信頼性の高いStorageClassを選択します。
- Helmアップグレードを本番前にテストする: 新しいチャートバージョンと既存のカスタム設定値を非本番環境で検証し、テスト済みのロールバック手順を用意しておきます。
この記事の内容:
- 2つのKubecost Helmチャート:cost-analyzerとkubecost
- Helmチャートに含まれるもの
- HelmでKubecostをインストールする方法
- Kubecost HelmチャートとKubernetesマニフェストの比較
- Kubecost Helmチャートのベストプラクティス
2つのKubecost Helmチャート:cost-analyzerとkubecost

現在、Kubecostには管理者が目にする可能性のある2系統のHelmチャートがあります。Kubecost 2.xのデプロイで使われてきた旧来のcost-analyzerチャートと、Kubecost 3.x向けに導入された新しいkubecostチャートです。現行のKubecostリポジトリでは、バージョン2.8が2.x系最後の機能リリース、バージョン2.9が中間アップグレードステップ、バージョン3.0がKubecost 3.xの最初のリリースと位置づけられています。
cost-analyzerチャートは、Kubecost 2.x全体で使われてきたレガシーのデプロイ方法です。既存環境では引き続きkubecost/cost-analyzerなどのコマンドが参照されている場合があり、Kubecostも旧デプロイやアップグレードシナリオのために、このチャートに関連するリポジトリを維持しています。
Kubecost 3.xでは、主要チャートの名前はkubecostになりました。新規インストールでは、KubecostのHelmリポジトリからkubecost/kubecostチャートを使用します。Kubecost 3.xでは、ClickHouseベースのストレージや、2.xで使われていた従来のcost-modelエージェントに代わる新しいfinops-agentなど、アーキテクチャの大きな変更も導入されています。
そのため、既存のKubecost 2.xデプロイをアップグレードする場合は、単なるチャート名の変更以上のものとして扱う必要があります。Kubecostは、3.xへ移行する前にエージェントをバージョン2.9にアップグレードし、この中間バージョンをしばらく稼働させてから移行を完了することを推奨しています。コンポーネント名、ストレージアーキテクチャ、設定オプションが変更されているため、既存のcost-analyzerの設定値が新しいkubecostチャートにそのまま対応すると想定せず、必ず見直してください。
Helmチャートに含まれるもの
Kubecost Helmチャートには、Kubecostの実行に必要なKubernetesテンプレートと設定可能な依存関係が含まれています。実際にデプロイされるリソースはチャートのバージョンと有効化した設定値によって異なりますが、一般的に以下のコンポーネントをカバーしています。
- Kubecostアプリケーションコンポーネント: Kubecostを実行し、コスト監視機能を提供するために必要なDeployment、Service、ConfigMap、Secret、サービスアカウントなどのリソース。
- メトリクス収集(
finops-agent): チャートはfinops-agentをデプロイします。これはKubecostがコスト配分に使用するクラスタメトリクスを収集する軽量エージェントで、別途Prometheusをデプロイする必要はありません。 - Kubernetesメトリクスコンポーネント: 設定に応じて、Kubernetesオブジェクトやノードレベルのメトリクスを提供する
kube-state-metricsやNode Exporterなどの補助コンポーネントをデプロイできます。 - 永続ストレージ: Helmの設定値でKubecostとPrometheusのデータ用の永続ボリュームクレームを作成でき、ストレージサイズとストレージクラスを設定できます。
- IngressとServiceの設定: チャートには、Kubernetes Serviceを通じてKubecostを公開するための設定が用意されており、有効化すればホスト、パス、アノテーション、TLS設定を構成できるIngressも利用できます。
- 監視リソース: Prometheus Operatorを使用する環境向けに、
ServiceMonitorやPrometheusRuleなどのオプションリソースを作成できます。 - オプション機能と連携: 生成されたKubernetesマニフェストを手動で変更することなく、Helmの設定値でネットワークコスト収集、ネットワークポリシー、クラウドプロバイダーの料金連携などの追加機能を有効化できます。
これらのコンポーネントはチャートのvalues.yamlで制御されるため、必要なリソースだけを有効化したり、クラスタに既に存在する監視・インフラコンポーネントとKubecostを統合したりできます。
関連コンテンツ:Kubernetesコスト最適化のガイドもぜひご覧ください
HelmでKubecostをインストールする方法
Kubecostは、公式のKubecostチャートリポジトリを追加し、専用のnamespaceにチャートをデプロイすることで、Helmでインストールできます。現行のKubecost Helmチャートリポジトリは、Kubecost 3.x向けにkubecost/kubecostチャートを提供しています。
まず、KubecostのHelmリポジトリを追加し、ローカルのチャートインデックスを更新します。
helm repo add kubecost https://kubecost.github.io/kubecost/helm repo update次に、kubecost namespaceにKubecostをインストールします。
helm install kubecost kubecost/kubecost \ --namespace kubecost \ --create-namespaceKubecostは、リポジトリのURLから直接インストールすることもできます。公式の例では、クラスタを識別するためにglobal.clusterIdを設定しています。
helm install kubecost \ --repo https://kubecost.github.io/kubecost kubecost \ --namespace kubecost \ --create-namespace \ --set global.clusterId=my-cluster本番環境にデプロイする前に、特定のチャートバージョンでサポートされている設定値を確認できます。
helm show values kubecost/kubecost --version <chart-version>必要な設定をカスタムのvalues.yamlファイルにまとめ、次のコマンドでKubecostをインストールします。
helm install kubecost kubecost/kubecost \ --namespace kubecost \ --create-namespace \ --values values.yamlvaluesファイルを使えば、ストレージ、リソース割り当て、監視、Kubecostコンポーネントなどの設定をバージョン管理し、再現しやすくなります。Kubecostの公式リポジトリでは、リリースを選ぶ際にチャートとKubernetesのバージョン互換性を確認することも推奨しています。たとえば、Kubecost 3.0のチャートは、Kubecost 2.x系の最終リリースよりも新しいKubernetesバージョンを対象としています。
Kubecost HelmチャートとKubernetesマニフェストの比較
HelmチャートとKubernetesマニフェストはどちらもKubernetesへのアプリケーションデプロイに使えますが、設定の管理方法が異なります。Kubecostは主要なインストール方法としてHelmを推奨しており、公式チャートは必要なリソースをパッケージ化し、Helmの設定値を通じて構成を公開しています。
| Kubecost Helmチャート | Kubernetesマニフェスト | |
|---|---|---|
| デプロイ | パッケージ化されたチャートを使い、KubecostをHelmリリースとしてインストール。 | kubectl applyでリソースを直接適用。 |
| 設定 | 設定はvalues.yamlに集約するか、--setで指定。 |
個別のYAMLリソース定義を編集して設定を変更。 |
| アップグレード | Helmがリリースを追跡し、helm upgradeでチャートバージョンや設定の変更を適用可能。 |
更新したマニフェストは基本的に手動で適用・管理する必要がある。 |
| カスタマイズ | チャートの設定値で、コンポーネント、ストレージ、Prometheus、リソース制限などのオプションを構成可能。 | すべてのKubernetesオブジェクトを直接制御できるが、手動での保守負担が大きい。 |
| 再現性 | チャートバージョンとvaluesファイルの組み合わせにより、複数クラスタへのデプロイを再現しやすい。 | チーム自身がマニフェスト一式を管理し、同期させる必要がある。 |
| ライフサイクル管理 | リリースのインストール、アップグレード、ロールバック、アンインストールの機能がHelmに組み込まれている。 | KubernetesはHelmリリースのライフサイクルではなく、個々のリソースを管理する。 |
| 適したケース | ほとんどのKubecostデプロイ。特に再現可能な設定と継続的なアップグレードが必要な環境。 | 静的なKubernetesリソースを直接制御する必要がある環境や、Helmを使えない環境。 |
Kubecostは従来、静的マニフェストによるデプロイも代替手段として提供してきましたが、ドキュメントでは特に本番デプロイにHelmを推奨しています。また、Helmを使えば、すべてのKubernetesリソースの改変コピーを管理することなく、依存関係や設定(たとえば、Kubecostがバンドルの監視コンポーネントを使うか既存のインフラを使うか)を簡単にカスタマイズできます。
Kubecost Helmチャートのベストプラクティス
Kubecost Helmチャートを使う際に役立つプラクティスを紹介します。
1. Kubecost Helmチャートのバージョンを固定する
Helmに最新リリースを自動的にインストールさせるのではなく、Kubecostチャートのバージョンを明示的に指定します。Helmは--versionオプションで特定のチャートバージョンを選択でき、省略すると最新のチャートバージョンが選択される可能性があります。
バージョンを固定することでデプロイの予測可能性が高まり、自動インストールやCI/CDパイプラインが、デフォルト値や依存関係が変わった新しいチャートを予期せず採用してしまうのを防げます。固定したバージョンを意図的に更新する前には、Kubecostのリリースノートと互換性要件を確認してください。
2. Helmの設定値をバージョン管理する
上書きするKubecostの設定は専用のvalues.yamlファイルに保存し、バージョン管理下に置きます。Helmの設定値は、アプリケーションコンポーネント、ストレージ、Ingressなどのデプロイオプションを含め、チャートのデフォルト値を上書きする標準的な仕組みです。
バージョン管理により設定変更の履歴が残り、Kubecostデプロイのレビュー、再現、ロールバックが容易になります。認証情報などの機密シークレットをリポジトリに直接置くことは避け、適切なKubernetesまたは外部のシークレット管理の仕組みを参照するようにしてください。
3. 環境ごとに別々のvaluesファイルを使う
開発、ステージング、本番で異なるKubecost設定が必要な場合は、環境ごとに個別のvaluesファイルを管理します。Helmは同じチャートを異なる設定値でデプロイできるよう設計されており、ベースとなるKubernetesマニフェストのコピーを別々に管理する必要がありません。
たとえば、本番環境ではより大きな永続ボリュームとリソース割り当てを使用し、開発クラスタではより小さい設定を使用できます。環境別の上書き設定を分けておくことで、開発用の設定を誤って本番に適用してしまうリスクも減らせます。
4. 適切なリソースのrequestsとlimitsを設定する
クラスタの規模とworkloadsに応じて、KubecostコンポーネントのCPUとメモリのrequestsとlimitsを設定します。requestsはKubernetesがKubecostのPodに十分なリソースを確保するのに役立ち、limitsは個々のコンポーネントがクラスタ容量を過剰に消費するのを防ぎます。
規模が大きく異なるクラスタ間で同じリソース設定をそのままコピーするのは避けてください。デプロイ後はKubecostの実際のリソース消費量を監視し、ノード数、workloads、収集メトリクスの増加に合わせてHelmの設定値を調整しましょう。
5. 本番環境では永続ストレージを設定する
Podの再起動や再スケジュール後もデータを保持する必要があるKubecostコンポーネントには、永続ストレージを使用します。Kubecostのチャートでは、永続化の有効/無効、ボリュームサイズ、ボリュームに使用するKubernetes StorageClassなどの永続ボリューム設定を構成できます。
本番デプロイでは、信頼性の高いStorageClassを選び、想定されるデータ増加に十分な容量をプロビジョニングしてください。ストレージ設定は、組織のバックアップ、データ保持、ディザスタリカバリの要件とも整合させる必要があります。
6. Helmアップグレードを本番前にテストする
本番環境を更新する前に、開発またはステージングクラスタでKubecostチャートのアップグレードを適用します。チャートのアップグレードでは新しい設定の追加、デフォルト値の変更、Kubernetesリソースの変更が発生する可能性があるため、新しいチャートバージョンと既存のカスタム設定値の両方をテストしてください。
Helmはアップグレード時の設定値の確認と制御に対応しており、必要に応じてリリースを以前のリビジョンにロールバックすることもできます。本番アップグレードで問題が発生した場合に備え、テスト済みのロールバック手順として、以前のチャートバージョンと設定を保持しておきましょう。
Kubecostの先へ:PerfectScaleによるKubernetesコスト最適化
PerfectScale by DoiTは、Kubernetesの安定性とパフォーマンスを損なうことなく無駄なリソースを排除する、責任あるコスト最適化を提供します。Kubecostは主にKubernetesのコスト監視に焦点を当てています。PerfectScaleはその先を行きます。環境を継続的に微調整して最適なパフォーマンスとコスト効率を実現し、ノードグループ、namespace、コンテナ、workloadsにまたがる高度な可視性とガバナンスを提供します。Kubecost HelmチャートはPrometheusと関連メトリクスコンポーネントをデプロイ・管理しますが、PerfectScaleは最小限のフットプリントの単一ステートレスエージェントとして動作し、Prometheusを必要としません。
PerfectScaleの主な機能:
- 自律的なコスト最適化: GitOpsと統合されたアクションでKubernetes環境を自律的に微調整。コスト削減をダッシュボードに表示するだけでなく、継続的に適用します。
- 包括的なライトサイジング: requestsとlimitsの両方についてCPUとメモリの推奨値を提供。これらの推奨値は、コード変更やHPA設定も考慮します。
- ステートレスエージェントによるデプロイ: 単一の軽量エージェントとしてインストールでき、継続的な保守は最小限。Prometheusのセットアップや保守は不要です。
- きめ細かなコスト可視化と配分: コストの可視化と配分、コストと無駄の予測、一時的なworkloadsの可視化を実現。ノードの割り当て、使用率、アイドル容量も表示し、ノードグループに対応。一時的なworkloadsを独自の方法でグループ化できます。
- レジリエンス課題の検出と修復: OOMイベント、CPUスロットリング、メモリリークの疑い、頻繁な再起動、Eviction、レプリカ上限に達したworkloadsを特定。レジリエンスリスクの自動優先順位付け、カスタマイズ可能なアラート、自律的な修復も提供します。
- Kubernetesが動くあらゆる場所で動作: EKS、GKE、AKS、OpenShift、オンプレミスクラスタに対応。
コスト監視から自律的なKubernetes最適化へ進む準備はできましたか?PerfectScaleとKubecostの比較をご覧いただき、30日間の無料トライアルを始めましょう。