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) インスタンスなどのクラスター外コストを明らかにします。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 Node Support」を参照してください。

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

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

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

クラスターノードを適切にサイズ設定する

Kubecost で、ナビゲーションバーから [削減額] を選択し、[クラスターノードを適切なサイズにする] を選択します。

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

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

Kubecost ブログ記事「Find an optimal set of nodes for a Kubernetes cluster」で説明されているように、シンプルなオプションでは単一のノードグループを使用しますが、複雑なオプションではマルチノードグループのアプローチを使用します。[導入する方法] ボタンを使用すると、ワンクリックでクラスターのサイズ変更を実行できます。これには、Kubecost Cluster Controller のインストールが必要です。

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

コンテナリクエストを適切にサイズ設定する

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

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

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

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

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

中止されたワークロードを修復する

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

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

推奨事項に基づいて行動する

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

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

セルフマネージド型ノードの更新については、Amazon EKS ドキュメントの「Self-managed node updates」を参照してください。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-large で実行されていることを表示するには、kubectl describe pod <pod_name> -n <namespace> コマンドと kubectl describe node <node_name> コマンドを再度実行します。

代替のサイズ変更方法

この方法は、セルフマネージド型またはマネージド型ノードグループの任意の組み合わせに適用されます。ブログ記事「Seamlessly migrate workloads from EKS self-managed node group to EKS-managed node groups」には、ダウンタイムなしで、オーバーサイズのインスタンスタイプを持つ 1 つのノードグループから、適切にサイズ設定されたノードグループにワークロードを移行する方法に関するガイダンスが記載されています。

次の手順

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

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

その他のリソース