AWS で Kubernetes クラウドのコストを節約

記事の翻訳はコース開始前夜に準備されました 「Kubernetesをベースとしたインフラプラットフォーム」.

Kubernetes を使用するときにクラウドのコストを節約するにはどうすればよいですか? 単一の適切なソリューションはありませんが、この記事では、リソースをより効果的に管理し、クラウド コンピューティングのコストを削減するのに役立ついくつかのツールについて説明します。

この記事は AWS の Kubernetes を念頭に置いて書きましたが、他のクラウド プロバイダーにも (ほぼ) まったく同じように適用できます。 クラスターにはすでに自動スケーリングが構成されていると仮定します (クラスターオートスケーラー）。 リソースを削除してデプロイメントをスケールダウンすると、ワーカー ノード (EC2 インスタンス) のフリートも削減される場合にのみ費用が節約されます。

この記事では、次の内容について説明します。

• 未使用のリソースをクリーンアップする (kube-管理人)
• 勤務時間外のスケーリングを減らす (kube-ダウンスケーラー)
• 水平自動スケーリング (HPA) を使用し、
• 過剰なリソース予約の削減 (kube-リソース-レポート、VPA)
• スポットインスタンスの使用

未使用のリソースのクリーンアップ

ペースの速い環境で働くのは素晴らしいことです。 私たちはテクノロジー組織を望んでいます 加速された。 ソフトウェア配信の高速化は、PR 導入、プレビュー環境、プロトタイプ、分析ソリューションの増加も意味します。 すべてが Kubernetes 上にデプロイされます。 テスト展開を手動でクリーンアップする時間が誰にあるでしょうか? XNUMX 週間前の実験を削除することは忘れられがちです。 クラウドの請求額は、閉じ忘れたものが原因で最終的に上昇することになります。

(ヘニング・ジェイコブス:
ジザ:
(引用) コーリー・クイン:
誤解: AWS アカウントは、所有するユーザーの数によって決まります。
事実: AWS スコアは、抱えているエンジニアの数の関数です。

イワン・クルノソフ（返答）：
実際: AWS スコアは、無効化/削除し忘れたものの数の関数です。)

Kubernetes 管理人 (kube-janitor) はクラスターのクリーンアップに役立ちます。 管理者の構成は、グローバルとローカルの両方で使用できるように柔軟です。

• クラスター全体のルールにより、PR/テスト展開の最大存続時間 (TTL) を定義できます。
• 個々のリソースに janitor/ttl の注釈を付けることができます。たとえば、7 日後にスパイク/プロトタイプを自動的に削除します。

一般的なルールは YAML ファイルで定義されます。 そのパスはパラメータを通じて渡されます --rules-file kube-管理人で。 すべての名前空間を削除するルールの例を次に示します。 -pr- XNUMX日後の名前で:

- id: cleanup-resources-from-pull-requests
  resources:
    - namespaces
  jmespath: "contains(metadata.name, '-pr-')"
  ttl: 2d

次の例では、2020 年のすべての新しい Deployment/StatefulSet の Deployment ポッドおよび StatefulSet ポッドでのアプリケーション ラベルの使用を規制しますが、同時にこのラベルを使用しないテストの実行を XNUMX 週間許可します。

- id: require-application-label
  # удалить deployments и statefulsets без метки "application"
  resources:
    - deployments
    - statefulsets
  # см. http://jmespath.org/specification.html
  jmespath: "!(spec.template.metadata.labels.application) && metadata.creationTimestamp > '2020-01-01'"
  ttl: 7d

kube-janitor を実行しているクラスターで時間制限付きのデモを 30 分間実行します。

kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30m

コスト増加のもう XNUMX つの原因は、永続ボリューム (AWS EBS) です。 Kubernetes StatefulSet を削除しても、その永続ボリューム (PVC - Persistent VolumeClaim) は削除されません。 未使用の EBS ボリュームにより、月あたり数百ドルのコストが簡単に発生する可能性があります。 Kubernetes Janitor には、未使用の PVC をクリーンアップする機能があります。 たとえば、このルールは、モジュールによってマウントされておらず、StatefulSet または CronJob によって参照されていないすべての PVC を削除します。

# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
  resources:
  - persistentvolumeclaims
  jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
  ttl: 24h

Kubernetes Janitor は、クラスターをクリーンな状態に保ち、クラウド コンピューティングのコストが徐々に増大するのを防ぐのに役立ちます。 導入と構成の手順については、次のとおりです。 README kube-管理人.

勤務時間外のスケーリングを削減する

テストおよびステージング システムは、通常、営業時間内にのみ動作する必要があります。 バックオフィス/管理ツールなどの一部の実稼働アプリケーションも、限られた可用性しか必要とせず、一晩で無効になる可能性があります。

Kubernetes ダウンスケーラー (kube-downscaler) を使用すると、ユーザーとオペレーターは勤務時間外にシステムをスケールダウンできます。 デプロイメントと StatefulSet はレプリカをゼロにスケールできます。 CronJob が一時停止される可能性があります。 Kubernetes Downscaler は、クラスター全体、XNUMX つ以上の名前空間、または個々のリソースに対して構成されます。 「アイドル時間」を設定することも、逆に「作業時間」を設定することもできます。 たとえば、夜間や週末のスケーリングをできるだけ減らすには、次のようにします。

image: hjacobs/kube-downscaler:20.4.3
args:
  - --interval=30
  # не отключать компоненты инфраструктуры
  - --exclude-namespaces=kube-system,infra
  # не отключать kube-downscaler, а также оставить Postgres Operator, чтобы исключенными БД можно было управлять
  - --exclude-deployments=kube-downscaler,postgres-operator
  - --default-uptime=Mon-Fri 08:00-20:00 Europe/Berlin
  - --include-resources=deployments,statefulsets,stacks,cronjobs
  - --deployment-time-annotation=deployment-time

以下は、週末のクラスター ワーカー ノードのスケーリングのグラフです。

ワーカーノードを約 13 から 4 にスケールダウンすると、AWS の請求額に顕著な違いが生じます。

しかし、クラスターの「ダウンタイム」中に作業する必要がある場合はどうすればよいでしょうか? downscaler/exclude: true アノテーションを追加することで、特定のデプロイメントをスケーリングから永久に除外できます。 YYYY-MM-DD HH:MM (UTC) 形式の絶対タイムスタンプを持つダウンスケーラー/除外までの注釈を使用して、デプロイメントを一時的に除外できます。 必要に応じて、アノテーションを含むポッドをデプロイすることでクラスター全体をスケールバックできます。 downscaler/force-uptimeたとえば、nginx を空の状態で起動します。

kubectl run scale-up --image=nginx
kubectl annotate deploy scale-up janitor/ttl=1h # удалить развертывание через час
kubectl annotate pod $(kubectl get pod -l run=scale-up -o jsonpath="{.items[0].metadata.name}") downscaler/force-uptime=true

見ます README kube-downscaler導入手順と追加オプションに興味がある場合は、

水平方向の自動スケーリングを使用する

多くのアプリケーション/サービスは動的な読み込みパターンに対応しており、モジュールがアイドル状態の場合もあれば、フル稼働で動作する場合もあります。 最大ピーク負荷に対処するためにポッドの永続的なフリートを運用することは経済的ではありません。 Kubernetes はリソース全体にわたる水平自動スケーリングをサポートします 水平ポッドオートスケーラー (HPA)。 CPU 使用率は、多くの場合、スケーリングの良い指標となります。

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        averageUtilization: 100
        type: Utilization

Zalando は、スケーリングのためにカスタム メトリクスを簡単に接続するためのコンポーネントを作成しました。 Kube メトリクス アダプター (kube-metrics-adapter) は、ポッドの水平自動スケーリング用のカスタム メトリクスと外部メトリクスを収集して提供できる、Kubernetes の汎用メトリクス アダプタです。 Prometheus メトリクス、SQS キュー、その他の設定に基づいたスケーリングをサポートします。 たとえば、アプリケーション自体によって /metrics 内の JSON として表されるカスタム メトリックにデプロイメントを拡張するには、次を使用します。

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
  annotations:
    # metric-config.<metricType>.<metricName>.<collectorName>/<configKey>
    metric-config.pods.requests-per-second.json-path/json-key: "$.http_server.rps"
    metric-config.pods.requests-per-second.json-path/path: /metrics
    metric-config.pods.requests-per-second.json-path/port: "9090"
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: requests-per-second
      target:
        averageValue: 1k
        type: AverageValue

HPA を使用した水平自動スケーリングの構成は、ステートレス サービスの効率を向上させるためのデフォルト アクションの XNUMX つである必要があります。 Spotify は、HPA に関する経験と推奨事項を紹介するプレゼンテーションを行っています。 ウォレットではなくデプロイメントを拡張する.

リソースのオーバーブッキングを削減する

Kubernetes ワークロードは、「リソース リクエスト」を通じて CPU/メモリのニーズを決定します。 CPU リソースは仮想コア、またはより一般的には「ミリコア」で測定されます。たとえば、500m は 50% の vCPU を意味します。 メモリ リソースはバイト単位で測定され、500 メガバイトを意味する 500Mi などの一般的なサフィックスを使用できます。 リソース リクエストはワーカー ノードの容量を「ロック」します。つまり、1000 つの vCPU を備えたノード上で 4m CPU リクエストを持つポッドは、他のポッドが使用できる vCPU を 3 つだけ残します。 【1]

スラック（超過予備） 要求されたリソースと実際の使用量の差です。 たとえば、2 GiB のメモリを要求しながら 200 MiB しか使用しないポッドには、約 1,8 GiB の「過剰」メモリがあります。 過剰にはお金がかかります。 1 GiB の冗長メモリには月あたり約 10 ドルの費用がかかると大まかに見積もることができます。 【2]

Kubernetes リソース レポート (kube-resource-report) には超過予約が表示され、節約の可能性を判断するのに役立ちます。

Kubernetes リソース レポート アプリケーションおよびコマンドごとに集計された超過を示します。 これにより、リソースの需要を削減できる場所を見つけることができます。 生成された HTML レポートは、リソース使用量のスナップショットのみを提供します。 適切なリソース要求を判断するには、長期にわたる CPU/メモリ使用量を確認する必要があります。 これは、「典型的な」CPU 負荷の高いサービスの Grafana グラフです。すべてのポッドが使用しているのは、要求された 3 つの CPU コアよりも大幅に少ないです。

CPU リクエストを 3000m から約 400m に削減すると、他のワークロード用のリソースが解放され、クラスターを小さくできます。

「EC2 インスタンスの平均 CPU 使用率は、多くの場合、XNUMX 桁のパーセント範囲で推移しています。」 コーリー・クインは書いている。 EC2の場合 適切なサイズを見積もることは間違った決定である可能性がありますYAML ファイル内の一部の Kubernetes リソース クエリの変更は簡単で、大幅な節約が可能です。

しかし、YAML ファイルの値を変更することを本当に望んでいるでしょうか? いいえ、機械ならもっとうまくできます。 Kubernetes 垂直ポッドオートスケーラー (VPA) はまさにそれを行います。ワークロードに応じてリソースの要求と制約を調整します。 これは、VPA によって時間の経過とともに適応された Prometheus CPU リクエスト (細い青い線) のグラフの例です。

Zalando はすべてのクラスターで VPA を使用しています インフラストラクチャコンポーネント用。 重要でないアプリケーションでも VPA を使用できます。

ゴルディロックス Fairwind のツールは、ネームスペース内の展開ごとに VPA を作成し、ダッシュボードに VPA の推奨事項を表示します。 これは、開発者がアプリケーションに適切な CPU/メモリ リクエストを設定するのに役立ちます。

ちょっとしたことを書きました VPA に関するブログ投稿 2019年、そして最近では CNCF エンド ユーザー コミュニティは VPA の問題について議論しました.

EC2 スポットインスタンスの使用

最後に重要なことですが、スポット インスタンスを Kubernetes ワーカー ノードとして使用することで、AWS EC2 のコストを削減できます。 【3]。 スポット インスタンスは、オンデマンド価格と比較して最大 90% 割引でご利用いただけます。 EC2 スポットで Kubernetes を実行するのは良い組み合わせです。可用性を高めるには、複数の異なるインスタンス タイプを指定する必要があります。つまり、同じ価格またはより低い価格でより大きなノードを入手でき、増加した容量をコンテナ化された Kubernetes ワークロードで使用できます。

EC2 スポットで Kubernetes を実行するにはどうすればよいですか? いくつかのオプションがあります。SpotInst (現在は「Spot」と呼ばれています。理由は聞かないでください) のようなサードパーティ サービスを使用するか、単純に Spot AutoScalingGroup (ASG) をクラスターに追加します。 たとえば、複数のインスタンス タイプを持つ「容量が最適化された」スポット ASG の CloudFormation スニペットは次のとおりです。

MySpotAutoScalingGroup:
 Properties:
   HealthCheckGracePeriod: 300
   HealthCheckType: EC2
   MixedInstancesPolicy:
     InstancesDistribution:
       OnDemandPercentageAboveBaseCapacity: 0
       SpotAllocationStrategy: capacity-optimized
     LaunchTemplate:
       LaunchTemplateSpecification:
         LaunchTemplateId: !Ref LaunchTemplate
         Version: !GetAtt LaunchTemplate.LatestVersionNumber
       Overrides:
         - InstanceType: "m4.2xlarge"
         - InstanceType: "m4.4xlarge"
         - InstanceType: "m5.2xlarge"
         - InstanceType: "m5.4xlarge"
         - InstanceType: "r4.2xlarge"
         - InstanceType: "r4.4xlarge"
   LaunchTemplate:
     LaunchTemplateId: !Ref LaunchTemplate
     Version: !GetAtt LaunchTemplate.LatestVersionNumber
   MinSize: 0
   MaxSize: 100
   Tags:
   - Key: k8s.io/cluster-autoscaler/node-template/label/aws.amazon.com/spot
     PropagateAtLaunch: true
     Value: "true"

Kubernetes で Spot を使用する場合の注意点:

• インスタンスの停止時にノードをマージするなどして、スポット終了を処理する必要がある
• ザランドが使用する フォーク ノードプールの優先順位を使用した公式クラスターの自動スケーリング
• スポットノード 強制できる スポットで実行するワークロードの「登録」を受け入れる

サマリー

ここで紹介したツールのいくつかがクラウド料金の削減に役立つことを願っています。 記事の内容のほとんどは次の場所でも見つけることができます。 DevOps Gathering 2019 での私の講演 (YouTube とスライド).

Kubernetes でクラウド コストを節約するためのベスト プラクティスは何ですか? までお知らせください。 Twitter (@try_excel_).

【1] 実際、予約されたシステム リソースによってノードのスループットが低下するため、使用可能な vCPU は 3 つ未満になります。 Kubernetes は、物理ノードの容量と「プロビジョニングされた」リソースを区別します (ノード割り当て可能).

【2] 計算例: 5 GiB のメモリを備えた 8 つの m84.large インスタンスは、月額 ~1 ドル (eu-central-1、オンデマンド)、つまり8/10 ノードのブロッキングは月額約 $XNUMX です。

【3] リザーブドインスタンス、Savings Plan など、EC2 の請求額を削減する方法は他にもたくさんあります。ここではそれらのトピックについては説明しませんが、ぜひ調べてください。

コースについて詳しくはこちらをご覧ください。

出所： habr.com