Kubernetesにおけるスケール・トゥ・ゼロ：Elastiの深掘り

Elasti は、アイドル時にサービスをゼロにスケールダウンし、オンデマンドでスケールアップできるようにすることで、Kubernetesのリソース使用量を最適化するよう設計された革新的なオープンソースソリューションです。Kubernetesコントローラーとリクエストリゾルバーという2つのコンポーネントアーキテクチャで構築されており、Elastiはコストを最小限に抑えながら、サービスの可用性をシームレスに管理します。この記事では、そのアーキテクチャ、インストール、運用フローについて技術的な解説を行い、Kubernetes環境でElastiを効果的に統合し、拡張できるようになることを目指します。

💡この機能はTruefoundryのオートスケーリングスイートに含まれています。詳細については、 ドキュメント。

ゼロスケールの現状

KubernetesはHPAやKEDAのようなソリューションを通じて堅牢なスケーリング機能を提供していますが、レプリカをゼロにスケールすることは依然として困難です。既存のアプローチは通常、2つのカテゴリに分類されます。

1. ネイティブKEDAスケーリング - KEDAはイベントメトリクスを使用してデプロイメントをゼロにスケールできますが、スケールアップ時のコールドスタート期間中に受信リクエストが失われる可能性があります。
2. フルサービスメッシュ （例：Knative） - 包括的なゼロスケールを提供しますが、大幅なアーキテクチャ変更と高い運用オーバーヘッドを伴います。。
3. HTTPプロキシ （例：KEDA HTTPアドオン） - 永続的なプロキシレイヤーを維持し、サービスがスケールアップした後でもレイテンシーを発生させます。

なぜElastiなのか？

Elastiはこれらの制限に対処するために、3つの主要な設計目標を掲げて作成されました。

1. 軽量な統合 - コード変更なしで既存のデプロイメント/サービスと連携します。
2. プロキシによるオーバーヘッドなし - サービスがスケールアップしたら、リクエストパスから外れる。
3. コスト最適化スケーリング - 常に稼働するコンポーネントを維持することなく、真のゼロスケールを実現。

仕組み

Elastiは、サービスのスケーリングを管理するために連携して動作する2つの主要コンポーネントで構成されています。

コントローラー（オペレーター）：‍

• Kubernetesクラスター内のElastiServiceリソースを監視します。
• リアルタイムのトラフィックメトリクスに基づいて、サービスを0から1の間で動的にスケールします。

リゾルバー：

• サービスがスケールダウンされている場合、受信リクエストを傍受するプロキシとして機能します。
• これらのリクエストをキューに入れ、コントローラーにサービスをスケールアップするよう通知し、リクエストが失われないようにします。

サービスへのリクエストの定常状態フロー

このモードでは、すべてのリクエストはサービスポッドによって直接処理されます。Elastiリゾルバーはリクエストパスに関与しません。Elastiコントローラーは、設定されたクエリでPrometheusをポーリングし続け、その結果を閾値と比較して、サービスをスケールダウンできるかどうかを確認します。

リクエストがない場合の0へのスケールダウン

Prometheusからのクエリが閾値未満の値を返した場合、Elastiはサービスを0にスケールダウンします。0にスケールする前に、リクエストをElastiリゾルバーに転送するようにリダイレクトし、その後、Rollout/Deploymentを0レプリカに修正します。また、Kedaが使用されている場合はKedaを一時停止し、KedaはminReplicasが1に設定されているため、サービスがスケールアップされるのを防ぎます。

最初のリクエストが到着した際の0からのスケールアップ。

サービスが0にスケールダウンされているため、すべてのリクエストはElastiリゾルバーに到達します。最初のリクエストが到着すると、Elastiはサービスを設定されたminTargetReplicasまでスケールアップします。その後、急なリクエストの急増に備えて、Kedaを再開しオートスケーリングを継続します。また、ポッドが起動すると、サービスを実際のサービスポッドを指すように変更します。ElastiResolverに到達したリクエストは6分間リトライされ、クライアントに応答が返されます。ポッドの起動に6分以上かかる場合、リクエストは破棄されます。

はじめに

Elastiでシンプルなアプリケーションをデプロイする

1. ローカルクラスターの作成

minikube start


または

kind create cluster --name elasti-demo

または

‍
Docker Desktopでローカルクラスターを作成する

2. Prometheusのセットアップ

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
 --namespace monitoring \
 --create-namespace \
 --set alertmanager.enabled=false \
 --set grafana.enabled=false \
 --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false

Prometheusを monitoring 名前空間にインストールおよび設定します。

Prometheusはnginx ingressからメトリクスを読み取り、そのメトリクスはElastiによってクエリされ、サービスをゼロにスケールしたり、ゼロからスケールしたりするタイミングの決定に利用されます。

3. nginx ingressのセットアップ

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ingress-nginx ingress-nginx/ingress-nginx \
 --namespace ingress-nginx \
 --set controller.metrics.enabled=true \
 --set controller.metrics.serviceMonitor.enabled=true \
 --create-namespace

nginxコントローラーを ingress-nginx 名前空間にデプロイします。

このコントローラーは、デモのhttpbinサービスへのトラフィックをルーティングするために使用されます。

4. Elastiのセットアップ:

helm repo add elasti https://charts.truefoundry.com/elasti
helm repo update
helm install elasti oci://tfy.jfrog.io/tfy-helm/elasti \
 --namespace elasti --create-namespace


elastiネームスペースにhelmでElastiをインストールする

Elastiがインストールされると、その主要な2つのコンポーネントが稼働しているのが確認できます。

• コントローラー/オペレーター: メトリクスを監視することで、トラフィックの切り替えとスケーリングを管理します。
• リゾルバー: 受信リクエストをインターセプトし、キューに入れ、プロキシします。

より高度な設定については、以下を参照してください。 values.yaml helmのバリューファイルにあるすべての設定オプションを確認してください。

5. デモアプリケーションをデプロイする

kubectl create namespace elasti-demo
kubectl apply -n elasti-demo -f \
https://raw.githubusercontent.com/truefoundry/elasti/refs/heads/main/playground/config/demo-application.yaml

httpbinサービスを elasti-demo ネームスペースにデプロイしています。

このhttpbinサービスは、Elasti経由でトラフィックを処理するサービスの設定方法をデモンストレーションするために使用されます。

6. ElastiServiceリソースの作成:

ElastiService用のYAMLファイルを以下の設定で作成します。

apiVersion: elasti.truefoundry.com/v1alpha1
kind: ElastiService
metadata:
 name: httpbin-elasti
 namespace: elasti-demo
spec:
 minTargetReplicas: 1
 service: httpbin
 cooldownPeriod: 5
 scaleTargetRef:
   apiVersion: apps/v1
   kind: deployments
   name: httpbin
 triggers:
   - type: prometheus
     metadata:
       query: sum(rate(nginx_ingress_controller_nginx_process_requests_total[1m])) or vector(0)
       serverAddress: http://kube-prometheus-stack-prometheus.monitoring.svc.cluster.local:9090
       threshold: "0.5"

demo-elasti-service.yaml

ファイルが作成されたら、ElastiServiceを適用します。

kubectl apply -f https://raw.githubusercontent.com/truefoundry/elasti/refs/heads/main/playground/config/demo-elastiService.yaml

CRDスペックの主なフィールドは次のとおりです。

• minTargetReplicas: 最初のリクエストが到着したときに起動する最小レプリカ数。
• cooldownPeriod: スケールアップ後、スケールダウンを検討するまでに待機する最小時間（秒単位）。
• triggers: スケールダウンのタイミングを決定する条件のリスト（現在はPrometheusメトリクスのみをサポート）。
• scaleTargetRef:  HorizontalPodAutoscalerで使用されるものと同様のスケールターゲットへの参照。

詳細およびご自身のユースケースに合わせたElastiServiceの設定については、このドキュメントを参照してください。

セットアップのテスト

これらの手順により、以下のものが利用可能になりました。

• Ingress nginx がIngressコントローラーとして稼働しています。
• Prometheus がメトリクス（Ingress NGINXからのものを含む）をスクレイピングするように設定されています。
• httpbin Ingressルート経由でデプロイされ、アクセス可能です。

この設定により、実際のルーティングシナリオをテストし、Ingressトラフィックのパフォーマンスとメトリクスを監視できます。

この設定をテストするには、nginxロードバランサーにリクエストを送信し、デモサービスのPodを監視します。

kubectl port-forward svc/nginx-ingress-nginx-controller \
 -n ingress-nginx 8080:80


nginxコントローラーへのポートフォワード

kubectl get pods -n elasti-demo -w


httpbinサービスでウォッチを開始する

これで、リクエストを送信できます http://localhost:8080/httpbin すると、サービスがElastiによって1レプリカにスケールされていることが確認できます。

curl -v http://localhost:8080/httpbin

httpbinサービスにリクエストを送信する

その後、サービスはアクティビティがない場合、 cooldownPeriod 秒間（この場合は5秒）ElastiServiceで指定された時間が経過すると、再度スケールダウンされます。

Elastiのアンインストール

Elastiをアンインストールするには、 まず、インストールされているすべてのElastiServiceを削除する必要があります。 その後、インストールファイルを削除するだけです。

kubectl delete elastiservices --all
helm uninstall elasti -n elasti
kubectl delete namespace elasti

^比較

機能比較表：

Elastiを選ぶべき時

Elastiは、次のような場合に最適な選択肢です。

• 既存のHTTPサービスにスケール・トゥ・ゼロ機能を追加する必要がある場合
• スケーリング操作中にリクエストの損失がゼロであることを確実にしたい場合
• 最小限の設定で軽量なソリューションを好む場合
• 既存のオートスケーラー (HPA/KEDA) との統合が必要な場合

最後に

Elastiは、Kubernetesにおける特定の課題、すなわち、リクエストの整合性を損なうことなく、また過度なオーバーヘッドを課すことなく真のスケール・トゥ・ゼロを実装するという必要性から開発されました。このソリューションは、HPAおよびKEDAによるネイティブなオートスケーリングをサポートしており、既存のサービス設定を変更することなく、効率的なリソース利用を実現します。

このツールをオープンソース化することで、真のスケール・トゥ・ゼロ、リクエスト損失ゼロ、そして最小限の運用負荷を必要とする環境に対し、堅牢なソリューションを提供することを目指しています。

コミュニティからの貢献やフィードバックを歓迎します。詳細については、 開発ドキュメント をご覧ください。