翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
コンピューティングと自動スケーリング
開発者は、CPU やメモリなどのアプリケーションのリソース要件について見積もりを行いますが、継続的に調整しないと古くなり、コストが増加し、パフォーマンスと信頼性が低下する可能性があります。アプリケーションのリソース要件を継続的に調整することは、初めて正しく設定するよりも重要です。
以下に説明するベストプラクティスは、コストを最小限に抑え、組織が投資収益率を最大化しながら、ビジネス成果を達成するコスト対応ワークロードを構築して運用するのに役立ちます。クラスターのコンピューティングコストを最適化するための重要度の高い順序は次のとおりです。
-
適切なサイズのワークロード
-
未使用の容量を減らす
-
コンピューティングキャパシティタイプ (スポットなど) とアクセラレーター (GPUs) を最適化する
ワークロードの適切なサイズ設定
ほとんどの EKS クラスターでは、コストの大部分は、コンテナ化されたワークロードの実行に使用される EC2 インスタンスから発生します。ワークロードの要件を理解しないと、コンピューティングリソースのサイズを適正化することはできません。そのため、適切なリクエストと制限を使用し、必要に応じてそれらの設定を調整することが不可欠です。さらに、インスタンスサイズやストレージの選択などの依存関係はワークロードのパフォーマンスに影響を与える可能性があり、コストや信頼性に意図しないさまざまな影響を与える可能性があります。
リクエストは実際の使用率と一致する必要があります。コンテナのリクエストが高すぎると、未使用の容量が発生し、クラスターの合計コストの大きな要因になります。アプリケーションやサイドカーなど、ポッド内の各コンテナには、ポッドの集約制限が可能な限り正確になるように独自のリクエストと制限を設定する必要があります。
コンテナのリソースリクエストと制限を見積もる、Goldilocks
Horizontal Pod Autoscaler (HPA) を使用して、実行するアプリケーションのレプリカの数を制御し、Vertical Pod Autoscaler (VPA) を使用してレプリカごとにアプリケーションに必要なリクエストの数を調整して制限し、Karpenter
Vertical Pod Autoscaler は、コンテナに割り当てられたリクエストと制限を調整して、ワークロードが最適に実行されるようにできます。ポッドを自動的に変更して再起動しないように、VPA を監査モードで実行する必要があります。観測されたメトリクスに基づいて変更を提案します。本番稼働用ワークロードに影響する変更は、アプリケーションの信頼性とパフォーマンスに影響を与える可能性があるため、本番稼働用以外の環境で最初に変更を確認してテストする必要があります。
消費量の削減
コストを削減する最善の方法は、より少ないリソースをプロビジョニングすることです。そのための 1 つの方法は、現在の要件に基づいてワークロードを調整することです。コスト最適化の取り組みは、ワークロードが要件を定義し、動的にスケールするようにすることから始める必要があります。そのためには、アプリケーションからメトリクスを取得し、アプリケーションが動的に安全にスケールアップおよびスケールダウンできるように、 PodDisruptionBudgets
Horizontal Pod Autoscaler は、アプリケーションのパフォーマンスと信頼性の要件を満たすために必要なレプリカの数を調整できる柔軟なワークロードオートスケーラーです。CPU、メモリ、キューの深さ、ポッドへの接続数などのカスタムメトリクスなど、さまざまなメトリクスに基づいてスケールアップ/ダウンするタイミングを定義する柔軟なモデルがあります。
Kubernetes メトリクスサーバーは、CPU やメモリの使用量などの組み込みメトリクスに応じてスケーリングを有効にしますが、Amazon CloudWatch や SQS キューの深さなどの他のメトリクスに基づいてスケーリングする場合は、KEDA
ワークロードの消費量を減らすと、クラスターの容量が過剰になり、適切な自動スケーリング設定により、ノードを自動的にスケールダウンして総支出を削減できます。コンピューティング容量を手動で最適化しないことをお勧めします。Kubernetes スケジューラとノードオートスケーラーは、このプロセスを処理するように設計されています。
未使用の容量を減らす
アプリケーションの正しいサイズを決定し、過剰なリクエストを減らしたら、プロビジョニングされたコンピューティング容量を減らし始めることができます。上記のセクションからワークロードを正しくサイズ設定する時間がかかっている場合は、これを動的に実行できます。AWS の Kubernetes で使用されるプライマリノードオートスケーラーは 2 つあります。
Karpenter と Cluster Autoscaler
Karpenter と Kubernetes Cluster Autoscaler の両方が、ポッドの作成または削除とコンピューティング要件の変更に応じて、クラスター内のノード数をスケーリングします。両方の主な目標は同じですが、Karpenter はノード管理のプロビジョニングとプロビジョニング解除に異なるアプローチを採用しているため、コストを削減し、クラスター全体の使用量を最適化できます。
クラスターのサイズが大きくなり、ワークロードの種類が増えるにつれて、ノードグループとインスタンスを事前設定することが難しくなります。ワークロードリクエストと同様に、初期ベースラインを設定し、必要に応じて継続的に調整することが重要です。
Cluster Autoscaler を使用している場合、各 Auto Scaling グループ (ASG) の「最小」値と「最大」値を尊重し、「希望する」値のみを調整します。Cluster Autoscaler は「最小」数を超えて ASG をスケールダウンできないため、基盤となる ASG にこれらの値を設定するときは注意することが重要です。「希望する」カウントを通常の営業時間に必要なノード数として設定し、「最小」を営業時間外に必要なノード数として設定します。Cluster Autoscaler のよくある質問
クラスターオートスケーラー Priority Expander
Kubernetes Cluster Autoscaler は、ノードグループと呼ばれるノードのグループをスケールアップおよびスケールダウンすることで機能します。ワークロードを動的にスケーリングしていない場合、Cluster Autoscaler はコスト削減には役立ちません。Cluster Autoscaler では、ワークロードが消費されるように、クラスター管理者が事前にノードグループを作成する必要があります。ノードグループは、同じ「プロファイル」を持つインスタンスを使用するように設定する必要があります。つまり、CPU とメモリの量はほぼ同じです。
複数のノードグループを持つことができ、Cluster Autoscaler は優先度スケーリングレベルを設定するように設定でき、各ノードグループには異なるサイズのノードを含めることができます。ノードグループは異なる容量タイプを持つことができ、優先度エクスパンダーを使用して、安価なグループを最初にスケーリングできます。
以下は、 を使用してオンデマンドインスタンスを使用する前にリザーブドキャパシティConfigMap`に優先順位を付けるクラスター設定のスニペットの例です。同じ手法を使用して、他のタイプよりも Graviton インスタンスまたはスポットインスタンスに優先順位を付けることができます。
apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster managedNodeGroups: - name: managed-ondemand minSize: 1 maxSize: 7 instanceType: m5.xlarge - name: managed-reserved minSize: 2 maxSize: 10 instanceType: c5.2xlarge
apiVersion: v1 kind: ConfigMap metadata: name: cluster-autoscaler-priority-expander namespace: kube-system data: priorities: |- 10: - .*ondemand.* 50: - .*reserved.*
ノードグループを使用すると、基盤となるコンピューティングリソースがデフォルトで期待どおりのことを行うのに役立ちます。たとえば、ノードを AZs に分散できますが、すべてのワークロードが同じ要件や期待値を持つわけではないため、アプリケーションに要件を明示的に宣言させることをお勧めします。Cluster Autoscaler の詳細については、「ベストプラクティス」セクションを参照してください。
デスケジューラ
Cluster Autoscaler は、スケジュールする必要がある新しいポッド、またはノードが十分に活用されていないことに基づいて、クラスターからノード容量を追加および削除できます。ノードにスケジュールされた後、ポッド配置の完全リストビューは表示されません。Cluster Autoscaler を使用している場合は、クラスターの容量の浪費を避けるために、Kubernetes デスケジューラ
クラスターに 10 個のノードがあり、各ノードが 60% 使用されている場合、クラスター内のプロビジョニングされた容量の 40% を使用していません。Cluster Autoscaler では、ノードあたりの使用率しきい値を 60% に設定できますが、使用率が 60% を下回った後にのみ、1 つのノードをスケールダウンしようとします。
デスケジューラを使用すると、ポッドがスケジュールされた後、またはノードがクラスターに追加された後に、クラスターの容量と使用率を確認できます。クラスターの合計容量を指定されたしきい値を超えて維持しようとします。また、ノードテイントまたはクラスターに参加する新しいノードに基づいてポッドを削除して、ポッドが最適なコンピューティング環境で実行されていることを確認することもできます。デスケジューラは削除されたポッドの置き換えをスケジュールしませんが、そのためにデフォルトのスケジューラに依存することに注意してください。
Karpenter の統合
Karpenter はノード管理に「グループレス」アプローチを採用しています。このアプローチは、さまざまなワークロードタイプに対してより柔軟であり、クラスター管理者の事前設定が少なくて済みます。Karpenter は、グループを事前定義し、ワークロードのニーズに応じて各グループをスケーリングする代わりに、プロビジョナーとノードテンプレートを使用して、作成できる EC2 インスタンスのタイプと、作成時にインスタンスに関する設定を広く定義します。
ビンパッキングは、より多くのワークロードをより少ない最適なサイズのインスタンスにパッキングすることで、インスタンスのリソースをさらに活用する方法です。これにより、ワークロードが使用するリソースのみをプロビジョニングすることでコンピューティングコストを削減できますが、トレードオフがあります。特に大規模なスケーリングイベント中に容量をクラスターに追加する必要があるため、新しいワークロードの開始に時間がかかる場合があります。ビンパッキングを設定するときは、コストの最適化、パフォーマンス、可用性のバランスを考慮してください。
Karpenter は、インスタンスリソースの使用率を向上させ、コンピューティングコストを削減するために、継続的にモニタリングとバイナリパックを行うことができます。Karpenter は、ワークロードによりコスト効率の高いワーカーノードを選択することもできます。これは、プロビジョナーで「統合」フラグを true にすることで実現できます (以下のサンプルコードスニペット）。以下の例は、統合を有効にするプロビジョナーの例を示しています。このガイドを書いている時点で、Karpenter は実行中のスポットインスタンスをより安価なスポットインスタンスに置き換えません。Karpenter の統合の詳細については、このブログ
apiVersion: karpenter.sh/v1 kind: Provisioner metadata: name: enable-binpacking spec: consolidation: enabled: true
チェックポイントなしで長時間実行されるバッチジョブなど、中断できないワークロードの場合は、ポッドに注釈を付けることを検討してくださいdo-not-evict。ポッドをエビクションからオプトアウトすることで、このポッドを含むノードを自発的に削除しないように Karpenter に伝えます。ただし、ノードのドレイン中にdo-not-evictポッドがノードに追加された場合、残りのポッドは引き続き削除されますが、そのポッドは削除されるまで終了をブロックします。いずれの場合も、ノードは、ノードで追加の作業がスケジュールされないように接続されます。注釈の設定方法の例を以下に示します。
apiVersion: v1 kind: Pod metadata: name: label-demo labels: environment: production annotations: + "karpenter.sh/do-not-evict": "true" spec: containers: * name: nginx image: nginx ports: ** containerPort: 80
Cluster Autoscaler パラメータを調整して使用率の低いノードを削除する
ノード使用率は、リクエストされたリソースの合計を容量で割ったものとして定義されます。デフォルトでは、 scale-down-utilization-thresholdは 50% に設定されています。このパラメータは、 および とともに使用できます。これによりscale-down-unneeded-time、スケールダウンの対象となる前にノードが不要になる時間を決定できます。デフォルトは 10 分です。スケールダウンされたノードでまだ実行されているポッドは、kube-scheduler によって他のノードでスケジュールされます。これらの設定を調整すると、使用率の低いノードを削除できますが、クラスターを強制的に早期にスケールダウンしないように、まずこれらの値をテストすることが重要です。
削除にコストがかかるポッドが Cluster Autoscaler によって認識されるラベルで保護されるようにすることで、スケールダウンの発生を防ぐことができます。これを行うには、削除にコストがかかるポッドに注釈 があることを確認しますcluster-autoscaler.kubernetes.io/safe-to-evict=false。以下は、注釈を設定するための yaml の例です。
apiVersion: v1 kind: Pod metadata: name: label-demo labels: environment: production annotations: + "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" spec: containers: * name: nginx image: nginx ports: ** containerPort: 80
Cluster Autoscaler と Karpenter を使用してノードにタグを付ける
AWS リソースタグは、リソースを整理し、AWS のコストを詳細レベルで追跡するために使用されます。コスト追跡のために Kubernetes ラベルと直接相関することはありません。Kubernetes リソースラベル付けから開始し、Kubecost
ワーカーノードには、AWS Cost Explorer で請求情報を表示するためのタグが必要です。Cluster Autoscaler では、起動テンプレートを使用してマネージド型ノードグループ内のワーカーノードにタグを付けます。セルフマネージド型ノードグループの場合は、EC2 自動スケーリンググループを使用してインスタンスにタグを付けます。Karpenter によってプロビジョニングされたインスタンスの場合は、ノードテンプレートの spec.tags を使用してタグ付けします
マルチテナントクラスター
異なるチームによって共有されているクラスターを操作する場合、同じノードで実行されている他のワークロードを可視化できない場合があります。リソースリクエストは、CPU 共有などの「ノイズの多い近隣」の懸念を分離するのに役立ちますが、ディスク I/O の枯渇などのすべてのリソース境界を分離するとは限りません。ワークロードのすべての使用可能なリソースを分離または制限できるわけではありません。共有リソースを他のワークロードよりも高い割合で消費するワークロードは、ノードのテイントと許容度
ノードレベルでワークロードを分離するとコストがかかる場合がありますが、リザーブドインスタンス、Graviton プロセッサ
共有クラスターには、IP の枯渇、Kubernetes サービスの制限、API スケーリングリクエストなどのクラスターレベルのリソース制約もあります。スケーラビリティのベストプラクティスガイドを確認して、クラスターがこれらの制限を回避する必要があります。
リソースは、名前空間または Karpenter プロビジョナーレベルで分離できます。Resource Quotas
Karpenter プロビジョナーは、クラスター内の一部の使用可能なリソース (CPU、GPU など) に制限を設定できます
スケジュールされた Auto Scaling
週末やオフ時間にクラスターをスケールダウンする必要がある場合があります。これは、使用されていないときにゼロにスケールダウンするテストクラスターと非本番クラスターに特に関連します。cluster-turndown
コンピューティングキャパシティタイプを最適化する
クラスター内のコンピューティングの合計容量を最適化し、ビンパッキングを利用したら、クラスターでプロビジョニングしたコンピューティングのタイプと、それらのリソースに対する支払い方法を確認する必要があります。AWS には、コンピューティングのコストを削減できる Compute Savings プラン
-
Spot
-
積立プラン
-
オンデマンド
-
Fargate
キャパシティタイプごとに管理オーバーヘッド、可用性、長期コミットメントのトレードオフが異なるため、どちらが環境に適しているかを決定する必要があります。1 つのキャパシティタイプに依存する環境はなく、1 つのクラスターに複数の実行タイプを組み合わせて、特定のワークロード要件とコストを最適化できます。
Spot
スポット
スポットコンピューティングでは、スポット容量が利用できない可能性を減らすために、さまざまなインスタンスタイプを使用する必要があります。インスタンスの中断は、ノードを安全にシャットダウンするために処理する必要があります。Karpenter または Managed Node Group の一部でプロビジョニングされたノードは、インスタンスの中断通知を自動的にサポートします。セルフマネージド型ノードを使用している場合は、スポットインスタンスを適切にシャットダウンするために、ノード終了ハンドラー
スポットインスタンスとオンデマンドインスタンスを 1 つのクラスターでバランスさせることができます。Karpenter を使用すると、加重プロビジョナー
以下は、Karpenter を使用してオンデマンドインスタンスよりもスポットインスタンスを優先する例です。プロビジョナーを作成するときは、スポット、オンデマンド、またはその両方を指定できます (以下を参照）。両方を指定し、ポッドがスポットとオンデマンドのどちらを使用する必要があるかを明示的に指定しない場合、Karpenter は price-capacity-optimization 配分戦略
apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
name: spot-prioritized
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot", "on-demand"]
Savings Plans、リザーブドインスタンス、AWS EDP
コンピューティング削減プランを使用すると、コンピューティング
コンピューティング節約プランは、使用するインスタンスタイプ、ファミリー、またはリージョンに関するコミットメントを必要とせずに、EC2 コストを最大 66% 削減できます。節約は、使用するインスタンスに自動的に適用されます。
EC2 Instance Savings Plans は、コンピューティングを最大 72% 削減し、C ファミリーのインスタンスなど、特定のリージョンと EC2 ファミリーでの使用を約束します。リージョン内の任意の AZ に使用状況をシフトしたり、c5 や c6 などの任意の世代のインスタンスファミリーを使用したり、ファミリー内の任意のサイズのインスタンスを使用したりできます。割引は、Savings Plans 基準に一致するアカウント内のすべてのインスタンスに自動的に適用されます。
リザーブドインスタンス
お客様は、AWS とのエンタープライズ契約に登録することもできます。エンタープライズ契約では、ニーズに最適な契約を調整できます。お客様は、AWS EDP (エンタープライズ割引プログラム) に基づく料金で割引を受けることができます。エンタープライズ契約の詳細については、AWS 販売担当者にお問い合わせください。
オンデマンド
オンデマンド EC2 インスタンスには、Savings Plans と比較して、スポットと比較して中断のない可用性という利点があり、長期のコミットメントはありません。クラスターのコストを削減する場合は、オンデマンド EC2 インスタンスの使用量を減らす必要があります。
ワークロード要件を最適化したら、クラスターの最小容量と最大容量を計算できるはずです。この数は時間の経過とともに変化する可能性がありますが、ほとんど減少しません。最小限のものすべてに Savings Plan sを使用することを検討し、アプリケーションの可用性に影響を与えない容量を見つけます。継続的に使用されない、または可用性のために必要になるその他のものは、オンデマンドで使用できます。
このセクションで説明したように、使用量を減らす最善の方法は、より少ないリソースを消費し、プロビジョニングしたリソースを可能な限り最大限活用することです。Cluster Autoscaler を使用すると、 scale-down-utilization-threshold設定で使用率の低いノードを削除できます。Karpenter では、統合を有効にすることをお勧めします。
ワークロードで使用できる EC2 インスタンスタイプを手動で識別するには、ec2-instance-selector を使用する必要があります。ec2
ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 \ -r us-east-1 --service eks c5.large c5a.large c5ad.large c5d.large c6a.large c6i.large t2.medium t3.medium t3a.medium
非本番環境では、夜間や週末などの未使用の時間帯にクラスターを自動的にスケールダウンできます。kubecost プロジェクトの cluster-turndown
Fargate コンピューティング
Fargate コンピューティングは、EKS クラスター用のフルマネージド型のコンピューティングオプションです。Kubernetes クラスターのノードごとに 1 つのポッドをスケジュールすることで、ポッドを分離できます。これにより、コンピューティングノードをワークロードの CPU および RAM 要件に合わせてサイズ設定し、クラスター内のワークロード使用率を厳密に制御できます。
Fargate は、0.5 GB のメモリを搭載した .25 vCPU から、120 GB のメモリを搭載した 16 vCPU までワークロードをスケールできます。使用可能なポッドサイズのバリエーションには制限があり、ワークロードが Fargate 設定にどのように最適に適合するかを理解する必要があります。たとえば、ワークロードに 0.5 GB のメモリを持つ 1 つの vCPU が必要な場合、最小の Fargate ポッドは 2 GB のメモリを持つ 1 つの vCPU になります。
Fargate には EC2 インスタンスやオペレーティングシステム管理がないなど多くの利点がありますが、デプロイされたすべてのポッドがクラスター内の個別のノードとして分離されているため、従来の EC2 インスタンスよりも多くのコンピューティング容量が必要になる場合があります。そのためには、Kubelet、ロギングエージェント、通常ノードにデプロイする DaemonSets などに対して、さらに重複する必要があります。DaemonSets は Fargate ではサポートされていないため、ポッド「サイドカー」に変換してアプリケーションと一緒に実行する必要があります。
Fargate は、ワークロードの境界がバースト不可能またはワークロード間で共有できないノードであるため、プロビジョニングよりもビンパッキングや CPU のメリットを享受できません。Fargate は、それ自体にコストがかかる EC2 インスタンス管理時間を節約しますが、CPU とメモリのコストは他の EC2 容量タイプよりも高価になる可能性があります。Fargate ポッドは、コンピューティング削減プランを活用してオンデマンドコストを削減できます。
コンピューティング使用量の最適化
コンピューティングインフラストラクチャのコストを削減するもう 1 つの方法は、ワークロードに対してより効率的なコンピューティングを使用することです。これは、x86 よりも最大 20% 安価でエネルギー効率が 60% 高い Graviton プロセッサ
EKS には、混合アーキテクチャ (amd64 や arm64 など) でクラスターを実行する機能があり、コンテナが複数のアーキテクチャ用にコンパイルされている場合は、プロビジョナーで両方のアーキテクチャを許可することで、Karpenter で Graviton プロセッサを活用できます。ただし、一貫したパフォーマンスを維持するには、各ワークロードを 1 つのコンピューティングアーキテクチャに保持し、使用可能な追加の容量がない場合にのみ異なるアーキテクチャを使用することをお勧めします。
プロビジョナーは複数のアーキテクチャで設定でき、ワークロードはワークロード仕様で特定のアーキテクチャをリクエストすることもできます。
apiVersion: karpenter.sh/v1 kind: Provisioner metadata: name: default spec: requirements: - key: "kubernetes.io/arch" operator: In values: ["arm64", "amd64"]
Cluster Autoscaler では、Graviton インスタンス用のノードグループを作成し、新しい容量を利用するためにワークロードにノードの許容範囲
GPUsと FPGAsはワークロードのパフォーマンスを大幅に向上させることができますが、アクセラレーターを使用するようにワークロードを最適化する必要があります。機械学習と人工知能の多くのワークロードタイプはコンピューティングに GPUs を使用でき、インスタンスはリソースリクエストを使用してクラスターに追加し、ワークロードにマウントできます。
spec: template: spec: - containers: ... resources: limits: nvidia.com/gpu: "1"
一部の GPU ハードウェアは複数のワークロード間で共有できるため、1 つの GPU をプロビジョニングして使用できます。ワークロード GPU 共有を設定する方法については、仮想 GPU デバイスプラグイン
