Amazon EKS コストを可視化する - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon EKS コストを可視化する

概要

Kubernetes デプロイのコストを効果的にモニタリングするには、全体像を把握する必要があります。唯一の固定コストと既知のコストは、Amazon Elastic Kubernetes Service (Amazon EKS) コントロールプレーンです。これには、コンピューティングやストレージからネットワークまで、デプロイを構成する他のすべてのコンポーネントが含まれます。これは、アプリケーションのニーズに応じて変動する量です。

Kubecost を使用して、名前空間サービスから個々のポッドまで、Kubernetes インフラストラクチャのコストを分析し、ダッシュボードにデータを表示できます。Kubecost では、コンピューティングやストレージなどのクラスター内コストと、Amazon Simple Storage Service (Amazon S3) バケットや Amazon Relational Database Service (Amazon RDS) インスタンスなどのout-of-clusterコストが表示されます。Kubecost は、このデータに基づいて適切なサイズのレコメンデーションを行い、システムに影響を与える可能性のある重要なアラートを表示します。Kubecost は と統合AWS Cost and Usage Reportして、Compute Savings Plansリザーブドインスタンス、その他の割引プログラムによる削減額を表示できます。

コスト上の利点

Kubecost は、Amazon EKS デプロイのコストを視覚化するレポートとダッシュボードを提供します。これにより、クラスターからコントローラー、サービス、ノード、ポッド、ボリュームなどのさまざまなコンポーネントにドリルダウンできます。これにより、Amazon EKS 環境で実行されているアプリケーションの全体像を把握できます。この可視性を有効にすると、Kubecost の推奨事項に基づいて行動したり、各アプリケーションのコストをきめ細かく表示したりできます。Amazon EKS ノードグループのサイズを適切に設定すると、標準の EC2 インスタンスと同じ削減額が得られます。コンテナとノードのサイズを適正化できる場合は、コンテナの実行に必要なインスタンスのサイズと Auto Scaling グループに必要な EC2 インスタンスの数からコンピューティングの肥大化を削除できます。

コスト最適化に関する推奨事項

Kubecost を利用するには、以下を実行することをお勧めします。

  1. 環境に Kubecost をデプロイする

  2. Windows アプリケーションの詳細なコスト内訳を取得する

  3. 適切なサイズのクラスターノード

  4. 適切なサイズのコンテナリクエスト

  5. 使用率の低いノードを管理する

  6. 中止されたワークロードの修復

  7. レコメンデーションに基づく行動

  8. セルフマネージド型ノードを更新する

環境に Kubecost をデプロイする

Amazon EKS Finhack Workshop では、 AWS 所有アカウントで Kubecost を使用するように設定された Amazon EKS 環境をデプロイする方法について説明します。これにより、 テクノロジーを実際に体験できます。組織でこのワークショップを実行することに関心がある場合は、 アカウントチームにお問い合わせください。

Helm を使用して Kubecost を Amazon EKS クラスターにデプロイするには、 AWS AWS と Kubecost が共同で EKS のお客様にコストモニタリングを提供するブログ記事を参照してください。または、Kubecost のインストールと設定の手順については、Kubecost の公式ドキュメントを参照してください。Windows ノードの Kubecost サポートの詳細については、Kubecost ドキュメントの「Windows ノードのサポート」を参照してください。

Windows アプリケーションの詳細なコスト内訳を取得する

Amazon EC2 スポットインスタンスを使用すると大幅なコスト削減を実現できますが、Windows ワークロードがステートフルである傾向があることからもメリットを得られます。スポットインスタンスの使用はアプリケーションによって異なります。ユースケースに該当するかどうかを確認することをお勧めします。

Windows アプリケーションの詳細なコスト内訳を取得するには、Kubecost にログインします。ナビゲーションページで、Savings を選択します。

適切なサイズのクラスターノード

Kubecost で、ナビゲーションバーから Savings を選択し、クラスターノードの適切なサイズを選択します。

Kubecost がクラスターが vCPU と RAM の両方で過剰にプロビジョニングされていることを報告する例を考えてみましょう。次の表は、Kubecost の詳細と推奨事項を示しています。

  Current 推奨事項: シンプル 推奨事項: 複雑
合計数 1 か月あたり 3,462.57 USD 1 か月あたり 137.24 USD 1 か月あたり 303.68 USD
ノード数 4 5 4
CPU 74 VCPUs 10 VCPUs 8 VCPUs
RAM 152 GB 20 GB 18 GB
インスタンスの内訳 2 c5.xlarge + 2 その他 5 t3a.medium 2 c5n.large + 1 その他

Kubecost ブログ記事「Kubernetes クラスターに最適なノードのセットを見つける」で説明されているように、シンプルなオプションは単一のノードグループを使用しますが、複雑なオプションはマルチノードグループのアプローチを使用します。ボタンの採用方法を学ぶ は、ワンクリックでクラスターのサイズ変更を実行できます。これには、Kubecost クラスターコントローラーのインストールが必要です。

eksctl によって作成されていないセルフマネージド型 Windows ノードを使用している場合は、「既存のセルフマネージド型ノードグループの更新」を参照してください。以下の手順では、Auto Scaling グループで使用される Amazon EC2 起動テンプレートでインスタンスタイプを変更する方法を示します。

適切なサイズのコンテナリクエスト

Kubecost で、ナビゲーションバーから Savings を選択し、「適切なサイズのレコメンデーションをリクエストする」ページに移動します。このページでは、ポッドの効率、適切なサイズの推奨事項、および推定コスト削減について説明します。カスタマイズボタンを使用して、クラスターノード名前空間\コントローラーなどでフィルタリングできます。

たとえば、Kubecost が CPU と RAM (メモリ) の点で一部のポッドがオーバープロビジョニングされていると計算したとします。次に、Kubecost では、新しい CPU 値と RAM 値に調整して、毎月の推定削減額を達成することをお勧めします。CPU と RAM の値を変更するには、デプロイマニフェストファイルを更新する必要があります。

使用率の低いノードを管理する

Kubecost で、ナビゲーションバーから Savings を選択し、使用率の低いノードの管理を選択します。

このページで、クラスター内の 1 つのノードが CPU と RAM (メモリ) の点で十分に活用されていないため、ドレインして終了またはサイズ変更できる例を考えてみましょう。ノードとポッドのチェックに合格しないノードを選択すると、ドレインできない理由の詳細が表示されます。

中止されたワークロードの修復

Kubecost で、ナビゲーションバーから Savings を選択し、中止されたワークロードページを選択します。この例では、Windows と呼ばれる名前空間でフィルタリングします。このページには、トラフィックのしきい値に達しておらず、中止されたと見なされるポッドが表示されます。ポッドは、定義された期間に一定量のネットワークトラフィックを送受信する必要があります。

1 つ以上のポッドが中止されることを慎重に検討した後、レプリカの数をスケールダウンし、デプロイを削除し、リソースを消費しないようにサイズ変更するか、デプロイが中止されたと思われることをアプリケーション所有者に通知することで、コストを削減できます。

レコメンデーションに基づく行動

「クラスターノードの適切なサイズ設定」セクションで、Kubecost はクラスター内のワーカーノードの使用状況を分析し、コストを削減するためにノードの適切なサイズ設定に関するレコメンデーションを行います。Amazon EKS で使用できるノードグループには、セルフマネージド型マネージド型の 2 種類があります。

セルフマネージド型ノードを更新する

セルフマネージド型ノードの更新については、Amazon EKS ドキュメントの「セルフマネージド型ノードの更新」を参照してください。を使用して作成されたノードグループは更新eksctlできず、新しい設定で新しいノードグループに移行する必要があることを示しています。

たとえば、 ng-windows-m5-2xlarge (m5.2xlarge EC2 インスタンスを使用する) という Windows ノードグループがあり、ポッドを ng-windows-t3-large (コストを削減するために t3.large EC2 インスタンスによってバックアップされる) という新しいノードグループに移行するとします。

によってデプロイされたノードグループを使用するときに新しいノードグループに移行するにはeksctl、次の手順を実行します。

  1. ポッドが現在存在するノードを検索するには、 kubectl describe pod <pod_name> -n <namespace> コマンドを実行します。

  2. kubectl describe node <node_name> コマンドを実行します。出力は、ノードが m5.2xlarge インスタンスで実行されていることを示しています。また、ノードグループ名 () とも一致しますng-windows-m5-2xlarge

  3. ノードグループ を使用するようにデプロイを変更するにはng-windows-t3-large、ノードグループ を削除ng-windows-m5-2xlargeして を実行しますkubectl describe svc,deploy,pod -n windows。ノードグループが削除されると、デプロイはすぐに再デプロイを開始します。

    注記

    ノードグループを削除すると、サービスのダウンタイムが発生します。

  4. 数分後にkubectl describe svc,deploy,pod -n windowsコマンドを再度実行します。出力は、ポッドがすべて再び実行中状態であることを示しています。

  5. ポッドがノードグループ で実行されていることを表示するにはng-windows-t3-largekubectl describe pod <pod_name> -n <namespace>および kubectl describe node <node_name> コマンドを再度実行します。

代替のサイズ変更方法

この方法は、セルフマネージド型またはマネージド型ノードグループの任意の組み合わせに適用されます。「EKS セルフマネージド型ノードグループから EKS マネージド型ノードグループへのワークロードのシームレス移行」ブログ記事では、オーバーサイズのインスタンスタイプの 1 つのノードグループから、ダウンタイムなしで適切なサイズのノードグループにワークロードを移行する方法に関するガイダンスを提供しています。

次のステップ

Kubecost を使用すると、Amazon EKS 環境のコストを簡単に視覚化できます。Kubecost と Kubernetes および AWS APIs の深い統合は、潜在的なコスト削減を見つけるのに役立ちます。これらは、Kubecost の Savings ダッシュボードでレコメンデーションとして確認できます。Kubecost は、クラスターコントローラー機能を通じてこれらの推奨事項の一部を実装することもできます。

「」のstep-by-stepデプロイAWS 」と「Kubecost collaborate to deliver cost monitoring for EKS customers」のブログ投稿を AWS Containers ブログから確認することをお勧めします。

その他のリソース