Kedify Capabilities for Smarter Kubernetes

Kedify Insights turns monitored pod utilization into CPU and memory recommendations. Platform teams can review current requests and limits, see the recommended values and confidence, and apply the change from the dashboard or with a generated kubectl command.

• Scope recommendations by namespace Monitor only the namespaces you choose, then review recommendations by organization, cluster, workload, container, and resource type.
• Review before applying Each recommendation includes current value, recommended value, confidence, explanation, and the manual command behind the change.
• Connect action to savings Use Insights with FinOps views to find oversized workloads and prioritize the changes that reduce CPU and memory waste first.

The Kedify HTTP Scaler lets Kubernetes applications scale directly from incoming request rate or concurrency. It is built for APIs, web services, internal services, and intermittent workloads where traffic is the scaling signal that matters.

• Use request rate or concurrency Scale from the pressure users actually create instead of waiting for CPU to catch up.
• Scale to zero without custom plumbing Route and cache traffic through the Kedify proxy and interceptor so idle HTTP services can shrink safely.
• Autowire existing traffic paths Integrate with Ingress, Gateway API, Istio, OpenShift Routes, or in-cluster Services with fallback behavior for control-plane issues.

The Kedify Predictive Scaler trains on historical metric data and forecasts future demand. It works best for traffic patterns that repeat daily, weekly, seasonally, or around known business events.

• Train from real metric history Feed models from KEDA scalers, OpenTelemetry OTLP metrics, CSV bootstraps, or a combination of sources.
• Blend current and predicted demand Use KEDA scaling modifiers to combine live measurements with forecasted values for balanced decisions.
• Tune confidence and horizon Control prediction horizon, retraining interval, seasonality, and error thresholds for each MetricPredictor model.

The Kedify OpenTelemetry Scaler scales workloads from metrics ingested through OTLP. It gives teams a direct path from application or collector metrics to KEDA without operating a full Prometheus stack just for autoscaling.

• Push metrics directly to the scaler Use direct OTLP push, collector sidecars, static scrape targets, or Kubernetes service discovery.
• Query the signal you need Use a simple PromQL-like metric query with aggregations such as sum, avg, min, and max.
• React faster to AI and custom metrics Scale from high-frequency application, Dapr, GPU, and model-serving metrics without scrape-delay bottlenecks.

Kedify vertical scaling combines Pod Resource Profiles (PRP) for declarative lifecycle transitions and Pod Resource Autoscaler (PRA) for utilization-based in-place right-sizing. Together they let teams adjust CPU and memory without treating replica count as the only lever.

• Use Pod Resource Profiles for lifecycle profiles Raise resources during startup, shrink after container readiness, or react to ScaledObject activation and deactivation.
• Use Pod Resource Autoscaler for utilization bands Continuously adjust requests and limits from observed CPU or memory utilization with thresholds, cooldowns, and bounds.
• Avoid unnecessary restarts Apply resource updates through Kubernetes in-place pod resize when the cluster supports it.

Kedify multi-cluster scaling lets one KEDA cluster calculate demand and distribute work to member clusters. It supports deployment-style workloads with DistributedScaledObject and job-based workloads with DistributedScaledJob.

• Distribute replicas by weight Allocate capacity across member clusters with configured weights or use all registered clusters equally.
• Rebalance around outages Move desired replicas away from unreachable or unhealthy member clusters after a configurable grace period.
• Keep member clusters lightweight Member clusters host workloads and expose API access; they do not need their own KEDA installation for distributed scaling.

Multitenant KEDA lets platform teams run isolated KEDA operators per tenant, namespace, or business unit while a shared metrics adapter routes HPA metric requests to the right operator.

• Run tenant-scoped operators Each operator watches only its assigned namespaces and keeps its reconcile loop, deployment, and certificates separate.
• Route metrics automatically The shared metrics adapter maps each HPA request to the tenant operator responsible for that namespace.
• Keep transport isolated Kedify Agent discovers tenant registrations, syncs TLS material, and keeps mTLS connections separated per tenant.

Kedify FinOps connects scaling behavior, observed capacity, and estimated spend. Teams can compare current capacity with recent peaks and see where autoscaling and right-sizing are creating measurable savings.

• Track estimated spend and savings Review current cost, recent peak, estimated savings, and saved capacity at organization or cluster level.
• Drill into capacity types Inspect pods, nodes, CPU, memory, and GPU capacity to understand which signals are driving savings.
• Prioritize the next action Use high-savings clusters and workloads to decide where Insights, scaling policies, or scaler tuning should happen next.

Scaling Groups let teams define shared max capacity across multiple ScaledObjects. Kedify dynamically caps scaling metrics for group members so related services can share a backend safely.

• Group by label selector Add any existing or new ScaledObject to a ScalingGroup by matching labels.
• Cap aggregate replicas Keep the total group within a shared capacity while still respecting each workload minimum.
• Avoid backend overload Use group limits for database-bound services, shared queues, third-party APIs, or other constrained dependencies.

Kedify packages production KEDA operations with SOC 2 Type II controls, hardened image variants, signed attestations, and support from the engineers building and operating the autoscaling platform.

• SOC 2 Type II assurance Kedify has independent validation for Security and Availability controls across real operating practices.
• FIPS-aware hardened images Hardened Kedify images embed the Go FIPS 140-3 cryptographic module and publish verification evidence.
• Supported KEDA for regulated teams Use Hardened KEDA, signed artifacts, and engineering support where compliance, procurement, and uptime reviews matter.