نسخه آنلاین در حال بارگذاری زمان... تهران: ۲۶°C
۲۸ کاربر آنلاین

PNo.30Light

نشریه تخصصی هوش مصنوعی، سیستم‌های سرور و مهندسی داده

تازه ترین‌ها
زیرساخت و سرور
زمان مطالعه: ۲۶ دقیقه ۰ بازدید

KEDA: Event-driven Autoscaling برای Kubernetes — از Scale-to-Zero تا ۷۰+ Scaler

نویسنده: تحریریه فنی P30Light
KEDA: Event-driven Autoscaling برای Kubernetes — از Scale-to-Zero تا ۷۰+ Scaler
✦ خلاصه نکات کلیدی مقاله
  • KEDA = Kubernetes Event-driven Autoscaler — کنار HPA کار می‌کند؛ از صفر تا N بر اساس رویداد واقعی.
  • معماری: operator (0↔1) + metrics-apiserver (1↔N via HPA) + admission webhooks؛ CRDهای ScaledObject / ScaledJob / TriggerAuthentication.
  • CNCF Graduated؛ ۷۰+ scaler داخلی (Kafka، RabbitMQ، Prometheus، SQS، …) + HTTP Add-on و External scaler.

HPA استاندارد Kubernetes عمدتاً روی CPU و Memory فکر می‌کند. اما بسیاری از workloadها با صف پیام، عمق Kafka، نرخ HTTP، یا query دیتابیس زنده می‌مانند — نه با درصد CPU.

KEDA برای همین ساخته شد:

Kubernetes Event-driven Autoscaling — Application autoscaling made simple.

یعنی اسکیل هر کانتینر در Kubernetes بر اساس تعداد رویدادهایی که باید پردازش شوند — سبک، تک‌منظوره، و کنار HPA بدون بازنویسی یا تداخل با بقیهٔ اپ‌ها.

CNCF Graduated. خاستگاه: Microsoft و Red Hat. سایت: keda.sh · Docs: docs · Repo: github.com/kedacore/keda · نیازمندی: Kubernetes ≥ 1.30


مشکل: اسکیل بدون سیگنال رویداد

بدون KEDA:
  صف ۱۰۰٬۰۰۰ پیام → ۳ pod ثابت → backlog
  شب صف خالی → ۳ pod بیکار → هزینه
  HPA فقط روی CPU → صف پر ولی CPU پایین → اسکیل نمی‌شود

با KEDA:
  queue depth / lag / cron / Prometheus ──► ScaledObject

        ├─ 0 → 1   (operator)
        └─ 1 → N   (HPA + external metrics)
معیارHPA (CPU/Mem)CronJob ثابتVendor APM scalerKEDA
سیگنال رویدادضعیفزمانوابسته۷۰+ منبع
Scale-to-zeroنه (معمولاً)نهوابستهبله (با trigger مناسب)
کنار HPAخودش استگاهی جایگزینمکمل / مدیر HPA
Deployment + JobDeploymentJob زمان‌بندیوابستهScaledObject + ScaledJob
Vendor lock-inکمکمبالاآگنوستیک
CNCF✅ Graduated

KEDA جایگزین HPA نیست — آن را با متریک خارجی تغذیه می‌کند و مسیر ۰↔۱ را خودش مدیریت می‌کند. برای معماری رویداد ببینید: CloudEvents. برای runtime اپ: Dapr.


KEDA چیست؟

طبق keda.sh و Concepts:

  • autoscaler مبتنی بر Kubernetes برای اسکیل بر اساس رویداد واقعی
  • سبک؛ قابل افزودن به هر کلاستر بدون overwrite اجزای استاندارد
  • صریحاً مشخص می‌کنید کدام اپ با KEDA اسکیل شود؛ بقیه دست‌نخورده می‌مانند
  • پشتیبانی از Deployment، StatefulSet، Job و CRهایی که /scale دارند (مثل Argo Rollouts)
  • کاتالوگ ۷۰+ scaler برای cloud، messaging، DB، telemetry، CI/CD و …
  • هدف پایداری: بهینه‌سازی scheduling و scale-to-zero برای کاهش مصرف منابع

قابلیت‌های برجسته (از سایت)

ویژگیمعنی
Autoscaling Made Simpleاسکیل غنی برای هر workload
Event-drivenواکنش به backlog واقعی، نه فقط infra
Built-in Scalers۷۰+ scaler آماده
Multiple Workload TypesDeployment / Job / CR با scale subresource
Reduce environmental impactکمتر منابع بیکار
ExtensibleExternal / community scalers
Vendor-AgnosticAWS، Azure، GCP، on-prem، …
Azure Functions on K8sاجرای و اسکیل Functions روی Kubernetes

معماری: سه جزء، دو مسیر اسکیل

 Event sources (Kafka, SQS, RabbitMQ, Prometheus, …)
              │ poll / push

┌─────────────────────────────────────────────┐
│  keda-operator                              │
│   • watch ScaledObject / ScaledJob          │
│   • create/manage HPA                       │
│   • scale 0 ↔ 1 مستقیم                      │
├─────────────────────────────────────────────┤
│  keda-metrics-apiserver                     │
│   • external metrics → Kubernetes API       │
│   • HPA از اینجا برای 1 ↔ N می‌پرسد         │
├─────────────────────────────────────────────┤
│  keda-admission-webhooks                    │
│   • اعتبارسنجی ScaledObject هنگام apply     │
│   • مثلاً دو ScaledObject روی یک target     │
└─────────────────────────────────────────────┘


         HPA + ReplicaSet → Pods
مسیرمسئولبازه
Activationkeda-operator۰ → ۱ و ۱ → ۰
ScalingHPA + metrics-apiserver۱ → N و N → ۱

نتیجه: وقتی صف خالی است می‌توانید واقعاً به صفر برسید؛ با اولین رویداد، operator اپ را بیدار می‌کند؛ بعد HPA بر اساس متریک خارجی تعداد را بالا می‌برد.

محدودیت مهم CPU/Memory: با triggerهای CPU یا Memory، HPA متریک را از metrics-server می‌گیرد نه از KEDA metrics API. بدون pod در حال اجرا متریکی نیست → scale-to-zero با CPU/Memory پشتیبانی نمی‌شود.

جزئیات: KEDA Concepts.


CRDهای اصلی

CRDکاربرد
ScaledObjectاسکیل Deployment / StatefulSet / CR دارای /scale
ScaledJobساخت Jobهای Kubernetes بر اساس رویداد (batch)
TriggerAuthentication / ClusterTriggerAuthenticationاحراز هویت امن به منبع رویداد (Secret، IAM، AAD، …)

از KEDA 2.0 به بعد Job از Deployment جدا شد (ScaledJob) و API group به keda.sh منتقل شد.


ScaledObject — اسکیل سرویس‌های طولانی‌عمر

نمونهٔ مفهومی با RabbitMQ:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: rabbitmq-consumer
  namespace: default
spec:
  scaleTargetRef:
    name: consumer-deploy          # Deployment / StatefulSet / ...
  pollingInterval: 30              # ثانیه — فاصلهٔ poll متریک
  cooldownPeriod: 300              # بعد از idle، قبل از scale-to-zero
  minReplicaCount: 0               # scale-to-zero
  maxReplicaCount: 50
  triggers:
    - type: rabbitmq
      metadata:
        protocol: amqp
        queueName: orders
        mode: QueueLength
        value: "5"                 # هدف: ~5 پیام per pod
      authenticationRef:
        name: rabbitmq-trigger-auth

فیلدهای کلیدی:

فیلدمعنی
scaleTargetRefهدف اسکیل
minReplicaCount / maxReplicaCountکف و سقف
pollingIntervalتناوب خواندن متریک
cooldownPeriodتأخیر قبل از رفتن به صفر
triggers[]یک یا چند منبع؛ ترکیب چند trigger مجاز است
fallbackرفتار هنگام خطای scaler (در نسخه‌های جدید)

ScaledObject با Prometheus

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: http-app-scaledobject
spec:
  scaleTargetRef:
    name: http-app
  minReplicaCount: 1
  maxReplicaCount: 10
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-server.default.svc:9090
        threshold: "5"
        query: sum(rate(http_requests_total{app="http-app"}[1m]))

ScaledJob — batch به‌جای replica ثابت

به‌جای بالا بردن Deployment، برای هر backlog، Job می‌سازد (مثلاً یک Job به ازای پیام/دسته):

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: image-processor
spec:
  jobTargetRef:
    template:
      spec:
        containers:
          - name: worker
            image: example/image-processor:1.0
        restartPolicy: Never
  pollingInterval: 30
  maxReplicaCount: 20
  successfulJobsHistoryLimit: 5
  failedJobsHistoryLimit: 5
  triggers:
    - type: aws-sqs-queue
      metadata:
        queueURL: https://sqs.eu-west-1.amazonaws.com/123/images
        queueLength: "1"
      authenticationRef:
        name: aws-trigger-auth

مناسب برای: پردازش تصویر، import، گزارش، کار ناهمگام یک‌بارمصرف. Jobهای تمام‌شده تمیز می‌شوند.


TriggerAuthentication

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: rabbitmq-trigger-auth
  namespace: default
spec:
  secretTargetRef:
    - parameter: host
      name: rabbitmq-secret
      key: host

الگوهای رایج auth:

روشمثال
Kubernetes Secretconnection string، password
Env / pod identityworkload با env از Secret
AWS IAM / IRSA / Pod IdentitySQS، Kinesis بدون کلید ثابت
Azure AD / Workload IdentityService Bus، Event Hubs
GCP Workload IdentityPub/Sub

ClusterTriggerAuthentication همان ایده در سطح کلاستر برای اشتراک بین namespaceها.


کاتالوگ Scalerها (نمای کلی)

بیش از ۷۰ scaler در keda.sh/scalers — گروه‌بندی مفهومی:

دستهنمونه‌ها
Messaging / StreamApache Kafka، RabbitMQ، NATS JetStream، ActiveMQ، Pulsar، IBM MQ، NSQ، Solace، Temporal
Cloud queuesAWS SQS / Kinesis / DynamoDB Streams، Azure Service Bus / Event Hubs / Storage Queue، GCP Pub/Sub / Cloud Tasks
DatastoresPostgreSQL، MySQL، MSSQL، MongoDB، Cassandra، Redis Lists/Streams، Elasticsearch، OpenSearch، etcd
Metrics / ObservabilityPrometheus، Datadog، New Relic، Dynatrace، Graphite، Loki، Splunk، CPU، Memory
Object storageAzure Blob، GCS، OpenStack Swift
CI / runnersAzure Pipelines، GitHub Runner، Forgejo، Selenium Grid
زمان / عمومیCron، Metrics API، Kubernetes Workload / Resource، External، External Push
سایرAzure Functions اکوسیستم، Predictkube (پیش‌بینی)، Elastic Forecast (experimental)

External Scaler

اگر منبع شما در کاتالوگ نیست، scaler سفارشی (gRPC) یا External Push بنویسید. همچنین می‌توان متریک خام scaler را با gRPC (RAW_METRICS_GRPC_PROTOCOL) به سیستم‌های ثالث فرستاد — حالت‌های all / hpa / pollinginterval.


HTTP Add-on و scale-to-zero برای وب

برای ترافیک HTTP خالص، KEDA هسته به‌تنهایی interceptor ندارد. پروژهٔ HTTP Add-on (جدا، اغلب beta) درخواست را از یک interceptor رد می‌کند، متریک صف/همزمانی می‌سازد و با triggerهایی مثل external-push اپ را از صفر بیدار می‌کند.

نکتهتوصیه
محیط staging / dev بی‌کارکاندید خوب برای scale-to-zero HTTP
production پرترافیکinterceptor می‌تواند bottleneck شود — با احتیاط و تست؛ بسیاری هنوز HPA+Prometheus یا minReplicas≥1 نگه می‌دارند
جایگزینمتریک Prometheus/Ingress روی ScaledObject بدون add-on (اغلب بدون صفر واقعی مگر صف/رویداد جدا)

نصب

طبق Deploying KEDA:

Helm (رایج‌ترین)

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --namespace keda --create-namespace
kubectl get pods -n keda

YAML (کنترل کامل)

# با admission webhooks — نسخه را با آخرین release عوض کنید
kubectl apply --server-side -f \
  https://github.com/kedacore/keda/releases/download/v2.20.0/keda-2.20.0.yaml

سایر روش‌ها

روشمناسب
Operator Hub / OLMOpenShift و کلاسترهای OLM
MicroK8slab محلی (helm3 + dns)
CRD جدامدیریت lifecycle CRD خارج از chart

حذف:

helm uninstall keda --namespace keda
# در صورت گیر کردن finalizer:
kubectl patch scaledobject <name> -p '{"metadata":{"finalizers":null}}' --type=merge

مقایسه کوتاه

ابزارتمرکزScale-to-zero رویدادکاتالوگ trigger
HPA aloneCPU/Mem/custom metricsمحدودوابسته به metrics pipeline
VPAاندازهٔ request/limit
Cluster Autoscaler / Karpenterتعداد Node
Knative Servingrequest-driven + zeroقوی برای HTTPمدل سرویس خاص
KEDAevent sources روی workload موجودقوی (صف/متریک)۷۰+

KEDA اغلب کنار Cluster Autoscaler می‌نشیند: اول pod، بعد در صورت نیاز node. با Karmada می‌توان ScaledObject را به چند کلاستر propagate کرد؛ با Helm و Flux نصب و سیاست را GitOps کرد.


عملیات و عیب‌یابی

علامتبررسی
اسکیل نمی‌شودkubectl describe scaledobject؛ وضعیت trigger Active؟
به صفر نمی‌رودminReplicaCount، cooldownPeriod، آیا trigger هنوز «فعال» است؟
از صفر برنمی‌گرددactivation threshold؛ دسترسی auth به صف؛ CPU-only trigger؟
HPA ساخته نشدهwebhook/operator log؛ تداخل دو ScaledObject روی یک target
نوسان (flapping)pollingInterval، threshold، stabilization HPA
خطای authTriggerAuthentication و Secret/IAM role
kubectl get scaledobject,scaledjob,hpa -A
kubectl logs -n keda deploy/keda-operator -f
kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" | head

برای observability مسیر اسکیل و latency اپ: Jaeger و Fluentd.


یکپارچگی با استک P30Light

لایهمقاله
رویدادCloudEvents
App runtimeDapr
GitOps / PackageFlux · Helm
Multi-clusterKarmada
MeshIstio · Linkerd
Tracing / LogsJaeger · Fluentd

الگوی رایج:

Queue / Stream / Cron / Prometheus
        → KEDA (ScaledObject|ScaledJob)
        → HPA + Pods
        → (اختیاری) Cluster Autoscaler / Karpenter

خلاصه

موضوعجمع‌بندی
چیستEvent-driven autoscaler روی Kubernetes
وضعیتCNCF Graduated؛ Microsoft + Red Hat
رابطه با HPAمکمل؛ KEDA HPA را می‌سازد و متریک خارجی می‌دهد
۰↔۱ / ۱↔Noperator / HPA
CRDScaledObject، ScaledJob، TriggerAuthentication
اکوسیستم۷۰+ scaler + External + HTTP Add-on
محدودیتCPU/Memory alone → بدون scale-to-zero

قدم بعدی

  1. با Helm در namespace keda نصب کنید و سه Deployment اپراتور را چک کنید.
  2. یک consumer ساده + صف (RabbitMQ یا Redis) و ScaledObject با minReplicaCount: 0 بسازید.
  3. صف را پر/خالی کنید و مسیر ۰↔۱↔N را با kubectl get pods -w ببینید.
  4. برای batch، یک ScaledJob روی SQS/Kafka امتحان کنید.
  5. TriggerAuthentication را به IAM/Workload Identity وصل کنید — کلید در YAML نگذارید.
  6. قبل از production، cooldown، maxReplica و رفتار fallback را در load test قفل کنید.

منابع

منتشر شده در P30Light — بخش زیرساخت و سرور

لینک گزارش با موفقیت کپی گردید!