kube-downscaler を使用して Kubernetes クラスターのコストを削減する

導入

Kube-downscaler は、Kubernetes でポッドリソースが自動的にスケールダウンされるタイミングをユーザーが定義できるオープンソースツールです。これにより、オフピーク時のリソース使用量が削減され、インフラストラクチャコストが削減されます。

この記事では、kube-downscaler の機能、インストール、構成、使用例、将来の展望について詳しく説明します。

kube-downscalerの機能

Kube-downscaler は、Kubernetes クラスター内のアプリケーションをアップグレードまたはダウングレードするための強力なスケジュールベースのツールです。このセクションでは、ツールの主な機能のいくつかについて説明します。

Kubernetesの機能やツールとの互換性

Kube-downscaler は Horizontal Pod Autoscaling (HPA) もサポートしており、HPA と組み合わせて使用することで、アプリケーションに必要な数のレプリカが維持されるようにすることができます。これにより、kube-downscaler は Kubernetes でのアプリケーションスケーリングに対してさらなる柔軟性ときめ細かい制御を提供できるようになります。

Karpenter と kube-downscaler は、Kubernetes クラスターに完全かつ強力なリソース管理ソリューションを提供するために一緒に使用できる 2 つのツールです。 Karpenter と kube-downscaler を組み合わせることで、Kubernetes クラスターは水平スケーリングと垂直スケーリングの両方のメリットを享受できます。 Downscaler を使用するとポッドの数を減らすことができ、Karpenter はポッドをより少数のマシンまたは異なるタイプのマシンに統合することでノードの使用率を最適化します。

定義された期間に基づいてデプロイメントレプリカを自動的にスケーリングする

Kube-downscaler は、事前に定義された期間に基づいてデプロイメントレプリカを自動的にスケーリングできます。つまり、日、週、または月の特定の時間にレプリカの数を増減するスケジュールを設定できます。

たとえば、アプリケーションのトラフィックが特定の時間帯に高くなることがわかっている場合は、その時間帯にレプリカを自動的にスケールアップし、トラフィックが減少したときにレプリカをスケールダウンするように kube-downscaler を構成できます。

これにより、ピーク負荷が発生して HPA によって処理されるまで待つのではなく、ピーク負荷を予測してスケーリングできるようになります。これにより、リソースの使用が最適化され、アプリケーションが常に利用可能で応答性があることが保証されます。

しかし、Kube-downscaler は主にレプリカをスケールダウンしてクラスターのコストを最適化するために使用され、スケーリングの管理には通常 HPA が使用されます。

kube-downscalerのインストールと設定

Kubernetes クラスターへの kube-downscaler のインストール手順

GitHub から kube-downscaler リポジトリをクローンします。

 git clone <https://codeberg.org/hjacobs/kube-downscaler.git>

kube-downscaler ディレクトリに入ります:

 cd kube-downscaler

deploy/kube-downscaler.yaml ファイルを編集して、特定のニーズに合わせて構成をカスタマイズします。たとえば、タイムゾーン、スケジュール、スケーリングルールを調整できます。

Kubernetes クラスターに構成を適用します。

 kubectl apply -f deploy/

このコマンドは、kube-downscaler コントローラーをデプロイし、kube-downscaler デプロイメントを作成します。

kube-downscalerデプロイメントのログを確認することで、kube-downscaler コントローラーが実行されていることを確認できます。

 kubectl logs -f deployment/kube-downscaler

インストールが完了したら、いくつかの設定を実行する必要があります。

特定のユーザーのニーズに応じて kube-downscaler を構成する

Kube-downscaler は、Kubernetes デプロイメントオブジェクトの注釈を使用してスケーリングプランをカスタマイズします。

デプロイメントオブジェクトの downTimePeriod アノテーションを使用すると、デプロイメントをスケーリングしないダウンタイム期間を指定できます。

minReplicas アノテーションを使用すると、デプロイメントのレプリカの最小数を設定できます。

これらのフィールドを kube-downscaler アノテーションと組み合わせることで、特定のビジネスニーズとリソース使用パターンに基づいてカスタマイズされたスケーリングプランを作成できます。

これらのフィールドを調整することで、アプリケーションの可用性とコスト効率を最適化する方法でデプロイメントをスケーリングするように kube-downscaler を構成できます。

以下は、kube-downscaler を使用したデプロイメントの簡単な構成です。

 apiVersion: apps/v1 kind: Deployment metadata: name: random-deployment annotations: # Kube-downscaler downscaler/downtimePeriod: "Mon-Fri 00:00-07:00 Europe/Berlin" downscaler/minReplicas: 1 spec: replicas: 2 selector: matchLabels: app: random template: metadata: labels: app: random spec: containers: - name: random-container image: random-image

この構成では、月曜日から金曜日の午前 0 時から午前 7 時まで (ヨーロッパ/ベルリンのタイムライン)、レプリカの数が 1 に削減されます。

kube-downscaler は、定義されたスケジュールに基づいてポッドのスケールダウンを自動的に開始します。

これで、Kubernetes クラスターに kube-downscaler をインストールして実行しました。

アルゴリズム

Kube-downscaler は、次の条件がすべて満たされた場合にデプロイメントのレプリカをスケールダウンします。

現在の時刻は、「アップタイム」スケジュールの一部ではなく、「ダウンタイム」スケジュールの一部でもありません。 true の場合、プランは次の順序で評価されます。

ダウンスケーラー/ダウンスケール期間またはダウンスケーラー/ダウンタイムのワークロード定義の注釈。
ダウンスケーラー/アップスケール期間またはダウンスケーラー/アップタイムのワークロード定義の注釈。
downscaler/downscale-period または downscaler/downtime ワークロード名前空間の注釈。
downscaler/upscale-period または downscaler/uptime ワークロード名前空間の注釈。
--upscale-period または --default-uptime CLI パラメーター。
--downscale-period または --default-downtime CLI パラメーター。
UPSCALE_PERIOD または DEFAULT_UPTIME 環境変数。
DOWNSCALE_PERIOD または DEFAULT_DOWNTIME 環境変数。

ワークロードの名前空間が除外リストに含まれていない:
除外リストが指定されている場合は、デフォルト (kube-system のみを含む) の代わりにそのリストが使用されます。
ワークロードのタグがタグリストと一致しません。
ワークロードの名前は除外リストに含まれていません。
ワークロードは除外対象としてマークされていません (注釈 downscaler/exclude: "true" または downscaler/exclude-until: "2024-04-05")。
アクティブなポッドがない場合は、クラスター全体が強制的に稼働状態になります (downscaler/force-uptime: "true" と注釈を付けます)。

最小レプリカ数レプリカの最小数

デフォルトでは、デプロイメントはコピー 0 個までスケールダウンされます。これは、デプロイメントまたはその名前空間のアノテーション downscaler/downtime-replicas を介して、または --downtime-replicas を使用して CLI を介して構成できます。

例: downscaler/downtime-replicas: "1"。

特定の作業負荷

通常の HorizontalPodAutoscaler の場合、このフィールドをゼロに設定することはできないため、 downscaler/downtime-replicas は少なくとも 1 に設定する必要があります。 CronJobs に関しては、その状態は suspend: true として定義されます。

注記

デフォルトの 15 分の猶予期間は、新しい nginx デプロイメントに適用されることに注意してください。

現在の時刻が月曜〜金曜の 9 時から 17 時 (ブエノスアイレスのタイムゾーン) でない場合は、すぐにズームアウトされず、15 分後にズームアウトされます。ダウンスケーラーは最終的に次のようなログを出力します。

 INFO: Scaling down Deployment default/nginx from 1 to 0 replicas (uptime: Mon-Fri 09:00-17:00 America/Buenos_Aires, downtime: never)

デプロイメントで HorizontalPodAutoscaler (HPA) を使用する場合は、次の点に注意してください。

レプリカを 0 にスケールダウンする必要がある場合は、 Deployment にアノテーションを適用する必要があります。これは、HPA では minReplicas を 0 にできないため、特別なケースです。デプロイメントレプリカを 0 に設定すると、基本的に HPA が無効になります。この場合、HPA は、メモリ使用率の取得に失敗しました: リソースメモリのメトリックを取得できません: メトリックを取得する Pod がないため、リソースメトリック API からメトリックが返されません、などのイベントを発行します。
0 より大きい縮小が必要な場合は、HPA に注釈を適用する必要があります。これにより、停止中に外部トラフィックに基づいてポッドを動的にスケーリングし、トラフィックが少ない場合は停止中に minReplicas を低く保つことができます。 HPA ではなくデプロイメントにアノテーションを付けると、デプロイメントの minReplicas が高い場合に、デプロイメントがスケールダウンされ、kube-downscaler HPA がそれをスケールアップするという競合状態が発生します。

--downtime-replicas=1 を使用して HPA でダウンスケーラーを有効にするには、デプロイメントと HPA に次のアノテーションを追加してください。

 $ kubectl annotate deploy nginx 'downscaler/exclude=true' $ kubectl annotate hpa nginx 'downscaler/downtime-replicas=1' $ kubectl annotate hpa nginx 'downscaler/uptime=Mon-Fri 09:00-17:00 America/Buenos_Aires'

詳細設定

稼働時間/停止時間の仕様

ダウンスケーラーは、コマンドライン引数、環境変数、または Kubernetes アノテーションを介して構成されます。

時間定義 ( DEFAULT_UPTIME など) は、コンマ区切りの仕様リストを受け入れます。たとえば、次の構成では、営業時間外にすべてのデプロイメントがスケールダウンされます。

 DEFAULT_UPTIME="Mon-Fri 07:30-20:30 Europe/Berlin"

週末と金曜日の20:00以降のみズームアウトします。

 DEFAULT_DOWNTIME="Sat-Sun 00:00-24:00 CET,Fri-Fri 20:00-24:00 CET'

各時間の指定は、次の 2 つの形式のいずれかになります。

指定形式 <WEEKDAY-FROM>-<WEEKDAY-TO-INCLUSIVE> <HH>:<MM>-<HH>:<MM> <TIMEZONE> を繰り返します。タイムゾーンの値には、「US/Eastern」、「PST」、「UTC」などの任意のタイムゾーンを指定できます。
絶対正規形式、<TIME_FROM>-<TIME_TO>。各 <TIME> は ISO 8601 の日付と時刻の形式 <YYYY>-<MM>-<DD>T<HH>:<MM>:<SS>[+-]<TZHH>:<TZMM> です。

期間に基づく代替ロジック

厳密な稼働時間や停止時間の代わりに、アップグレードまたはスケールダウンの期間を選択できます。時間の定義は同じです。この場合、ズームインまたはズームアウトは指定された期間のみ実行され、残りの時間は無視されます。

スケールアップまたはスケールダウンサイクルが構成されている場合、稼働時間と停止時間は無視されます。つまり、一部のオプションは相互に排他的です。たとえば、 --default-downtime または --downscale-period のいずれかを使用できますが、両方は使用できません。

この定義により、19:00 から 20:00 の間にクラスターがスケールダウンされます。クラスターを手動でアップグレードすると、翌日の 19:00 ～ 20:00 まではクラスターはスケールダウンされません。

 DOWNSCALE_PERIOD="Mon-Sun 19:00-20:00 Europe/Berlin"

コマンドラインオプション

使用可能なコマンドラインオプション:

--dry-run 実行のみモード: 何も変更せず、実行される内容のみを出力します
--debug モード: 詳細情報を出力します
--once はループを1回だけ実行して終了します
--interval ループ間隔 (デフォルト: 30 秒)
--namespace は、ダウンスケーラーが単一の名前空間でのみ動作するように制限します (デフォルト: すべての名前空間)。これは主に、kube-downscaler のデプロイヤーが特定の名前空間にのみアクセスできる (クラスターアクセスではない) デプロイシナリオに適用されます。 --exclude-namespaces と一緒に使用した場合、何も適用されません。
--include-resources は、そのようなリソースをコンマ区切りのリストに絞り込みます。
--grace-period デプロイメントをスケールダウンする前の新しいデプロイメントの猶予期間（秒単位）（デフォルト: 15 分）。猶予期間はデプロイメントの作成時に開始されます。つまり、猶予期間に関係なく、更新されたデプロイメントは直ちにスケールダウンされます。
--upscale-period 指定された期間のみスケールアップする代替ロジック（デフォルト: なし）。環境変数 UPSCALE_PERIOD または各デプロイメントのアノテーションを介して構成することもできます。downscaler/upscale-period
--downscale-period 指定された期間のみダウンスケールする代替ロジック（デフォルト：なし）。環境変数 DOWNSCALE_PERIOD または各デプロイメントのアノテーション downscaler/downscale-period 経由でも構成可能
--default-uptime スケールアップするデフォルトの時間枠（デフォルト：常に）。環境変数 DEFAULT_UPTIME または各デプロイメントのダウンスケーラー/アップタイムのアノテーションを介しても構成可能です。
--default-downtime ダウンスケールするデフォルトの時間枠（デフォルト: なし）。環境変数 DEFAULT_DOWNTIME または各デプロイメントのダウンスケーラー/ダウンタイムのアノテーションを介しても設定可能
--exclude-namespaces ダウングレードから名前空間を除外します (正規表現パターンのリスト、デフォルト: kube-system)。環境変数 EXCLUDE_NAMESPACES 経由でも構成可能です。 --namespace と共に使用した場合、何も適用されません。
--exclude-deployments 特定のデプロイメント/ステートフルセット/cronjobs をダウングレードから除外します (デフォルト: kube-downscaler、downscaler)。環境変数 EXCLUDE_DEPLOYMENTS 経由でも構成可能です。名前にかかわらず、このオプションは、含まれるリソースタイプ (Deployment、StatefulSet、CronJob など) の名前と一致します。
--downtime-replicas スケールダウンするレプリカのデフォルト値。downscaler/downtime-replicas がこの値よりも優先されることに注意してください。
--deployment-time-annotation オプション: リソースの作成タイムスタンプの代わりに使用される注釈の名前。このオプションは、デプロイ後の猶予期間 ( --grace-period ) 中にリソースをスケールアップし続ける場合に使用する必要があります。アノテーションのタイムスタンプ値の形式は、Kubernetes 形式とまったく同じである必要があります: creationTimestamp %Y-%m-%dT%H:%M:%SZ 。推奨事項: この注釈は、デプロイメントツールによって自動的に設定されます。
--matching-labels オプション: kube-downscaler スコープでカバーされるワークロードラベルのリスト。リスト内のどのワークロードとも一致しないタグを持つワークロードは無視されます。下位互換性のため、このパラメータが指定されていない場合は、kube-downscaler がすべてのリソースに適用されます。

名前空間のデフォルト

DEFAULT_UPTIME 、 DEFAULT_DOWNTIME 、および FORCE_UPTIME の除外も、名前空間アノテーションを使用して構成できます。設定されている場合、これらの値は他のグローバルデフォルトよりも優先されます。

 apiVersion: v1 kind: Namespace metadata: name: foo labels: name: foo annotations: downscaler/uptime: Mon-Sun 07:30-18:00 CET

名前空間レベルでは、次の注釈がサポートされています。

ダウンスケーラー/アップスケール期間。
ダウンスケーラー/ダウンスケール期間。
downscaler/uptime : この名前空間内のすべてのリソースの「稼働時間」を設定します。
downscaler/downtime : この名前空間内のすべてのリソースの「ダウンタイム」を設定します。
downscaler/force-downtime : この名前空間内のすべてのリソースのダウンタイムを強制します。true / false を指定できます。
downscaler/force-uptime : この名前空間内のすべてのリソースのスケールアップを強制します。true / false を指定できます。
downscaler/exclude : 名前空間内のすべてのリソースを除外するには true に設定します。
downscaler/exclude-until : 指定されたタイムスタンプまで、名前空間内のすべてのリソースを一時的に除外します。
downscaler/downtime-replicas : スケールダウンするデフォルトのターゲットレプリカを上書きします (デフォルト: ゼロ)。

ユースケース

このツールの主な使用例は、Kubernetes クラスターリソースの使用率を最適化することでコストを削減することです。ただし、クラスターを事前にウォームアップし、HPA への過度の依存を回避するためにも使用できます。

これは主な目的ではありませんが、この組み合わせにより、インフラストラクチャコストを最小限に抑えながらアプリケーションの高可用性を確保するための代替ソリューションが提供されます。

コストを削減

kube-downscaler のもう 1 つの使用例は、ピーク使用時のサービス停止を防ぐことです。需要が高い期間にリソースを拡張する計画を定義することにより、kube-downscaler は事前にデプロイメントを拡張し、HPA レイテンシを回避して、ピーク使用時でもアプリケーションの可用性と応答性を維持できるようにします。

サービス中断防止

提案

事前定義されたスケジュールに基づいてスケーリングしますが、すべてのユースケースに適しているとは限りません。さらに、自動スケーリングはサポートされていないため、ユーザーは変化する需要に合わせてスケーリングプランを手動で調整する必要があります。

検討すべきもう一つの解決策は Keda です。 Keda は、Kubernetes アプリケーションに動的な自動スケーリング機能を提供するオープンソースプロジェクトです。 Keda を使用すると、ユーザーはキューの長さ、CPU 使用率、カスタムメトリックなどのさまざまなメトリックに基づいてカスタムスケーリングルールを設定できます。

これにより、リソースの使用をより細かく制御できるようになり、アプリケーションが常に需要に応じて適切に拡張されることが保証されます。

さらに、Keda は、ステートフルアプリケーションやステートレスアプリケーションを含む幅広い Kubernetes アプリケーションと互換性があり、Azure Event Hubs、Kafka、RabbitMQ などの複数のイベントソースをサポートしています。

結論は

Kube-downscaler は、Kubernetes クラスター内のリソース使用量を管理するための強力なツールです。スケーリングプランを定義することで、ユーザーはクラスター内のリソース使用を最適化し、コストを削減しながら、ピーク使用時でもアプリケーションの可用性と応答性を維持できます。

kube-downscaler は Kubernetes クラスターのリソース使用量を管理するための貴重なツールですが、いくつかの制限があります。リソースのスケーリングをより細かく制御する必要がある場合、または自動スケーリング機能が必要な場合は、Keda などの代替ソリューションを検討する価値があるかもしれません。

<<: k3sup を使って 1 分で K3s クラスターを素早く構築する

>>: K8s コンポーネントの完全な分析: 知っておくべきすべての秘密