Go to Qiita Advent Calendar 2024 Top
LoginSignup
3
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?

ZOZOAdvent Calendar 2024

Day 22
@kimuchi-systemin株式会社ZOZO

【後編】ゼロから学ぶKEDA：導入手順とScaledObjectの設定方法【コスト削減編】

Last updated at Posted at 2024-12-22

はじめに

この記事では、Kubernetesでイベント駆動型スケーリングを実現する KEDA について、基礎から応用（導入）までを解説します。
「KEDAとは何か？」という基本的な疑問に答えるところから始め、KEDAのアーキテクチャやベストプラクティス、さらに実際の導入方法までを 3部構成 で整理し、KEDAの仕組みや運用のポイントを理解できるように構成しています。

【後編】となる本記事では、KEDAの導入手順とScaledObjectの設定方法について解説します。

【前編】ゼロから学ぶKEDA：概要と導入目的
【中編】ゼロから学ぶKEDA：アーキテクチャ・ベストプラクティス解説

対象読者

  • Kubernetesを学習・導入している方
  • KEDAって聞いたことがあるけど、「何をどうスケールしてくれるのかわからない」という方
  • 「KEDAの導入に興味はあるけど、どこから手をつければいいかわからない」と悩んでいる方

KEDAの導入と環境構築

KEDAのインストール

以下のコマンドを実行して、KEDAをKubernetesクラスタにインストールします。

> kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.16.0/keda-2.16.0.yaml

namespace/keda serverside-applied
customresourcedefinition.apiextensions.k8s.io/cloudeventsources.eventing.keda.sh serverside-applied
customresourcedefinition.apiextensions.k8s.io/clustercloudeventsources.eventing.keda.sh serverside-applied
customresourcedefinition.apiextensions.k8s.io/clustertriggerauthentications.keda.sh serverside-applied
customresourcedefinition.apiextensions.k8s.io/scaledjobs.keda.sh serverside-applied
customresourcedefinition.apiextensions.k8s.io/scaledobjects.keda.sh serverside-applied
customresourcedefinition.apiextensions.k8s.io/triggerauthentications.keda.sh serverside-applied
serviceaccount/keda-operator serverside-applied
role.rbac.authorization.k8s.io/keda-operator serverside-applied
clusterrole.rbac.authorization.k8s.io/keda-external-metrics-reader serverside-applied
clusterrole.rbac.authorization.k8s.io/keda-operator serverside-applied
rolebinding.rbac.authorization.k8s.io/keda-operator serverside-applied
rolebinding.rbac.authorization.k8s.io/keda-auth-reader serverside-applied
clusterrolebinding.rbac.authorization.k8s.io/keda-hpa-controller-external-metrics serverside-applied
clusterrolebinding.rbac.authorization.k8s.io/keda-operator serverside-applied
clusterrolebinding.rbac.authorization.k8s.io/keda-system-auth-delegator serverside-applied
service/keda-admission-webhooks serverside-applied
service/keda-metrics-apiserver serverside-applied
service/keda-operator serverside-applied
deployment.apps/keda-admission serverside-applied
deployment.apps/keda-metrics-apiserver serverside-applied
deployment.apps/keda-operator serverside-applied
apiservice.apiregistration.k8s.io/v1beta1.external.metrics.k8s.io serverside-applied
validatingwebhookconfiguration.admissionregistration.k8s.io/keda-admission serverside-applied

このコマンドにより、KEDA名前空間にCRDやリソースが作成されます。
（ref.https://keda.sh/docs/2.16/deploy/#yaml）

ScaledObjectの設定とゼロスケール

KEDAのゼロスケール機能を利用して、特定のスケジュールに基づいてPodのスケールを自動化します。この設定により、指定した時間にPodをスケールダウンしてリソースを節約し、必要なタイミングで自動的にスケールアウトできます。

ScaledObject設定

以下のYAMLを使用してScaledObjectを作成すると、スケジュールに基づいてPodの数を自動で調整できます。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject  # ScaledObjectの名前を指定
  namespace: kimuchi-httpbin  # 対象のNamespaceを指定
spec:
  scaleTargetRef:
    name: httpbin  # スケール対象のDeployment名
  minReplicaCount: 0  # 最小Replica数を0に設定（ゼロスケールを有効化）
  maxReplicaCount: 3  # 最大Replica数を3に設定
  triggers:
    - type: cron
      metadata:
        timezone: Asia/Tokyo  # タイムゾーンを指定
        start: 0 7 * * 1-5  # 平日の午前7時にスケーリングを開始
        end: 0 23 * * 1-5  # 平日の午後23時にスケーリングを終了
        desiredReplicas: "1"  # スケールアウト時のPod数

設定の適用

作成したYAMLファイルを適用するには、以下のコマンドを実行します。
ここでは、cron-scaledobject.yamlという名前のファイルを使用していますが、このファイルには先ほど記載したScaledObjectの設定が含まれています。

> kubectl apply -f cron-scaledobject.yaml

設定後の動作確認

設定が正しく適用されたことを確認するために、以下の手順で状態をチェックします。

1. ScaledObjectの状態を確認

以下のコマンドでScaledObjectの状態を確認します。

# ScaledObject名、ターゲットリソースの種類と名前、最小・最大Pod数、現在の状態などが確認可能
> kubectl get ScaledObject -n kimuchi-httpbin
NAME                SCALETARGETKIND      SCALETARGETNAME   MIN   MAX   READY   ACTIVE   FALLBACK   PAUSED    TRIGGERS   AUTHENTICATIONS   AGE
cron-scaledobject   apps/v1.Deployment   httpbin           0     3     True    False    False      Unknown   cron                         51s

# KEDAによって作成されたHPAが正常に動作しているか確認
> kubectl get hpa -n kimuchi-httpbin                                                                                                                          
NAME                         REFERENCE            TARGETS             MINPODS   MAXPODS   REPLICAS   AGE
keda-hpa-cron-scaledobject   Deployment/httpbin   <unknown>/1 (avg)   1         3         0          63s

# 現在のシステム時間を表示するコマンド
# Cronトリガーの動作タイミングを確認する際に使用
> date                                                                                                                                                     
2024年 11月14日 木曜日 23時10分11秒 JST
 
# Namespace内の稼働中のPodを確認するコマンド
# 時間外のため、Podがスケールダウンして0になっていることを確認
> kubectl get po -n kimuchi-httpbin                                                                                                               
No resources found in kimuchi-httpbin namespace.

現在の時間はスケーリングルールで指定された稼働時間外に該当するため、Podがスケールダウンしており、Namespace内に稼働中のPodは存在しません。スケーリングルールに基づいて、リソースが管理されている状態です。

スケールアウトの開始を確認

スケーリングルールの稼働時間内に、スケールアウトが開始されているか確認します。
以下のコマンドで、ScaledObject、HPA、そしてNamespace内のPodの状態を確認します。

# 現在のシステム時間を確認
> date 
2024年 11月15日 金曜日 7時10分37秒 JST

# ScaledObjectの状態を確認
> kubectl get ScaledObject -n kimuchi-httpbin
NAME                SCALETARGETKIND      SCALETARGETNAME   MIN   MAX   READY   ACTIVE   FALLBACK   PAUSED    TRIGGERS   AUTHENTICATIONS   AGE
cron-scaledobject   apps/v1.Deployment   httpbin           0     3     True    True     False      Unknown   cron                         4m4s

# HPAの状態を確認
> kubectl get hpa -n kimuchi-httpbin 
NAME                         REFERENCE            TARGETS             MINPODS   MAXPODS   REPLICAS   AGE
keda-hpa-cron-scaledobject   Deployment/httpbin   <unknown>/1 (avg)   1         3         0          4m16s

# Namespace内のPodの状態を確認（新しいPodが作成され、稼働中であることを確認）
> kubectl get po -n kimuchi-httpbin
NAME                       READY   STATUS    RESTARTS   AGE
httpbin-7f56dc944b-g8ddb   1/1     Running   0          4m15s

この結果から、スケールアウトが正常に動作していることが確認できます。

CPUトリガーの追加

負荷に応じてPodを自動的にスケーリングするために、CPUトリガーを設定します。

CPUトリガー設定

ScaledObjectに以下の設定を追加します：

triggers:
  - type: cpu
    metricType: Utilization
    metadata:
      value: "50"  # CPU使用率が50%を超えた場合にスケールアップ

この設定により、CPU使用率が50%を超えるとPodが自動的にスケールアップし、負荷に応じた柔軟なスケーリングが可能になります。

最終的なマニフェスト

以下は、CPUトリガーとCronトリガーを組み合わせたScaledObjectの最終マニフェスト例です：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject  # ScaledObjectの名前を指定
  namespace: kimuchi-httpbin  # 対象のNamespaceを指定
spec:
  scaleTargetRef:
    name: httpbin  # スケール対象のDeployment名
  minReplicaCount: 0  # 最小Replica数を0に設定（ゼロスケールを有効化）
  maxReplicaCount: 3  # 最大Replica数を3に設定
  triggers:
    - type: cpu
      metricType: Utilization
      metadata:
        value: "50" # CPU使用率が50%を超えた場合にスケールアップ
    - type: cron
      metadata:
        timezone: Asia/Tokyo  # タイムゾーンを指定
        start: 0 7 * * 1-5  # 平日の午前7時にスケーリングを開始
        end: 0 23 * * 1-5  # 平日の午後23時にスケーリングを終了
        desiredReplicas: "1"  # スケールアウト時のPod数

このマニフェストを適用すると、以下の動作が実現します：

  • 夜間（利用がない時間帯）
    • Podを自動的にゼロスケールし、不要なリソースの消費を抑えます。
  • 日中（利用がある時間帯）
    • 常に1つのPodを稼働させ、CPU使用率が高くなると自動的にPodを増やして負荷に対応します。

これにより、夜間はリソースを節約し、日中は負荷に応じて柔軟にスケールする運用が可能になります。

まとめ

KEDAを活用することで、夜間はPodをゼロスケールしてリソースを節約し、不要なコストを削減できます。
さらに、日中の稼働時には最低限のPodを維持しながら、CPU使用率に応じて自動的にスケールアウトするため、柔軟に負荷に対応できます。

いいね・コメントお待ちしてます！

3
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
Sign upLogin
3
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?