4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Pod Topology Spread Constraints と Spot VM で可用性を担保しつつ、インフラコストの削減をする

Last updated at Posted at 2023-12-12

この記事は、CyberAgent Group SRE Advent Calendar 2023の13日目の記事です。

はじめに

株式会社CAM の SRE team に所属している岡です。

弊社は、エンターテインメント事業に注力しており、それらサービスのインフラストラクチャの運用・保守を SRE team が担当しています。

本記事では、GKE 環境において Pod Topology Spread Constraints と Spot VM を使用することで、可用性を担保しつつ、コスト削減を行なった方法をご紹介します。

Spot VM の課題

Spot VM とは Regular VM(標準的な Compute Engine VM)と比べ、可用性が保証されない代わりに、料金がとても低い VM です(参照)。
割引率はインスタンスタイプや時期にもよりますが 90% 以上の割引率が適用されたりもします。

本番環境に導入することができれば大きな額のコスト削減が見込めるためとても魅力的なサービスです。
しかし、本番環境に導入するには以下のような課題がありました。

  • 在庫不足などにより Spot VM が 1 台も起動できない状況を考慮する必要がある
  • 複数台の Spot VM が同時に停止される可能性を考慮する必要がある

Pod Topology Spread Constraints が解決する課題

先ほど上げた課題は 「サービスを構成する全Podの内 50% は Regular VMにスケジュールする」 といったようなことが実現できれば、Spot VM が全て停止されてしまった場合でも、半数の Pod は稼働していることが保証できるため解決できます。

Pod Topology Spread Constraints とはユーザーが定義したドメインに基づいて Pod を分散配置してくれる機能です(参照)。

この機能を使用することで、最低限の可用性を担保しつつ、Spot VM を使用しコスト削減をすることが可能になります。

実装

ここからはコード交えつつ、実装方法の紹介をしていきます。

Taint/Toleration の定義

なんでもかんでも Spot VM にスケジュールしたくないので、Taint を Node に付与し、Spot VM にスケジュールしたい Pod 側で Toleration を定義します。

Taint

key    = "allow-schedule-to-spot-vm"
value  = true
effect = "NO_EXECUTE"

Toleration

tolerations:
  - key: "allow-schedule-to-spot-vm"
    operator: "Equal"
    value: "true"
    effect: "NoExecute"

Pod Topology Spread Constraints の定義

Spot VM にスケジュールしたい Pod に Pod Topology Spread Constraints を定義します。
この際、Regular VM と Spot VM を判別するための Labele を Node に付与しておく必要があります
今回の例では Regular VM に spot-vm: false、Spot VM に spot-vm: true という Label が付与されている程でコードの例を出します。

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: spot-vm
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: example-app
        release: example-app

以上で実装は終了です。
特に難しい設定もなく簡単に実装できると思います。

注意事項

Pod Topology Spread Constraints を導入するにあたって、Pod のスケールイン時や、ローリングアップデート時に定義した戦略通りのスケジューリングにならない可能性があることを考慮する必要があります。
Descheduler というソフトウェアを使用することで、戦略に従っていない Pod を Evict し再スケジュールすることが可能なためインストールすることを推奨します。

おわりに

Pod Topology Spread Constraints を利用することで最低限の可用性を保ちつつ、Spot VM を利用することができ、コスト削減を実施することができました。
Spot VM 使いたいけど、可用性の問題で使えてないよといった方の参考になると幸いです。
明日は @kznrluk さんの「SRE入門のための自宅K8sクラスタ」です。

4
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?