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

導入

Kube-downscalerは、Kubernetes内のPodリソースを自動的にスケールダウンする時間をユーザーが定義できるオープンソースツールです。これにより、オフピーク時のリソース使用量を最小限に抑え、インフラストラクチャコストを削減できます。

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

kube-downscalerの機能

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

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

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

Karpenterとkube-downscalerは、Kubernetesクラスター向けの包括的かつ強力なリソース管理ソリューションを提供するために併用できる2つのツールです。Karpenterとkube-downscalerを併用することで、Kubernetesクラスターは水平スケーリングと垂直スケーリングの両方のメリットを享受できます。DownscalerはPodの数を削減し、KarpenterはPodを少数のマシンまたは異なる種類のマシンに統合することでノードの利用率を最適化します。

定義された期間に基づいて、展開されたレプリカを自動的に拡張します。

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 は、次の条件がすべて満たされた場合に、デプロイされたレプリカをスケールダウンします。

現在時刻は「稼働時間」プランにも「停止時間」プランにも含まれません。該当する場合、プランは以下の順序で評価されます。

ダウンスケーラー/ダウンスケール期間またはダウンスケーラー/ダウンタイムのワークロード定義のコメント。
ダウンスケーラー/アップスケール期間またはダウンスケーラー/アップタイムのワークロードを定義するコメント。
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")。

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

デフォルトでは、デプロイメントはレプリカがゼロになるまでスケールダウンされます。これは、デプロイメントまたはその名前空間のアノテーション、またはCLIの`--downtime-replicas`オプションを使用して設定できます。

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

特定の作業負荷

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

注意すべき点

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

現在の時刻が利用できない場合、すぐに月曜～金曜の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にスケールダウンする必要がある場合は、デプロイメントにアノテーションを適用する必要があります。これはHPAではminReplicasを0にできないため、特別なケースです。デプロイメントのレプリカ数を0に設定すると、HPAが実質的に無効になります。この場合、HPAは次のようなイベントを発行します。「メモリ使用率の取得に失敗しました。リソースメモリのメトリクスを取得できません。リソースメトリクスAPIからメトリクスが返されません。どのPodもHPAからメトリクスを取得できません。」
0 より大きい削減が必要な場合は、HPA にアノテーションを適用する必要があります。これにより、ダウンタイム中に外部トラフィックに基づいてポッドを動的にスケーリングし、低いトラフィックが利用できない場合はダウンタイム中に低い minReplicas トラフィックを維持できます。HPA ではなくデプロイメントにアノテーションを適用すると、デプロイメントがスケールダウンされた際に、デプロイメントの minReplicas が高い場合、kube-downscaler HPA が minReplicas をアップグレードするという競合状態が発生します。

`--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'

詳細な設定

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

downscaler は、コマンドライン引数、環境変数、または Kubernetes アノテーションを介して構成できます。

時間定義（DEFAULT_UPTIMEなど）は、カンマ区切りのリストで指定できます。例えば、以下の設定は、すべてのデプロイメントを非稼働時間に絞り込みます。

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

週末と金曜日の午後8時以降のみ割引となります。

 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 mode: 詳細情報を出力する
--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` オプションは、垂直スケーリングのデフォルトの時間範囲を指定します（デフォルト：always）。これは、環境変数 `DEFAULT_UPTIME` または各デプロイメントの `downscaler/uptime` のコメントを通じて設定することもできます。
`--default-downtime` オプションは、スケールダウンするデフォルトのダウンタイム範囲を指定します（デフォルト：なし）。これは、環境変数 `DEFAULT_DOWNTIME` または各デプロイメントのダウンスケーラー/ダウンタイムのコメントで設定することもできます。
`--exclude-namespaces` オプションは、フォールバックから名前空間（正規表現パターンのリスト、デフォルト：kube-system）を除外します。これは環境変数 `EXCLUDE_NAMESPACES` で設定することもできます。`--namespace` と併用した場合、適用は行われません。
`--exclude-deployments` オプションは、特定のデプロイメント／ステートフルセット／cronジョブをフォールバックから除外します（デフォルト：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 のもう一つのユースケースは、ピーク時のサービス停止を防ぐことです。需要が集中する期間にリソースをスケールする計画を定義することで、kube-downscaler はデプロイメントの事前スケールを支援し、HPA レイテンシを回避します。これにより、ピーク時でもアプリケーションの可用性と応答性を維持できます。

サービス中断防止

提案

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

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

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

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

結論は

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

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

DUICUO