Free audit

View Audit Scope
Dragonfly on K8sDragonfly Operator CRD · Proactor CPU Pinning · io_uring NodePools

Dragonfly on Kubernetes Consulting & DBRE Services

JusDB designs, hardens, and operates Dragonfly on Kubernetes across Amazon EKS, Google GKE, Azure AKS, and bare-metal OpenShift. Our database reliability engineers configure the Dragonfly Operator (dragonflydb.io/v1alpha1) and Helm charts, align Pinned QoS integer CPU limits 1-to-1 with --proactor_threads to prevent Linux CFS throttling, provision Linux 5.15+ io_uring worker node pools, and automate zero-fork .dfs snapshot recovery.

The first 30-minute call covers your databases, current ownership, and required coverage. No production access is needed. Or request a free audit of one database instance.

  • NDA before access
  • Read-only by default
  • Written scope before work starts

Dragonfly on Kubernetes DBRE controls

Select a K8s subsystem to inspect

Host Core Count vs Container cgroup CPU

Pin --proactor_threads == CPU

If --proactor_threads is not explicitly set, Dragonfly may spawn threads matching the 64-core Kubernetes worker host even inside a 4-CPU pod, causing catastrophic CFS quota throttling.

We enforce Pinned QoS with integer CPU requests/limits (kubelet static CPU Manager) and explicitly pass --proactor_threads matching the container allocation.

Inspect hardened Dragonfly CRD manifest

Verified against dragonflydb.io/v1alpha1 Operator specifications and Kubernetes cgroup v2 CPU Manager.

Kubernetes stacks covered
Dragonfly Operator (dragonflydb.io/v1alpha1), Helm StatefulSets, Amazon EKS, Google GKE, Azure AKS, and OpenShift
Initial-response targets
15 minutes for a critical (P1) incident under a 24x7 support agreement; 2 to 4 hours in business hours. See details
Coverage hours
Business hours (03:30–12:30 UTC) by default; 24x7 on-call available under a 24x7 support agreement

Selected clients

  • Innoviti
  • Blitz
  • Freecharge
  • Nango
  • Recochain
  • Screen Facts
  • Nexora
  • WeCredit

Production failure modes

Common Dragonfly on Kubernetes issues we resolve

Because Dragonfly spawns pinned proactor threads and uses Linux io_uring, running it inside uncalibrated Kubernetes cgroups causes CFS throttling and seccomp fallbacks.

Dragonfly on Kubernetes production symptoms, root causes, and first diagnostic actions
Kubernetes / Dragonfly signalWhat is usually happeningWhere we start
CFS Throttling (64 Threads in 4 CPUs)Dragonfly p99 latency spikes to 40ms+ immediately after pod startupDragonfly detects 64 physical cores on the Kubernetes worker node and spawns 64 proactor threads inside a pod limited to resources.limits.cpu: 4, burning the 100ms CFS quota in 6ms.Explicitly pass --proactor_threads=4 matching the container's integer CPU request/limit, and enable kubelet static CPU Manager policy on the cache node group.
io_uring ENOSYS / EPERMPod logs warn that io_uring initialization failed or snapshots stallDocker/containerd seccomp profiles block io_uring_setup/io_uring_enter syscalls, or the container's RLIMIT_MEMLOCK (ulimit -l) is too small to lock io_uring ring buffers.Provision Linux 5.15+/6.x worker nodes, raise container default memlock ulimits in containerd, and configure seccompProfile to allow io_uring syscalls.
OOMKilled without cache_modeDragonfly pod rejects writes or hits Exit 137 when dataset growsThe Dragonfly CRD omitted --cache_mode=true (leaving eviction disabled) or set --maxmemory equal to the full resources.limits.memory without leaving room for pipeline buffers.Set Pinned QoS (requests == limits), configure --maxmemory to 80% of limits.memory, and pass --cache_mode=true for Dash 2-bit LFRU eviction.
Operator Upgrade SplitClients receive connection resets or write to a demoted pod during upgradeApplication pods cache the old primary Pod IP instead of routing through the Operator's role=master Service selector, or Karpenter drains primary and replica nodes simultaneously.Route writes strictly via the Operator Service (selector: role=master), set DNS TTLs <= 2s, enforce cross-AZ topologySpreadConstraints, and add karpenter.sh/do-not-disrupt.
Partial .dfs PVC RestoreRestarted Dragonfly pod fails to load snapshot or loses keys after rescaleChanging --proactor_threads from 16 to 8 without migrating snapshots leaves orphaned dump-0008..0015.dfs shard files or mismatches PVC volume mounts.Standardize proactor thread counts per tier, configure S3/GCS snapshot shipping (s3://bucket/prefix) in the Dragonfly CRD, and test automated cold restores.
Liveness Probe Kill on Loadkubelet restarts Dragonfly pod in a loop while restoring a 100 GiB S3 snapshotRestoring 100+ GiB of parallel .dfs files from S3 or PVC takes 30-90 seconds, exceeding an aggressive livenessProbe window before the port accepts PING.Configure a generous startupProbe on the Dragonfly StatefulSet template and gate Service endpoint inclusion on the Operator's readiness and role labels.

Technical scope

What does our Dragonfly on Kubernetes service include?

We engineer production-ready Dragonfly Operator CRDs, static CPU-pinned node pools, S3 .dfs snapshot pipelines, and native Prometheus alerting.

  • Dragonfly Operator CRD & Helm engineering

    We deploy, audit, and customize the official Dragonfly Kubernetes Operator (dragonflydb.io/v1alpha1) and Helm charts for GitOps-driven production operations.

    • Review and harden Dragonfly CRDs, args flags, ACL Secret mounts, and TLS certificates
    • Validate Operator controller RBAC, webhook availability, and role=master label reconciliation

    dragonflydb.io/v1alpha1 · Dragonfly Operator · Helm · ArgoCD / Flux

    Dragonfly consulting & architecture
  • Pinned QoS, static CPU Manager & thread pinning

    Dragonfly's shared-nothing proactor architecture demands 1-to-1 alignment between threads and physical vCPUs. We eliminate Kubernetes CFS CPU throttling.

    • Pin --proactor_threads to exact integer Pinned QoS CPU requests and limits
    • Configure kubelet static CPU Manager policy and single-NUMA-socket node selectors

    --proactor_threads · Pinned QoS · static CPU Manager · cpuset

    Dragonfly performance tuning
  • io_uring node pools, PVCs & S3 snapshot recovery

    We engineer the underlying EKS, GKE, or AKS worker node pools and storage classes so zero-fork parallel .dfs snapshots run at wire speed.

    • Provision Linux 5.15+/6.x node groups with io_uring seccomp and memlock ulimits enabled
    • Configure automated parallel .dfs snapshots to AWS EBS gp3/NVMe PVCs or S3/GCS buckets

    io_uring · snapshotSpec · S3 / GCS · EBS gp3 / Local NVMe CSI

  • Zone-aware scheduling & rolling Operator upgrades

    We protect vertical Dragonfly HA pairs against AZ outages, Karpenter node consolidation, and disruptive rolling image updates.

    • Enforce hard podAntiAffinity and topologySpreadConstraints across Availability Zones
    • Rehearse Operator replica-first rolling upgrades and primary switchover under load

    topologySpreadConstraints · PodDisruptionBudget · karpenter.sh/do-not-disrupt

  • Redis Cluster to K8s Dragonfly consolidation

    Running 20+ Bitnami or Opstree Redis Cluster pods on Kubernetes? We consolidate them into a 2-pod vertical Dragonfly CRD with emulated Cluster Mode.

    • Enable --cluster_mode=emulated so existing Cluster SDKs connect without code changes
    • Stream live data from Kubernetes Redis StatefulSets into Dragonfly via REPLICAOF

    --cluster_mode=emulated · REPLICAOF · Service cutover · TCO reduction

    Dragonfly migration services
  • Prometheus observability & 24x7 K8s SRE support (where contracted)

    Dragonfly exposes rich native Prometheus metrics on port 6379 (/metrics) without needing a sidecar exporter. We wire full Kubernetes alerting.

    • Configure PodMonitor / ServiceMonitor scraping native Dragonfly /metrics endpoints
    • Alert on per-thread CPU skew, VLL lock latency, Dash eviction rates, and replica lag

    PodMonitor · dragonfly_* metrics · Grafana · PagerDuty alert rules

    Dragonfly 24x7 support (where contracted)

Shared responsibility & response targets

Where default Operator quickstarts stop and what JusDB engineers run

Applying the sample Dragonfly CRD gets a pod running, but production multi-core throughput requires static CPU pinning, io_uring node preparation, and tested S3 snapshot recovery.

Comparison between default Dragonfly Operator manifests and JusDB Kubernetes DBRE configurations
Kubernetes subsystemWhere default CRDs stopWhat JusDB engineers run
Proactor threads vs container CPU limitsLeaves --proactor_threads unset in the CRD, spawning 32-64 threads inside a 4-vCPU container and causing severe CFS throttling.Enforces Pinned QoS integer CPUs with kubelet static CPU Manager and matches --proactor_threads 1-to-1 to allocated cores.
cgroup memory utilization & cache_modeCopies Redis 65% maxmemory rules or forgets --cache_mode=true, wasting RAM or triggering OOM write errors.Allocates up to 80% of container memory limit to --maxmemory (thanks to zero-fork snapshots) with --cache_mode=true LFRU.
Worker node kernel & io_uring supportSchedules Dragonfly onto default shared nodes where seccomp or low memlock ulimits degrade io_uring snapshot performance.Provisions dedicated tainted Dragonfly NodePools with kernel 5.15+/6.x, unlimited memlock, and verified io_uring rings.
Multi-AZ placement & Karpenter safetyAllows primary and replica pods to land in the same AZ or get evicted simultaneously by Karpenter node consolidation.Configures required cross-AZ podAntiAffinity, PodDisruptionBudgets, and karpenter.sh/do-not-disrupt annotations.
Snapshot persistence & S3 recoveryMounts a basic PVC without testing whether all N parallel .dfs shard files restore cleanly on pod replacement.Configures CRD snapshotSpec to PVC + S3/GCS with IAM Roles for Service Accounts (IRSA) and runs scheduled restore drills.
Observability & exporter overheadAttaches unnecessary external redis_exporter sidecars that miss Dragonfly-specific fiber and Dash-table metrics.Scrapes Dragonfly's native HTTP /metrics endpoint via PodMonitor for thread-level VLL, Dash segment, and io_uring telemetry.

Published initial-response targets by severity

Standard business hours: 03:30–12:30 UTC

Initial-response targets are 2 to 4 hours during covered business hours, Mon–Fri 09:00–18:00 IST (UTC+5:30). Where your service agreement includes 24x7 on-call, the initial-response target for P1 incidents is 15 minutes. Targets are not resolution guarantees.

SeverityInitial responseDefinitionChannel & coverage
P1 · Critical15 minutesProduction database down, primary unreachable, data corruption risk, or active failover event.24x7 on-call (under your service agreement) · Direct PagerDuty, Opsgenie, or phone page plus incident bridge
P2 · High30 minutesSevere latency spike, replication lag climbing rapidly, connection exhaustion, or degraded HA node.24x7 on-call (under your service agreement) · On-call alert plus shared Slack or Teams channel
P3 · Medium60 minutesNon-critical slow query regression, staging issue, backup warning, or replication check alert.24x7 on-call (under your service agreement) · Shared Slack or Teams channel or support ticket
P4 · Low90 minutesConfiguration question, index advisory, planned schema review, or general operational request.24x7 on-call (under your service agreement) · Shared Slack or Teams channel or support ticket

Our engineering team is in India; business-hours coverage is Mon–Fri 09:00–18:00 IST (UTC+5:30), and 24x7 on-call is available under your service agreement.

Initial-response targets, not resolution guarantees. The target for your engagement is set in your service agreement.

Interactive Operator & cgroup simulator

How Dragonfly Operator manages CPU pinning and failovers

Compare a CPU-pinned Pinned QoS Dragonfly CRD against an unpinned Burstable pod suffering CFS throttling and a replica-first rolling upgrade.

Dragonfly on Kubernetes Operator & proactor thread simulator

Select a state to inspect proactor thread alignment, role=master Service routing, and rolling upgrade behavior.

Dragonfly Operator, Service (role=master) & Proactor Fibers

Kubernetes Service (selector: role=master) routes traffic to dragonfly-0 in AZ-a; 16 pinned proactor fibers process 1.4M RPS at 0.35ms p99.

16 vCPUs == 16 proactor_threads · Zero-fork S3 sync
  • dragonfly-prod-0 (AZ-a · role=master)

    Pinned 16 CPU / 128Gi · --proactor_threads=16

    ONLINE · maxmemory 102Gi (80%) · 0% CFS throttle

  • dragonfly-prod-1 (AZ-b · role=replica)

    16-stream parallel replication · Anti-affinity AZ-b

    SYNCED · Streaming zero-fork .dfs to S3

  • Dragonfly Operator Controller

    Watches health & maintains role=master label

    RECONCILED · PDB maxUnavailable: 1 active

With Pinned QoS integer CPUs and --proactor_threads=16 matched to kubelet's static CPU Manager, each Dragonfly fiber loop runs on an exclusive physical core with zero CFS throttling.

Representative production deliverable

How a Dragonfly Operator CRD and node-pool audit is delivered

Every engagement delivers the hardened dragonflydb.io/v1alpha1 CRD manifest, the PodMonitor telemetry spec, and the node-pool configuration.

Sample deliverable · Hardened Dragonfly Operator CRD with static CPU pinning & S3 snapshotsEKS 1.31 · dragonflydb.io/v1alpha1

Finding

Unpinned proactor threads on 64-core EKS nodes caused 34ms p99 latency spikes

The Dragonfly pod requested 8 CPUs on a 64-vCPU r7g.16xlarge host without passing --proactor_threads=8. Spawning 64 threads inside an 8-CPU cgroup caused 62% CFS throttling. Pinning 16 threads to 16 Pinned CPUs dropped p99 to 0.39ms.

Pod p99 latency34.6ms to 0.39ms
Usable cache / pod RAM65% to 80%

1. Production Dragonfly CRD: Pinned QoS, 16 pinned proactor threads & S3 .dfs snapshots

dragonfly-prod.yaml · dragonflydb.io/v1alpha1

apiVersion: dragonflydb.io/v1alpha1
kind: Dragonfly
metadata:
  name: dragonfly-cache
  namespace: data-prod
spec:
  replicas: 2
  image: docker.dragonflydb.io/dragonflydb/dragonfly:v1.24.0
  annotations:
    karpenter.sh/do-not-disrupt: "true"
  args:
    - "--proactor_threads=16"
    - "--conn_io_threads=4"
    - "--maxmemory=102G"
    - "--cache_mode=true"
    - "--cluster_mode=emulated"
    - "--lock_on_hashtags=true"
  resources:
    requests:
      cpu: "16"
      memory: "128Gi"
    limits:
      cpu: "16"
      memory: "128Gi"
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: DoNotSchedule
  snapshot:
    cron: "0 */4 * * *"
    dir: "s3://prod-dragonfly-snapshots/cache-cluster"

2. Native Prometheus PodMonitor & role label verification

dragonfly-podmonitor.yaml & kubectl check

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: dragonfly-cache-metrics
  namespace: data-prod
spec:
  selector:
    matchLabels:
      app: dragonfly-cache
  podMetricsEndpoints:
    - port: admin
      path: /metrics
      interval: 15s
---
# Verify Pinned QoS and Operator role=master assignment
# kubectl get pods -n data-prod -l app=dragonfly-cache -L role

Ways to work together

How to engage JusDB for Dragonfly on Kubernetes

Start with a free read-only audit of your Dragonfly Operator CRD and node pools, scope a turnkey K8s deployment or Redis consolidation, or put your cluster under ongoing DBRE coverage.

Scoped K8s DBRE projectThis page

Architect, pin, or consolidate onto Dragonfly Operator.

A fixed-scope engagement delivering GitOps Dragonfly CRDs, static CPU-pinned NodePools, S3 snapshot pipelines, and rehearsed failover testing.

Common K8s scopes agreed in writing first

  • Dragonfly Operator CRD tuning
  • Static CPU Manager & thread pinning
  • io_uring NodePool & S3 .dfs
  • K8s Redis Cluster consolidation
  • Multi-AZ failover & drain drills
Free K8s Dragonfly audit

One Dragonfly CRD or StatefulSet, audited read-only.

We inspect your proactor thread flags, container CPU/memory limits, worker node kernel io_uring support, and snapshot config, then deliver a written report within one week.

What we check on your Kubernetes cluster

  • proactor_threads vs cgroup CPU & CFS throttling
  • Dash cache_mode, maxmemory & io_uring seccomp
  • Cross-AZ anti-affinity, PDBs & S3 .dfs recovery
Ongoing K8s DBRE & support

Named engineers covering your Kubernetes Dragonfly estate.

Proactive PodMonitor alerting, Operator upgrades, .dfs snapshot restore drills, and incident response under a 24x7 support agreement.

  1. Page on-callavailable under a 24x7 support agreement
  2. 15 minP1 initial-response target
  3. Written RCAafter every P1

Kubernetes distributions and cloud platforms we support

Evaluation Vector
JusDB DBRE
In-House DBALegacy AgencyDeveloper Generalist
Dragonfly Operator Architecture & Dragonfly CRD TuningDeploys the official Dragonfly Operator with tuned Dragonfly CRD manifests, configuring vertical CPU scaling, kernel fs.file-max, and connection multiplexing for seamless cloud-native lifecycle management.Deploys raw StatefulSets without the operator, manually tracking replica endpoints and struggling to automate failovers during worker node updates.Attempts to manage Dragonfly using legacy Redis Sentinel Helm charts, introducing incompatible sentinel coordination protocols that corrupt state.Deploys Dragonfly as a stateless Deployment with default replica counts, causing split-brain keyspace divergences on restart.
Multi-Threaded Shared-Nothing Fiber CPU Core AllocationConfigures vertical Guaranteed QoS with static CPU core reservations, enabling Dragonfly's shared-nothing fiber execution engine to saturate all available physical cores with zero lock contention.Caps container resources with shared Burstable CPU limits, triggering CFS quota throttling that degrades Dragonfly's multi-threaded fiber scheduling.Runs single-threaded container templates based on Redis assumptions, restricting Dragonfly to 1 vCPU and losing up to 25x throughput capacity.Overcommits CPU resources across dense multi-tenant nodes, inducing thread migration penalties and L3 cache thrashing under burst traffic.
Linux io_uring Zero-Fork Snapshot StorageClass SizingProvisions low-latency NVMe PersistentVolumeClaims formatted with XFS and verifies Linux host kernel io_uring syscall availability, enabling non-blocking zero-fork DFS/RDB snapshot persistence.Configures snapshots onto slow network storage without kernel io_uring verification, stalling background persistence threads under heavy write loads.Assumes Redis BGSAVE fork semantics and over-provisions RAM by 200% to guard against memory doubling, inflating cloud infrastructure costs.Disables persistent volumes entirely or uses dynamic provisioners with incorrect reclaim policies, losing point-in-time snapshots upon pod reschedule.
PodDisruptionBudgets (PDB) & Cross-AZ Anti-AffinityImplements strict PodDisruptionBudgets (minAvailable=1) and hard podAntiAffinity with topologySpreadConstraints across availability zones, protecting primary and replica availability during node maintenance.Omits PDBs, allowing Kubernetes node drain operations to simultaneously terminate primary and replica instances during automated cluster upgrades.Deploys all pods in a single Kubernetes worker node group, leaving the cache layer vulnerable to localized hypervisor or rack failures.Configures soft anti-affinity, permitting the scheduler to place both Dragonfly pods on the same worker node under resource pressure.
Rolling Stateful Upgrades & Replication CatchupOrchestrates phased rolling updates with automated replica warm-up, snapshot synchronization verification, and atomic primary role failover to preserve in-flight client writes.Restarts the primary pod directly without pre-promoting the replica, dropping active client TCP connections and inducing cache stampedes.Executes manual container image swaps without testing replica catchup lag, resulting in stale read responses post-upgrade.Relies on standard Kubernetes RollingUpdate strategies that kill pods before replication catchup completes, losing volatile cache keys.
Cloud-Native Prometheus Metrics, Grafana & Memory GovernanceIntegrates Dragonfly's native Prometheus exporter with ServiceMonitors, Grafana memory distribution dashboards, and automated eviction policies (maxmemory-policy) with calibrated watermark alerts.Collects basic Kubernetes pod memory usage without tracking internal keyspace fragmentation, leading to sudden Linux OOM kills.Installs legacy Redis exporter sidecars that fail to parse Dragonfly-specific fiber stats and multi-threaded engine metrics.Sets container memory limits equal to Dragonfly maxmemory, causing kernel OOM termination during small buffer allocations.

For procurement and platform security teams

Mutual NDA first, namespace-scoped RBAC, and GitOps delivery

We deliver all Dragonfly Operator CRD, Helm, and Terraform node-pool changes via Git pull requests under mutual NDA and least-privilege Kubernetes RBAC.Raguraman, Engineering Manager · Allen D, Lead Database SRE
  • Mutual NDA
  • Written statement of work
  • Scoped K8s RBAC
  • GitOps PR workflow
  • NDA before access

    Signed before inspecting any Dragonfly CRDs, node configs, or Prometheus metrics.

  • Written statement of work

    Target Kubernetes clusters, deliverables, chaos drill criteria, and fees agreed in writing.

  • Read-only RBAC by default

    Scoped read-only Kubernetes Role bindings and Dragonfly ACLs without secret exfiltration.

  • Manifests & runbooks you keep

    Every Dragonfly CRD, PodMonitor spec, and upgrade runbook stays in your Git repository. Meet the JusDB team.

JusDB's security practices are aligned with ISO 27001 and SOC 2 Type II, and JusDB is pursuing both certifications (see Terms, section 12). Read the stated status.

Technical FAQ

Dragonfly on Kubernetes common questions

Answers on the Dragonfly Operator CRD, --proactor_threads CPU pinning, 80% zero-fork cgroup memory sizing, io_uring kernels, and S3 .dfs snapshots.

Still have a question?

Ask it on a scoping call. No production access needed.

Book a 30-min scoping call (opens Google Calendar in a new tab)

How does the Dragonfly Kubernetes Operator manage high availability and failovers?

The official Dragonfly Operator (dragonflydb.io/v1alpha1) deploys a backing StatefulSet and actively monitors every pod's health. It assigns role=master to the primary pod and role=replica to standby pods, wiring a Kubernetes Service with selector role=master. If the primary pod fails or a node drains, the Operator executes REPLICAOF NO ONE on the healthiest replica, updates its pod label to role=master so traffic routes immediately, and reconfigures remaining replicas.

Why must --proactor_threads be set explicitly when running Dragonfly on Kubernetes?

When Dragonfly starts without --proactor_threads, it inspects host CPU cores - which in many Kubernetes environments reflects the underlying 32, 64, or 128-core worker VM rather than the pod's cgroup limit. Running 64 busy proactor threads inside a pod limited to 4 or 8 vCPUs causes intense context switching and Linux CFS bandwidth throttling. We always set integer CPU requests == limits and pass --proactor_threads equal to that exact CPU count.

How much memory can we allocate to --maxmemory in a Dragonfly Kubernetes pod?

In Redis or Valkey Kubernetes pods, you must cap maxmemory at 65-70% of resources.limits.memory so copy-on-write BGSAVE forks do not trigger Exit Code 137 OOMKills. Because Dragonfly uses zero-fork shared-nothing snapshotting, there is no fork() memory multiplication. We safely configure --maxmemory at 80% to 85% of the Pinned QoS container memory limit, leaving 15-20% for connection pipeline buffers and replication streams.

What Kubernetes worker node requirements does Dragonfly need for io_uring?

Dragonfly achieves its highest network and disk snapshot throughput using Linux io_uring, which requires a host Linux kernel >= 5.10 (we recommend 5.15 LTS or 6.1+ on EKS AL2023, Bottlerocket, GKE Container-Optimized OS, or AKS Ubuntu 22.04). Additionally, containerd must permit io_uring syscalls in its seccomp profile and provide a sufficient memlock ulimit (RLIMIT_MEMLOCK) so Dragonfly can register ring buffers.

How do backups and automatic restores work in the Dragonfly Operator CRD?

The Dragonfly CRD supports a native snapshotSpec block that accepts a cron schedule, a PersistentVolumeClaimTemplate, or an S3/GCS URI (for example s3://prod-dragonfly-backups/cache-a) authenticated via AWS IRSA / Pod Identity or GCP Workload Identity. On cold cluster creation or disaster recovery, Dragonfly automatically streams all parallel .dfs shard files from S3 back into memory across all proactor threads.

How do we monitor Dragonfly on Kubernetes with Prometheus?

Unlike Redis, which requires a separate redis_exporter sidecar container, Dragonfly natively serves Prometheus metrics in OpenMetrics format directly on its main port (http://<pod-ip>:6379/metrics). We deploy a kube-prometheus-stack PodMonitor or ServiceMonitor to scrape dragonfly_commands_total, dragonfly_memory_used_bytes, dragonfly_evicted_keys_total, and replication offset lag.

Can we consolidate our Kubernetes Redis Cluster StatefulSets into the Dragonfly Operator?

Yes. We deploy a vertical Dragonfly CRD alongside your existing Bitnami or OT-Container-Kit Redis Cluster with --cluster_mode=emulated enabled, replicate live data via REPLICAOF or Redis-Shake, and switch your Kubernetes Service selector with a sub-second write pause - often reducing pod count from 12-24 pods down to 2 pods.

What are your response targets for Dragonfly on Kubernetes incidents?

Initial-response targets are 2 to 4 hours during covered business hours, Mon–Fri 09:00–18:00 IST (UTC+5:30). Where your service agreement includes 24x7 on-call, the initial-response target for P1 incidents is 15 minutes. Targets are not resolution guarantees.

Next step

Talk to an engineer about your Dragonfly on Kubernetes estate

Tell us which Kubernetes platform you run and whether you are deploying the Dragonfly Operator or consolidating Redis pods. The first 30-minute call covers your databases, current ownership, and required coverage. No production access is needed. Or request a free audit of one database instance, subject to availability: mutual NDA before read-only access, a prioritized report within one week after access is ready, and no obligation.

NDA before access · read-only by default · written scope first

Related Dragonfly Services

Explore more ways our Dragonfly experts can help with your database infrastructure.