What does AceMQ Kubernetes support cover?

We support message brokers running on Kubernetes — RabbitMQ, Tanzu RabbitMQ, Kafka, and ActiveMQ — across the full stack that keeps them running: StatefulSets, PVCs and storage classes, probes, PodDisruptionBudgets, network policy, operators, and Helm charts. Coverage includes 24/7 emergency response with a 15-minute SLA, root cause analysis on every P1, upgrade and migration support, and quarterly manifest reviews. This is not general-purpose Kubernetes platform support; it is deep support for the stateful workload that breaks most often.

Do you support RabbitMQ on Kubernetes specifically?

Yes, and it is our single largest Kubernetes workload. We are the number one RabbitMQ partner globally with direct access to the RabbitMQ core team, and we support both the RabbitMQ Cluster Operator and hand-rolled StatefulSet deployments. That covers quorum queue membership after node replacement, Erlang distribution over CNI, cert-manager TLS rotation breaking inter-node auth, and the operator reconcile failures that leave a cluster mid-upgrade.

Can you support Kafka running on Kubernetes?

Yes. We support Kafka on Kubernetes including Strimzi-managed clusters, covering broker and controller pod scheduling, storage sizing for log segments and fsync patterns, rack awareness mapped to zone topology, rolling upgrades under partition-availability constraints, and the KRaft migration path. As with RabbitMQ, most incidents turn out to be a platform-layer cause with a broker-layer symptom.

Why do our broker pods get OOMKilled when heap usage looks fine?

Because heap is not the whole story inside a container. A JVM without container awareness sizes its heap from node memory rather than the pod limit, and even a correctly sized heap sits alongside metaspace, thread stacks, direct byte buffers, and native memory used by the broker's network layer. The container limit counts all of it. The fix is usually MaxRAMPercentage plus explicit direct-memory limits, sized against measured off-heap usage rather than a guess.

How fast do you respond to a production Kubernetes incident?

P1 emergencies — brokers down, quorum lost, messages not flowing — get a 15-minute first response with a senior engineer joining a live bridge. P2 critical issues are 1 hour, P3 high-priority 4 hours, and P4 standard questions next business day. These are contractual, not best-effort targets.

Our platform team already supports Kubernetes. Where do you fit?

Alongside them, on the stateful workload. Platform teams are generally strong on the cluster and weaker on what a broker needs from it — the fsync behavior that makes a storage class inadequate, the drain sequence that costs you quorum, the probe timeout that kills a recovering node. We work directly with your platform team rather than around them, and most of our recommendations end up in their manifests, not ours.

How is AceMQ Kubernetes support priced?

Support is priced as an annual contract based on cluster count, broker footprint, required SLA tier, and coverage hours — not per incident or per ticket. Calling us during an outage never carries a cost decision. Contact us for a quote; we turn them around within 24 hours.

Kubernetes Support

24/7 Kubernetes Support for Message Brokers with a 15-Minute SLA

Stateful brokers are the hardest workload on Kubernetes. AceMQ supports RabbitMQ, Kafka, ActiveMQ, and Tanzu RabbitMQ running on EKS, AKS, GKE, and OpenShift — StatefulSet pods wedged in Terminating, quorum lost after a node drain, JVMs OOMKilled by cgroup limits, and storage classes that can't sustain broker fsync. Every ticket reaches a named senior engineer.

Senior Kubernetes engineers on call right now — 24/7/365

15 min emergency SLA24 /7 global coverage130 + enterprise customers26 + countries served

Available Now

Book a free Consultation.

Prefer to chat first?

Prefer to E-mail?

info@acemq.com

Trusted for mission-critical Kubernetes by teams in finance, healthcare, defense, and telecom

Escalation Path

Your first hour of a Kubernetes outage

Most vendors publish an SLA number. This is what actually happens, minute by minute, when you page a senior AceMQ engineer.

T+0

You page us

Phone, email, or Slack — any channel reaches the on-call senior engineer directly. No web form, no tier-1 queue.

T+15

Named engineer live

A senior engineer who already knows your environment joins a live bridge. Zero cold-start, no re-explaining your topology.

T+30

Root cause isolated

Direct broker access, log and metric review, and a working hypothesis with a rollback plan before we touch anything.

Post

Written RCA

Documented root cause, the fix applied, and the prevention steps — delivered after every P1, not just when asked.

Response Times

SLA tiers, contractually guaranteed

Every tier reaches a senior Kubernetes engineer. There is no tier-1 triage layer to get through.

P1 — Emergency

15 min

Production down, messages not flowing, cluster or broker failure

P2 — Critical

1 hour

Severe degradation, rising error rates, approaching capacity limits

P3 — High

4 hours

Performance issues, configuration problems, non-critical failures

P4 — Standard

Next day

Questions, guidance, best practices, non-urgent improvements

Incident Triage

Kubernetes problems we fix every week

These are real symptoms from real Kubernetes production environments — and the first thing our engineers check when one comes in.

Symptom you're seeingWhat we check firstTypical resolution

Broker StatefulSet pod stuck Terminating, cluster won't reform

What we check firstWhether the PVC is still bound and which node holds the volume attachment. A node that went NotReady leaves the pod in Terminating and the volume attached, so the replacement pod cannot schedule — and force-deleting the pod before the volume detaches risks two brokers writing one disk.

Typical resolutionUnder 1 hour

Split-brain or lost quorum after a routine node drain

What we check firstThe PodDisruptionBudget against actual quorum requirements. A PDB with maxUnavailable: 1 on a 3-node cluster still permits the drain that takes you to two members while one is mid-restart, so the drain reports success and the cluster loses majority.

Typical resolution1-3 hours

Broker pods OOMKilled with heap usage well under the configured max

What we check firstWhether the JVM sees the cgroup limit. Without UseContainerSupport and a percentage-based MaxRAMPercentage, the JVM sizes heap from node memory, not the pod limit — and off-heap buffers, metaspace, and page cache push the container past its limit long before heap looks full.

Typical resolutionUnder 2 hours

Publish latency spikes and write stalls with no CPU pressure

What we check firstThe storage class IOPS and throughput ceiling against the broker's fsync rate. gp2 or a default network storage class will throttle at exactly the wrong moment; we correlate volume-level burst-balance metrics with broker flush timings before touching the broker config.

Typical resolution2-4 hours

Nodes join then immediately partition — clustering never stabilizes

What we check firstNetworkPolicy and service mesh rules on the inter-broker ports. Erlang distribution (4369 and 25672), Kafka's controller and replication listeners, and headless service DNS all get blocked by default-deny policies or silently mangled by an mTLS sidecar that shouldn't be intercepting them.

Typical resolution2-4 hours

Pod restarts under load — liveness probe killing a healthy broker

What we check firstProbe timeout against broker behavior during GC, compaction, or recovery. A liveness probe with a 1-second timeout will kill a broker replaying its journal after restart, producing a restart loop that looks like a crash but is entirely self-inflicted.

Typical resolutionUnder 1 hour

Broker data lost or unbound after a StatefulSet update

What we check firstThe volumeClaimTemplate, reclaim policy, and whether the StatefulSet was recreated rather than patched. Deleting and reapplying a StatefulSet with a Delete reclaim policy destroys the PVCs — and Helm chart upgrades that change immutable fields quietly encourage exactly that.

Typical resolutionSame day

Rolling upgrade hangs partway, half the cluster on the new version

What we check firstThe readiness probe against the broker's own cluster-health definition. StatefulSet rolling updates wait for readiness before moving on, so a probe that reports ready before the node has fully rejoined — or never reports ready at all — leaves the rollout mid-flight with mixed versions.

Typical resolution1-3 hours

Resolution times reflect typical Kubernetes engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.

Not on the list? Tell us what's breaking

Support In Practice

Kubernetes problems we've already solved

Representative engagements showing how these incidents get diagnosed and closed under an AceMQ support contract.

All use cases

Assessment

Stabilizing RabbitMQ on Kubernetes for Mission-Critical Airport Systems

Global Aviation Technology Provider

Troubleshooting cluster failover, partition handling, and quorum queue issues in a high-stakes aviation operational environment.

RabbitMQKubernetesQuorum Queues

Read case study

Managed Services

Managed RabbitMQ Platform Modernization

Fortune 500 Software Company

Migration to supported RabbitMQ versions with managed services, standardization, compliance posture, and Tanzu commercial licensing.

RabbitMQTanzu RabbitMQAWS

Read case study

Remediation

RabbitMQ Performance Remediation for Telecom-Scale IoT

Global Telecom Leader

Resolving weekly RabbitMQ crashes, optimizing for 300,000+ connected devices, and architecting horizontal scaling strategy.

RabbitMQKubernetesQuorum Queues

Read case study

CVE Patching

Enterprise-Wide RabbitMQ CVE Patching and Compliance Strategy

Enterprise IT Management Company

Implementing a comprehensive CVE patching and compliance strategy across 10,000+ RabbitMQ deployments running end-of-life versions, with real-time vulnerability monitoring and phased upgrade planning.

RabbitMQKubernetesLinux

Read case study

Remediation

Elasticsearch Cluster Stuck Yellow After Node Loss

Global Payments Processor

Emergency remediation of an Elasticsearch cluster that would not return to green after a data node failure, with replicas blocked by disk watermarks.

ElasticsearchKibanaLinux

Read case study

Support

Elasticsearch Heap Pressure and Circuit Breaker Support

SaaS Observability Vendor

Ongoing 24/7 support for an Elasticsearch estate suffering repeated parent circuit breaker trips and long garbage collection pauses under aggregation load.

ElasticsearchKibanaKubernetes

Read case study

Support

OpenSearch Cluster Support for Regulated Workloads

Public Sector Agency

24/7 enterprise support for OpenSearch clusters carrying regulated search and audit workloads, including security plugin and upgrade coverage.

OpenSearchOpenSearch DashboardsLinux

Read case study

Remediation

Grafana Outage and Datasource Timeout Remediation

Telecommunications Operator

Remediation of a Grafana deployment that became unusable during incidents, with dashboards timing out exactly when engineers needed them most.

GrafanaPrometheusKubernetes

Read case study

What's Included

Everything in your Kubernetes support contract

No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.

Emergency Incident Response

Broker pods crash-looping, quorum lost, or a cluster that won't reform after a node event. A senior engineer joins a live bridge within 15 minutes with kubectl access to diagnose — not a ticket acknowledgement.

Root Cause Analysis

Every P1 closes with a written RCA: what failed, why, the fix applied, and the manifest, probe, or policy change that prevents recurrence. Delivered as standard, not on request.

Storage & StatefulSet Design

Storage class selection, IOPS and throughput sizing against broker fsync patterns, volume expansion procedures, and PVC retention policy — reviewed before you discover the limits during an incident.

Resilience & Disruption Budgets

PodDisruptionBudgets that actually protect quorum, anti-affinity across zones and nodes, topology spread constraints, and drain runbooks your platform team can execute without paging us.

Operator & Helm Support

RabbitMQ Cluster Operator, Strimzi, and vendor Helm charts — reconcile failures, CRD upgrades, values drift, and the version-skew problems that surface when the operator and broker upgrade on different schedules.

Migration to and from Kubernetes

Moving brokers onto Kubernetes from VMs or bare metal, and moving them back off when the operational cost isn't justified. Both directions, with parallel-run validation and zero message loss.

Anywhere You Run It

We support Kubernetes wherever it's deployed

Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.

Amazon EKSAzure AKSGoogle GKE & AutopilotRed Hat OpenShiftVMware Tanzu Kubernetes GridRancher / RKE2Self-managed kubeadm clustersAir-gapped / disconnected clustersRabbitMQ Cluster OperatorStrimzi & Kafka on KubernetesActiveMQ Artemis on KubernetesIstio, Linkerd & service mesh deployments

Why AceMQ

What you get that you don't get elsewhere

Named Engineers, Zero Cold Start

The same senior engineers stay on your account. They know your cluster layout, your storage class, and your broker topology — so a P1 call starts with diagnosis, not twenty minutes of you explaining which cloud and which operator.

No Tier-1 Triage Layer

You reach a senior engineer directly by phone, email, or Slack. No help desk collecting information to pass along, and no escalation approval process standing between you and someone who can actually fix it.

Broker and Platform, Not One or the Other

Your Kubernetes vendor doesn't know RabbitMQ internals. Your broker vendor doesn't debug CNI or CSI. Broker-on-Kubernetes incidents live exactly in that gap, and both parties will tell you the problem is on the other side.

Genuine Follow-the-Sun Coverage

Engineers across 26+ countries and every time zone. Your 3am node-drain incident is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to wake up.

Proactive, Not Just Reactive

Quarterly reviews of your manifests, probes, disruption budgets, and storage headroom. When a chart or operator version introduces a regression on one customer's cluster, every affected customer hears about it before their next upgrade window.

Regulated and Air-Gapped Clusters

We work in environments with no outbound network access, private registries only, and change control that measures deployments in weeks. Support that assumes you can just pull a new image is not support for these clusters.

FAQ

Kubernetes support questions

Stateful Workloads Deserve More Than Best-Effort

Whether a broker cluster is down tonight or you want your manifests reviewed before the next node-pool upgrade, AceMQ staffs every engagement with a named senior engineer who knows both the broker and the platform. Support quotes returned within 24 hours.

Get in Touch

Talk to a Support Expert

Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.

305-204-2607

info@acemq.com

66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.