編集

次の方法で共有


Kubernetes のコスト管理

Azure Cost Management
Azure Kubernetes Service (AKS)
Azure Managed Disks
Azure Storage
Azure Virtual Machines

このガイドでは、Azure Kubernetes Service (AKS) における価格とコスト管理のしくみを Amazon Elastic Kubernetes Service (Amazon EKS) と比較して説明します。 AKS クラスターのコストを最適化し、コスト ガバナンス ソリューションを導入する方法について説明しています。

Note

この記事は、Amazon EKS に詳しいプロフェッショナルの方が Azure Kubernetes Service (AKS) を理解するのに役立つ一連の記事の一部です。

Amazon EKS のコストの基本

Amazon EKS では、各 Amazon EKS クラスターについて 1 時間あたりの固定価格が発生します。 また、クラスターで使用されるネットワーク、運用ツール、ストレージも課金の対象となります。

Amazon EKS のワーカー ノードは標準的な Amazon EC2 インスタンスであるため、通常の Amazon EC2 価格がかかります。 Kubernetes ワーカー ノードを実行するためにプロビジョニングした他のアマゾン ウェブ サービス (AWS) リソースについても料金が発生します。

Amazon EKS の マネージド ノード グループを使用するにあたって追加のコストは発生しません。 支払いの対象となるのは、Amazon EC2 インスタンス、Amazon EBS ボリューム、Amazon EKS クラスター時間などの AWS インフラストラクチャを含む、プロビジョニングした AWS リソースのみです。

マネージド ノード グループを作成するときは、使用する インスタンスのキャパシティ タイプとしてオンデマンドまたはスポット を選択して、エージェント ノードのコストを管理できます。 Amazon EKS では、オンデマンド インスタンスのみ、またはスポット インスタンスのみを含んだ Amazon EC2 Auto Scaling グループ を使用してマネージド ノード グループがデプロイされます。

オンデマンド インスタンスは、長期的なコミットメントはなく、コンピューティング容量に対して秒刻みで料金が発生します。 Amazon EC2 スポットインスタンスは、使われていない Amazon EC2 容量を利用することで、オンデマンド価格よりも抑えた価格を提供するものです。

  • Amazon EC2 スポット インスタンスは、EC2 に再び容量が必要になると中断される場合があります。その場合は中断の 2 分前に通知されます。

  • オンデマンド インスタンスとスポット インスタンスのグループを自動化する手法であるスポットフリートと、中断する可能性が最も低いリージョンまたは可用性ゾーンを予測するのに役立つスポット インスタンス アドバイザーが Amazon より提供されています。

  • AWS スポット インスタンスの価格は変動します。 スポット インスタンス容量の価格は、長期的な需要と供給の傾向に応じて設定され、基本的にはインスタンスが稼動している時間分について料金が発生します。

Azure Kubernetes Service のコスト分析

Azure Kubernetes Service (AKS) クラスターは、仮想マシン、仮想ディスク、ロード バランサー、パブリック IP アドレスなど、さまざまな Azure リソースに依存しています。 これらのリソースは、組織内のさまざまなチームによって管理される可能性のある複数のアプリケーションで利用できます。 これらのリソースの消費パターンは変化する可能性があり、クラスター リソースの合計コストに対する寄与も変化します。 さらに、一部のアプリケーションは複数のクラスターにフットプリントがあるため、コストの帰属と管理が困難になる場合があります。

クラスターに 1 つのワークロードが含まれているシナリオでは、Microsoft Cost Management を使用して、クラスター リソース グループのクラスター リソース消費量を測定できます。 ただし、一部のシナリオでは、そのソリューションだけではネイティブにカバーされません。次に例を示します。

  • コンピューティング、ネットワーク、ストレージなど、リソースの使用状況の詳細な内訳。
  • 個々のアプリケーション コストと共有コストの区別。
  • 同じサブスクリプション スコープ内の複数のクラスターにわたるコストの分析。

コストの監視性を高めるために、AKS は Microsoft Cost Management と統合されており、クラスターや名前空間などの Kubernetes コンストラクトで詳細なコスト ドリルダウンを提供しています。 この統合により、Azure のコンピューティング、ネットワーク、ストレージの各カテゴリでコスト分析が可能になります。

AKS コスト分析アドオンは、使用状況データ収集用のオープンソース プロジェクトである OpenCost 上に構築されています。 Azure の請求書でデータを調整することで、コストの可視性を実現します。 後処理されたデータは、Cost Management コスト分析ポータルに直接表示されます。 詳細については、「Azure Kubernetes Service のコスト分析」を参照してください。

コストの定義

Kubernetes 名前空間とアセット ビューには次のような料金が表示されます。

  • アイドル料金: ワークロードで使用されなかった使用可能なリソース容量のコストを表します。
  • サービス料金: アップタイム サービス レベル アグリーメント (SLA) や Microsoft Defender for Containers などのサービスに関連する料金を表します。
  • システム料金: クラスターに必要なシステム プロセスを実行するために、各ノードで AKS によって予約された容量のコストです。
  • 未割り当て料金: 名前空間に割り当てられなかったリソースのコストを表します。

AKS のコストの基本

Kubernetes アーキテクチャは、コントロール プレーンと少なくとも 1 つのノード (またはノード プール) という 2 つのレイヤーが基盤となっています。 AKS の価格モデルは、2 つの Kubernetes アーキテクチャ レイヤーに基づいています。

  • コントロール プレーン は、 主要な Kubernetes サービス (API サーバー、 etcd など) とアプリケーション ワークロードのオーケストレーションを提供します。 Azure プラットフォームは AKS のコントロール プレーンを管理し、AKS Free レベルの場合、コントロール プレーンにコストはかかりません

  • ノードは、Kubernetes ワークロードとアプリケーションのホストであり、"エージェント ノード" または "ワーカー ノード" とも呼ばれます。 AKS では、お客様がエージェント ノードをすべて管理し、そのすべてのコストを負担することになります。

次の図は、AKS Kubernetes アーキテクチャのコントロール プレーンとノードの関係を示しています。

AKS アーキテクチャのコントロール プレーンとノードを示す図。

コントロール プレーン

AKS クラスターを作成すると、Azure によってコントロール プレーン レイヤーが自動的にプロビジョニングされ、構成されます。 AKS Free レベルの場合、コントロール プレーンは無料です。

コントロール プレーンに関して、それよりも上位のサービス レベル アグリーメント (SLA) については、 Standard レベルを使用して AKS クラスターを作成できます。 アップタイム SLA は既定で Standard レベルに含まれており、クラスターごとに有効になっています。 価格は、クラスターあたり 0.10 ドル/1 時間です。 詳細については、 AKS の価格の詳細に関するページをご覧ください。

Standard レベルのクラスターには、API サーバー インスタンスの数、Etcd リソースの制限、 最大 5,000 ノードまでのスケーラビリティ、金銭的な保証を伴う既存のアップタイム SLA サポートなど、より多くのコントロール プレーン リソースがあります。 AKS は、複数の更新ドメインや障害ドメインにまたがってメイン ノード レプリカを使用することで可用性要件を満たします。

運用ワークロードには Standard レベル を使用して、コントロール プレーン コンポーネントの可用性を高めることをお勧めします。 Free レベル クラスターは、レプリカが少なく、コントロール プレーン リソースも限られており、運用環境のワークロードには推奨されません。

ノード

AKS では、少なくとも 1 つのノード プールにエージェントまたはワーカー ノードが作成され、それらが Kubernetes 環境内で Azure の主要な機能を数多く使用できるようになっています。 AKS の課金は、AKS クラスターに接続されているノードに対してのみ行われます。

AKS のノードでは、仮想マシン スケール セット、仮想ネットワーク、マネージド ディスクなど、いくつかの Azure インフラストラクチャ リソースが使用されます。 たとえば、ほとんどの種類の Azure 仮想マシン (VM) は AKS 内で直接使用できます。 Azure の予約コンピューティング用 Azure 節約プラン を使用すると、これらのリソースを大幅に割引できます。

AKS クラスターの価格は、ノード プール内の VM のクラス、数、サイズに基づいています。 VM のコストは、サイズ、CPU の種類、vCPU の数、メモリ、ファミリ、使用可能なストレージの種類 (高パフォーマンスのソリッドステート ドライブ (SSD)、標準の HDD など) によって異なります。 詳細については、「Virtual Machines シリーズ」を参照してください。 アプリケーションの要件、ノードの数、クラスターのスケーラビリティのニーズに応じて、ノード サイズを計画してください。

エージェント ノードとノード プールの詳細については、このシリーズの ノード プール に関する記事、および「Azure Kubernetes Service (AKS) のクラスターで複数のノード プールを作成および管理する」を参照してください。

AKS クラスターのデプロイ

各 AKS デプロイは、2 つの Azure リソース グループにまたがります。

  • 1 つ目のリソース グループはユーザーが作成します。これには Kubernetes サービス リソースのみが含まれ、それに関してコストは発生しません。

  • AKS リソース プロバイダーにより、デプロイの間に 2 つ目またはノード リソース グループが自動的に作成されます。 このリソース グループの既定の名前は MC_<resourcegroupname>_<clustername>_<location> ですが、別の名前を指定することもできます。 詳細については、 AKS ノード リソース グループに独自の名前を指定する方法に関するセクションを参照してください。

    ノード リソース グループは、すべてのクラスター インフラストラクチャ リソースを含んでおり、サブスクリプションに対する料金が表示されるリソース グループでもあります。 これらのリソースには、Kubernetes ノードの VM、仮想ネットワー キング、ストレージなどのサービスが含まれます。 ノード リソース グループは、クラスターが削除されると AKS によって自動的に削除されるため、クラスターのライフサイクルを共有するリソースにのみ使用するようにしてください。

コンピューティング コスト

Azure VM の料金は、そのサイズと使用量に応じて課金されます。 Azure と AWS のコンピューティングの比較については、「Azure と AWS のコンピューティング サービス」を参照してください。

一般に、ノード プールに対して選択する VM サイズが大きいほど、エージェント ノードの 1 時間あたりのコストが高くなります。 グラフィックス処理装置 (GPU) 対応やメモリ最適化など、ノード プールに使用する VM シリーズの特殊化の度合いが強いほど、プールのコストが高くなります。

Azure VM の価格を調査するときは、次の点に注意してください。

  • 価格はリージョンごとに異なります。またリージョンによっては利用できないサービスや VM サイズもあります。

  • さまざまな種類のワークロード用に最適化された複数の VM ファミリがあります。

  • OS ドライブとして使用されるマネージド ディスクは個別に課金されるため、そのコストを見積もりに追加する必要があります。 マネージド ディスク サイズは、Standard HDD、Standard SSD、Premium SSD、Ultra Disk Storage などのクラスによって異なります。 1 秒あたりの入出力操作 (IOPS) とスループット (MB/秒) は、サイズとクラスによって異なります。 エフェメラル OS ディスク は無料であり、VM の価格に含まれています。

  • データ ディスク (永続ボリューム要求で作成されたものを含む) はオプションであり、Standard HDD、Standard SSD、Premium SSD、Ultra Disk Storage などのクラスに基づいて個別に課金されます。 コスト見積もりには、データ ディスクを明示的に追加する必要があります。 許可されるデータ ディスクの数、一時記憶域 SSD の数、IOPS、スループット (MB/秒) は、VM のサイズとクラスによって異なります。

  • エージェント ノードの稼働時間が長いほど、クラスターの総コストが高くなります。 開発環境は通常、継続的に実行する必要はありません。

  • ネットワーク インターフェイス (NIC) は無料です。

ストレージ コスト

Container Storage Interface (CSI) は、Kubernetes 上のコンテナー化されたワークロードに対してブロックおよびファイル ストレージ システムを公開するための標準です。 CSI を採用、使用することで、AKS は、Kubernetes のコア コードに触れたり、そのリリース サイクルを待つことなく、Kubernetes のストレージ システムを公開するプラグインの作成、デプロイ、反復を行うことができます。

AKS クラスター上の CSI 永続ボリュームを使用するワークロードを実行する場合は、ご利用のアプリケーションでプロビジョニングして使うストレージの関連コストを考慮に入れてください。 AKS 上の CSI ストレージ ドライバーは、以下のストレージ オプションをネイティブでサポートします。

  • Azure Disks では、Kubernetes データ ディスク リソースが作成されます。 ディスクには、高パフォーマンス SSD を使用する Azure Premium Storage、または標準 HDD または Standard SSD を使用する Azure Standard Storage を使用できます。 ほとんどの運用ワークロードと開発ワークロードでは Premium Storage を使用します。 Azure ディスクは ReadWriteOnce としてマウントされ、1 つの AKS ノードからのみ使用できるようになります。 複数のポッドから同時にアクセスする可能性のあるストレージ ボリュームについては、Azure Files を使用します。 コスト情報については、「Managed Disks の価格」を参照してください。

  • AKS ポッドには、Azure ストレージ アカウントを実体とする SMB (サーバー メッセージ ブロック) 3.0/3.1 ファイル共有が Azure Files によってマウントされます。 データは、複数のノードとポッドにまたがって共有できます。 Azure Files は、標準 HDD を実体とする Standard ストレージ、または高パフォーマンス SSD を実体とする Premium ストレージを使用できます。 Azure Files には Azure ストレージ アカウントが使用され、次の点に基づいて料金が課されます。

    • サービス: Blob、File、Queue、Table、アンマネージド ディスク
    • ストレージ アカウントの種類: GPv1、GPv2、BLOB、Premium BLOB
    • 回復性: ローカル冗長ストレージ (LRS)、ゾーン冗長ストレージ (ZRS)、geo 冗長ストレージ (GRS)、読み取りアクセス geo 冗長ストレージ (RA-GRS)
    • アクセス層: ホット、クール、アーカイブ
    • 操作とデータ転送
    • 使用容量 (GB)
  • Azure NetApp Files はいくつかの SKU レベルで提供され、プロビジョニングの最小容量は 4 TiB で、増分単位は 1 TiB となります。 Azure NetApp Files 料金は、次の点に基づきます。

    • SKU
    • 回復性: LRS、ZRS、GRS
    • (使用容量ではなく) プロビジョニングされたサイズまたは容量
    • 操作とデータ転送
    • バックアップと復元

ネットワーク コスト

いくつかの Azure ネットワーク サービスは、AKS で実行されるアプリケーションへのアクセスを提供できます。

  • Azure Load Balancer。 Load Balancer には、既定で Standard SKU が使用されます。 Load Balancer の料金は次の点に基づいて決まります。

    • 規則: 構成された負荷分散規則とアウトバウンド規則の数。 インバウンド ネットワーク アドレス変換 (NAT) 規則は規則の合計数にカウントされません。
    • 処理済みデータ: 規則に関係なくインバウンドとアウトバウンドで処理されたデータの量。 規則が構成されていない Standard load balancer には時間単位の料金はかかりません。
  • Azure Application Gateway。 AKS では、多くの場合、 Application Gateway イングレス コントローラーを介して、または手動で管理されたアプリケーション ゲートウェイを使って異なるイングレス コントローラーを前面にすることで Application Gateway が使用されます。 Application Gateway は、ゲートウェイ ルーティング、トランスポート層セキュリティ (TLS) 終了、および Web Application Firewall機能をサポートします。 Application Gateway の料金は次の点に基づいて決まります。

    • 時間または一部の時間によって設定された固定価格。
    • 容量ユニット価格 (追加される使用量ベースのコスト)。 各容量ユニットには、最大 1 つのコンピューティング ユニット、2,500 の永続的な接続、2.22 Mbps のスループットがあります。
  • パブリック IP アドレス には、次に依存するコストが関連付けられています。

    • 予約済みの関連付けと動的な関連付け。
    • 基本とセキュリティ保護およびゾーン冗長 Standard レベル。

スケールアウト コスト

AKS クラスターをスケーリングしてノード プールに別途容量を追加するには、複数の方法があります。

  • 必要に応じて、ノード プール内の VM 数を手動で更新したり、ノード プールをさらに追加したりできます。

  • AKS クラスターオートスケーラー は、リソース制約が原因でノードにスケジュールできないポッドを監視し、ノードの数を自動的に増やします。

  • AKS は、 virtual kubelet 実装を使用して、 Azure Container Instances 上でのコンテナーの実行をサポートします。 AKS の仮想ノードでは、数秒で起動する Container Instances ポッドがプロビジョニングされるため、平均的なワークロードにちょうど必要なだけの容量で AKS を動作させることができます。 AKS クラスターの容量が不足したら、追加のサーバーを管理しなくても Container Instances ポッドをさらにスケールアウトできます。 このアプローチは、クラスター オートスケーラーや手動スケーリングと併用することができます。

オンデマンド スケーリングまたはクラスター オートスケーラーを使用する場合は、追加される VM を考慮に入れてください。 Container Instances の料金は、次の点に基づきます。

  • コンテナー グループごとの使用量ベースのメトリック課金
  • 全体の vCPU とメモリ
  • 単一コンテナーの使用または複数コンテナーの共有
  • ネットワークとノードのライフサイクルを共有する共同スケジュール コンテナーの使用
  • イメージ プルの開始または再起動から停止までの使用時間計算
  • Windows コンテナー グループの追加料金

アップグレード コスト

AKS クラスター ライフサイクルの一部には、最新の Kubernetes バージョンへの定期的なアップグレードが含まれます。 最新のセキュリティ リリースを適用し、最新の機能を入手することが重要です。 AKS クラスターと単一ノード プールは、手動または自動でアップグレードできます。 詳細については、「Azure Kubernetes Service (AKS) クラスターのアップグレード」をご覧ください。

AKS は、既定で、1 つの追加ノードを使用してサージ操作するようにアップグレードを構成します。 max-surge 設定の既定値である 1 は、ワークロードの中断を最小限に抑えるために、別途ノードを作成し、それより古いバージョンのノードを置き換えたうえで、既存のアプリケーションの切断またはドレインを行います。 ノード プールごとに max-surge 値をカスタマイズすることで、アップグレード速度とアップグレード中断のトレードオフを考慮することができます。 max-surge 値を大きくすることでアップグレード プロセスはより速く完了しますが、 max-surge に大きな値を設定するとアップグレード プロセス中に中断が発生し、余分な VM コストが発生する可能性があります。

その他のコスト

使用法と要件によっては、AKS クラスターで別途次のコストが発生する可能性があります。

  • 使用した SKU (Basic、Standard、Premium のいずれか)、イメージ ビルド、ストレージに応じた Azure Container Registry のコスト。 余分なデータ転送料金を避けるために、Container Registry はクラスターと同じリージョンにデプロイしてください。 必要に応じてレプリケーションを使用し、できる限りイメージ サイズを減らして、ストレージ コストとデプロイ時間を抑えます。

  • Azure からのアウトバウンド データ転送 とリージョン間トラフィック。

  • その他ストレージまたは PaaS (サービスとしてのプラットフォーム) サービス (データベースなど)。

  • Azure Traffic Manager または Azure Front Door など、AKS ワークロードのパブリック エンドポイントにトラフィックをルーティングするグローバル ネットワーク サービス。

  • AKS クラスターとの間を行き来するトラフィックを検査して許可またはブロックするファイアウォールと保護サービス (Azure Firewall など)。

  • 監視とログ サービス (Azure Monitor Container InsightsAzure Monitor Application InsightsMicrosoft Defender for Cloudなど)。 詳細については、「Container insights の監視コストについて」を参照してください。

  • DevOps ツールに関連するコスト (Azure DevOps Services または GitHub など)。

コスト最適化

AKS クラスターのコストを最適化するうえで有効な推奨事項を次に示します。

  • AKS の Azure Well-Architected フレームワークの [Cost optimization] (コストの最適化) セクションを確認します。

  • マルチテナント ソリューションの場合、物理的な分離はコストが大きくなり、管理オーバーヘッドが増加します。 論理的な分離は、必要となる Kubernetes の経験が増し、変更とセキュリティの脅威にさらされる領域は増加しますが、コストは共同負担となります。

  • Azure の予約 は、AKS クラスター内の VM など、いくつかの製品に関して 1 年または 3 年間のプランにコミットすることでコストの節約効果が得られるものです。 容量を予約することで割引が適用されます。 エージェント ノードのコストを削減するには、ストレージコンピューティングに Azure の予約を使用します。

    予約によって、従量課金制の価格からリソース コストを最大 72% 削減できます。予約がリソースの実行時の状態に影響することはありません。 予約の購入後は、該当するリソースに割引が自動的に適用されます。 予約は、Azure portal から購入するか、Azure REST API、PowerShell、Azure CLI のいずれかを使用して購入できます。 Log Analytics ワークスペースに依存する運用ツールを使用する場合は、このストレージにも予約を使用することを検討してください。

  • AKS クラスターにスポット ノード プールを追加します。 スポット ノード プールは、 Azure スポット仮想マシン スケール セットを実体とするノード プールです。 AKS クラスター ノードにスポット VM を使用することで、活用されていない Azure 容量を、大幅に抑えたコストで利用することができます。 活用されていない容量のうち利用できる容量は、ノード サイズ、リージョン、時間帯など、いくつかの要因によって異なります。 利用できる容量がある場合、Azure によってスポット ノードが割り当てられますが、スポット ノードには SLA がありません。 スポット ノード プールをサポートするスポット スケール セットは 1 つの障害ドメインにデプロイされ、高可用性の保証は提供されません。 その容量が Azure で再び必要になると、スポット ノードは Azure インフラストラクチャによって削除されます。

    スポット ノード プールを作成する際は、1 時間あたりの最大価格を定義したうえで、スポット ノード プールに推奨されるクラスター オートスケーラーを有効にすることができます。 クラスター オートスケーラーは、実行中のワークロードに基づいて、ノード プール内のノード数をスケールアウトしたりスケールインしたりします。 スポット ノード プールから削除されたノードが引き続き必要な場合、クラスター オートスケーラーによってノードの数がスケールアウトされます。 詳細については、 Azure Kubernetes Service (AKS) クラスターにスポット ノード プールを追加する方法に関する記事を参照してください。

  • ワークロードの CPU とメモリの要件に基づき、AKS クラスター ノード プールに合った VM サイズ を選択します。 Azure では、CPU、メモリ、ストレージ、ネットワーク容量のさまざまな組み合わせで、幅広いユース ケースに対応する VM インスタンスの種類が数多く提供されています。 どの種類にもサイズが 1 つまたは複数用意されているので、リソースを簡単にスケーリングできます。

    Ampere Altra ARM ベースのプロセッサで実行されている AKS を使用して、コンテナー化されたアプリケーションをデプロイ、管理できるようになりました。 詳細については、 Ampere Altra ARM ベースのプロセッサを使用した Azure Virtual Machinesに関する記事を参照してください。

  • 特別な用途とワークロードのために、VM サイズが異なる複数のノード プールを作成します。 リソースを集中的に使用するアプリケーションを特定のノード プールに配置したり、"うるさい隣人" 問題を回避したりするため、Kubernetes の テイントと容認 および ノード ラベル を使用します。 これらのノードのリソースをそれが必要なワークロードで使用できるように保ち、そのノードでは他のワークロードをスケジュールしないようにします。 ノード プールごとに異なる VM サイズを使用することでコストを最適化することもできます。 詳細については、 Azure Kubernetes Service (AKS) で複数のノード プールを使用する方法に関する記事を参照してください。

  • システムモードのノード プールには少なくとも 1 つのノードを含める必要があり、ユーザーモードのノード プールには 0 台以上のノードを含めることができます。 可能であればいつでも、ユーザー モードのノード プールを構成して、 0 台から N 台の範囲でノードを自動的にスケーリングできます。 ワークロードのスケールアウトおよびスケールインは、Horizontal Pod Autoscaler を使用して構成できます。 CPU とメモリに基づくように自動スケーリングを行うか、または Kubernetes Event-driven Autoscaling (KEDA) を使用して、Apache Kafka、RabbitMQ、Azure Service Bus など外部システムのメトリックに基づくように自動スケーリングを行います。

  • アプリケーション密度を向上させ、ワークロードに CPU リソースとメモリ リソースを割り当てすぎないように、ポッドの 要求と制限 を適切に設定します。 Prometheus または Container Insights を使用して、CPU とメモリの平均と最大の消費量を観察してください。 デプロイの YAML マニフェスト、Helm チャート、Kustomize マニフェストでポッドの制限とクォータを適切に構成します。

  • ResourceQuota オブジェクトを使用し、特定の 名前空間で実行されているすべてのポッドについて、CPU とメモリの合計サイズに対するクォータを設定します。 リソース クォータを体系的に使用することで、"うるさい隣人" 問題を回避し、アプリケーション密度を向上させ、エージェント ノードの数と総コストを削減できます。 また、 LimitRange オブジェクトを使用して、名前空間内のポッドの既定の CPU 要求とメモリ要求を構成します。

  • バーストに Container Instances を使用します。

  • AKS ワークロードは、開発クラスター ノード プールの特定のワークロードなど、継続的に実行する必要がない場合があります。 コストを最適化するために、完全に AKS クラスターをオフにするか、AKS クラスター内の 1 つまたは複数のノード プールを停止できます。 詳細については、「Azure Kubernetes Service (AKS) クラスターの停止と起動」および Azure Kubernetes Service (AKS) でのノード プールの起動と停止に関する記事を参照してください。

  • Azure Policy は、組み込みのポリシーを通じて AKS と連携し、一元化された一貫性のある大規模な実施と保護を適用します。 クラスターで Azure Policy アドオンを有効にし、既定の CPU 要求と制限、および メモリ リソースの制限を適用します。これによってクラスターのコンテナーに対する CPU とメモリ リソースの制限が確実に定義されます。

  • Azure Advisor を使用して、未使用のリソースを監視および解放します。

  • Microsoft Cost Management の予算とレビューを使用して支出を追跡します。

コスト ガバナンス

クラウドにより、ビジネス ワークロードの技術的なパフォーマンスを大幅に向上させることができます。 組織の資産を管理するコストとオーバーヘッドも、クラウド テクノロジによって削減できます。 ただし、このビジネス チャンスによってリスクも生じます。クラウド デプロイによって廃棄物や非効率の可能性が高まる場合があるためです。

コスト ガバナンスは、支出とコストを制限するポリシーまたはコントロールを継続的に導入するプロセスです。 ネイティブの Kubernetes ツールと Azure ツールはどちらも、プロアクティブな監視と基になるインフラストラクチャ コストの最適化によるコスト ガバナンスをサポートします。

  • Microsoft Cost Management は、Azure ワークロードのコストの分析、管理、最適化に役立つ Microsoft ツールのスイートです。 このスイートを使用すると、組織がクラウドによってもたらされるベネフィットを確実に活用できます。

  • クラウド導入フレームワーク ガバナンスのベスト プラクティスで Cost Management の規範 を確認し、クラウドのコストを管理する方法について理解を深めます。

  • KubeCost など、AKS クラスターのコストを監視、管理するためのオープンソース ツールを詳しく調べます。 コスト割り当てのスコープをデプロイ、サービス、ラベル、ポッド、名前空間に指定できるため、クラスター ユーザーの表示と請求での柔軟性が提供されます。

リファレンス マニュアル

AKS コスト分析のさらなる理解と活用に役立つ参考資料を次に示します。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

その他の共同作成者:

  • Chad Kittel | プリンシパル ソフトウェア エンジニア
  • Ed Price | シニア コンテンツ プログラム マネージャー
  • Theano Petersen | テクニカル ライター

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ