KEDA Helmチャート：インストールから運用まで

KEDA Helmチャートは、Kubernetesのイベント駆動オートスケーラーであるKEDAをクラスターにインストールする公式の方法です。helm install を一度実行するだけで、イベントに基づいてワークロードをスケールするためにKEDAが必要とするすべて——オペレーター、メトリクスサーバー、アドミッションWebhook、スケーリングルールを定義するためのカスタムリソース——がデプロイされます。

本ガイドでは、このチャートを詳しく解説します。デプロイされるコンポーネント、インストールと検証の方法、values.yaml の主要パラメータ、KEDAの高可用性構成、セキュリティ強化と監視、GitOpsでの管理、そして不要なリソースを残さずにアップグレード・アンインストールする方法を学べます。

インストールのセキュリティ強化

本番環境でKEDAのセキュリティを高められる設定が2つあります。シークレットへのアクセス制限と証明書の管理です。順に見ていきましょう。

a. シークレットアクセスの制限：デフォルトでは、KEDAは監視対象のネームスペース全体でシークレットを読み取れます。permissions.operatorの設定を使うと、オペレーターが自身のリリースネームスペース内のシークレットのみ、または特定の名前のシークレットのみを読み取れるように制限できます。これにより、オペレーターが侵害された場合にアクセスされうる範囲を縮小できます。

b. 証明書の管理：KEDAは自己署名証明書を自動生成し、kedaorg-certsという名前のシークレットに保存して、各コンポーネントにマウントします。また、KEDAはこれらの証明書を自動的にローテーションし、必要なKubernetesリソースを更新して信頼される状態を維持します。

c. 組織のポリシーとしてマネージド認証局の証明書が必要な場合は、certificates.certManager.enabled を有効にすると、KEDAの代わりにcert-managerが証明書の発行とローテーションを行います。ほとんどのインストールでは、自動生成された証明書で十分です。

GitOpsによるチャートのデプロイ

Argo CDやFluxでクラスターを管理している場合は、GitOps経由でKEDAチャートをデプロイできます。特に注意して扱うべきなのはCRDです。

KEDAのCRDはサイズが大きく、生成されるアノテーションが大きくなりすぎるため、通常のKubernetes applyが失敗することがあります。これを避けるには、GitOpsツールがCRDをマージではなく置き換えるように設定します。Fluxの場合はHelmReleaseで crds: CreateReplace を設定し、Argo CDの場合はCRDに Replace=true またはserver-side applyを使用して、正しく適用されるようにします。

CRDが正しく設定されていないと、GitOpsで管理するKEDAのインストールが失敗する可能性があります。

レンダリング済みマニフェストの管理を好むワークフローであれば、helm template でチャートを通常のKubernetes YAMLファイルに変換し、それらのファイルをGitにコミットすることもできます。

どの方法を採用する場合でも、GitOpsツールとHelmがリソースの所有権をめぐって衝突しないよう、app.kubernetes.io/managed-by ラベルは一貫させてください。

インストール後に最初のScaledObjectを作成する

KEDAをインストールしたら、ScaledObjectを使ってKEDAが実際にワークロードをスケールできることを検証できます。以下の例ではcronトリガーを使用するため、外部システムは不要です。スケジュールされた時間帯にDeploymentをスケールアップし、スケジュールが終わるとスケールダウンします。

まずスケール対象のDeploymentを作成し、次に ScaledObject を適用します。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: nginx-cron
  namespace: default
spec:
  scaleTargetRef:
    name: nginx
  pollingInterval: 30
  cooldownPeriod: 300
  minReplicaCount: 0
  maxReplicaCount: 5
  triggers:
    - type: cron
      metadata:
        timezone: Asia/Kolkata
        start: 0 9 * * *
        end: 0 17 * * *
        desiredReplicas: "5"

pollingIntervalは、KEDAがトリガーをチェックする間隔を秒単位で指定します。minReplicaCount: 0 はPod数ゼロへのスケールダウンを有効にします。9時〜17時の時間帯以外は、DeploymentをPod数ゼロまでスケールダウンできます。スケジュールされた時間帯には5レプリカまでスケールアップします。

ScaledObject を適用し、KEDAが作成したリソースを確認します。

kubectl get scaledobject
kubectl get hpa

keda-hpa-nginx-cron という名前のHPAが表示されるはずです。KEDAはこのHPAを作成・管理して実際のスケーリングを行います。これにより、KEDAがワークロードに接続され、スケジュールされたスケーリング設定が機能していることを確認できます。

KEDAインストールの監視

KEDAが稼働したら、正常な状態で期待どおりに動作しているかを確認しましょう。
KEDAはオペレーターとメトリクスサーバーの両方についてPrometheusメトリクスを提供します。これらのメトリクスからは、スケーラーのアクティビティ、エラー、KEDAが報告する値を確認できます。

Prometheus Operatorを使用している場合、KEDAチャートはメトリクスサーバー用のServiceMonitorとオペレーター用のPodMonitorを作成できます。values.yamlのprometheus設定で有効化すれば、Prometheusが自動的にメトリクスを収集できます。

特定のScaledObjectが期待どおりに動作しない場合は、オペレーターのログも役立ちます。スケーラーがトリガーをどう読み取っているか、どのようなエラーが発生しているかを確認できます。

オペレーターのログは次のコマンドで表示できます。

kubectl logs -n keda deploy/keda-operator

KEDAがスケールするワークロードのライトサイジング

KEDAは需要に応じてPod数をスケールすることに優れています。しかし、各PodがどれだけのCPUとメモリをリクエストすべきかは判断しません。

レプリカを増やしても、リソースリクエストの誤りは解消されません。各Podが実際の使用量よりはるかに多いCPUやメモリをリクエストしていれば、KEDAはレプリカを追加するたびにその無駄を増幅させてしまいます。逆にリクエストが少なすぎると、トラフィック増加時に新しいレプリカがOOMKilledやCPUスロットリングに見舞われる可能性があります。

ここで役立つのがリソース最適化ツールです。PerfectScaleは、ワークロードが実際にCPUとメモリをどう使用しているかを監視し、自動化されたライトサイジングの推奨を提供します。推奨は手動でも自動でも適用できます。

KEDAと組み合わせることで、オートスケーリングの両面をカバーできます。KEDAが需要に合わせてPod数を調整し、PerfectScaleが各Podに適切な量のCPUとメモリが割り当てられるよう支援します。これにより、ワークロードの信頼性を保ちながら過剰プロビジョニングを防げます。実際に試すことも、技術セッションを予約することもできます。

その他のツールとしては、使用状況に基づいてリソースリクエストを調整できるVertical Pod Autoscaler（VPA）、VPAの推奨事項の可視化を支援するGoldilocks、そしてワークロードを実行するノードの選択と管理に特化したKarpenterがあります。

チャートのアップグレードとアンインストール

KEDAをアップグレードまたはアンインストールする際には、確認すべき重要なポイントがいくつかあります。

KEDAをアップグレードするには、まずHelmリポジトリを更新し、固定したチャートバージョンにアップグレードします。

helm repo update
helm upgrade keda kedacore/keda --namespace keda --version <new-chart-version>

アップグレード時に注意すべきなのはCRDです。チャートがCRDを管理しているため、helm upgrade は他のリソースと一緒にCRDも更新しますが、KEDAのマイナーバージョンではCRDのフィールドやスケーラーの動作が変わることがあります。本番クラスターをアップグレードする前にリリースノートを読み、新しいKEDAバージョンが使用中のKubernetesバージョンをサポートしていることを確認してください。

KEDAのアンインストールにも注意が必要です。削除の際にリソースが残ってしまうことがあるためです。

まず、ScaledObject と ScaledJob リソースを削除します。

kubectl delete scaledobject --all --all-namespaces
kubectl delete scaledjob --all --all-namespaces

次に、Helmリリースをアンインストールします。

helm uninstall keda --namespace keda

ScaledObject と ScaledJob リソースを先に削除することで、KEDAが作成したHPAをKEDA自身がクリーンアップできます。また、ゼロにスケールされていたワークロードが、KEDAが削除される前に通常のレプリカ数に戻る機会も得られます。

ファイナライザーが原因でリソースの削除が進まなくなった場合は、次のコマンドでファイナライザーを削除できます。

kubectl patch scaledobject <name> -p '{"metadata":{"finalizers":null}}' --type=merge

チャートでよくある問題のトラブルシューティング

KEDAが期待どおりにスケールしないときに確認すべき、よくある問題が2つあります。

a. 外部メトリクスAPIが利用不可、またはTLS検証に失敗している：kubectl get apiservice v1beta1.external.metrics.k8s.io でAvailableと表示されない場合、HPAは外部メトリクスを取得できず、それに基づくワークロードのスケールができません。よくある原因としては、メトリクスサーバーの異常、通信をブロックするNetworkPolicy、Kubernetes APIサーバーとメトリクスサーバー間の接続を妨げるプロキシが挙げられます。まずメトリクスサーバーのPodを確認してください。プロキシを使用している場合は、メトリクスサーバーのクラスターIPがAPIサーバーの no_proxy リストに含まれていることを確認してください。

b. ScaledObjectを作成してもレプリカ数が変わらない：まず kubectl describe scaledobject <name> でステータスとイベントを確認します。次にKEDAオペレーターのログを確認します。原因としては、トリガーの設定ミス、イベントソースの認証情報の不足、同じワークロードをすでにターゲットにしている既存のHPAが考えられます。既存のHPAは、KEDAが作成・管理するHPAと競合する可能性があります。

KEDA Helmチャート運用のベストプラクティス

以下のプラクティスは、KEDAのインストールを安定的かつ安全に保つのに役立ちます。

a. チャートのバージョンを固定し、テスト済みのKEDAアプリバージョンに合わせる：最新版をそのままインストール・アップグレードしないでください。チャートのバージョンを固定し、そのKEDAバージョンをテストし、慎重にロールアウトすることで、常に何が動いているかを把握できます。

b. KEDAを専用ネームスペースに置き、専用のリソースクォータを設定する：専用ネームスペースはKEDAを分離し、KEDA専用のResourceQuotaとNetworkPolicyを適用しやすくします。

c. KEDAの3つのコンポーネントすべてに明示的なrequestsとlimitsを設定する：クラスターに負荷がかかったときにKEDA自体がスロットリングやエビクションの対象にならないよう、オペレーター、メトリクスサーバー、Webhookに適切なリソースを設定する必要があります。

d. ScaledObjectに認証情報を直接書かず、TriggerAuthenticationを使う：TriggerAuthenticationまたはClusterTriggerAuthenticationを参照することで、認証情報をScaledObjectマニフェストの外に保てます。これにより、認証情報をバージョン管理から排除でき、再利用も可能になります。

e. 同じワークロードに対してScaledObjectと手動作成のHPAを併用しない：同じワークロードを2つのコントローラーがスケールしようとすると、互いに競合する可能性があります。KEDAがスケールするワークロードのHPAは、KEDAに管理させてください。

f. アップグレードはロールアウト前に非本番クラスターでテストする：KEDAのマイナーバージョンにはCRDの変更が含まれることがあるため、まず安全な環境でアップグレードをテストしてください。これにより、互換性の問題が本番ワークロードに影響する前に検出できます。