Managed Kubernetes
Last reviewed by Tyler Eastridge
AceMQ operates Kubernetes clusters on Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), OpenShift and on-premises, in your own cloud account or data centre (Tier 3) or on infrastructure we run (Tier 4). We own version upgrades, node pools, ingress, certificate rotation, observability, Velero backups, security patching and the pager, plus the RabbitMQ, Redis and Kafka operators that run on top. Cluster operations are delivered by AceMQ with partner Kubernetes specialists, under one contract and one escalation path.
Support quotes answered within 1 hour, by a senior engineer.
Planning a build, upgrade or migration instead? See AceMQ Kubernetes consulting and services.
Customers
Partners
What's Included
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
We plan and run control plane upgrades one minor release at a time, because the project does not let kube-apiserver skip minors. Before each one we scan manifests, Helm releases and live objects for APIs the target release removes, and check operators, CSI drivers and CNI plugins against the target. Nodes follow within the kubelet skew limit, and we replace them instead of upgrading kubelets in place.
We manage node pools: image and OS patching, node replacement, autoscaler settings, taints and dedicated pools for stateful workloads, and headroom reviewed against requests and limits so a drain has somewhere to put the pods. Capacity planning is written down, not kept in someone's head.
We run ingress or Gateway API, CoreDNS and network policy. The Kubernetes Steering and Security Response Committees said in January 2026 that Ingress NGINX would be retired in March 2026. The repository was archived read-only on 24 March 2026, so there are no further releases, bug fixes or security patches. Clusters still on it get a migration plan, tested route by route.
We track expiry of every certificate that can take a cluster down: kubeadm control plane certificates (valid for one year by default, and renewed on control plane upgrade), kubelet certificates, ingress and service certificates issued through cert-manager, and webhook CA bundles that fail silently when a certificate rotates. Secret encryption and external secret stores are checked against your policy.
We manage monitoring of what predicts cluster incidents: API server latency and errors, etcd health where we run it, node pressure, pending and evicted pods, PVC capacity and certificate expiry, on Prometheus and Alertmanager or the monitoring stack you already run. Then we take the pager, so an alert reaches an engineer who knows the cluster.
Velero backs up cluster resources and persistent volume data to object storage on a schedule. We deploy and manage it, set retention against your recovery objectives, and restore into a scratch cluster on a schedule, because a backup that has never been restored is a guess. Brokers and databases get an application-level backup alongside the cluster one.
We manage patching of Kubernetes patch releases, node images and cluster add-ons, with CVE assessment against the version you run, and the baseline policy: Pod Security Standards, network policy, RBAC review and admission rules. AceMQ supports the current Kubernetes release and the five end-of-life release lines before it, so a cluster that is behind stays covered while the upgrade is planned.
We run the RabbitMQ Cluster Operator, Strimzi for Kafka and Redis operators or charts on the clusters we manage: storage classes sized for fsync, PodDisruptionBudgets that protect quorum, and drain runbooks. These are the workloads AceMQ's broker and database engineers already support on Kubernetes.
Why AceMQ
Run managed Kubernetes in your own cloud account, data centre or OpenShift (Tier 3) when residency and compliance rules keep clusters and data inside your boundary. Or have AceMQ run the platform and the stateful services on infrastructure we operate (Tier 4), so your teams consume namespaces and endpoints and own no cluster operations.
When a StatefulSet fails on a managed cluster, the platform vendor points at the broker and the broker vendor points at the platform. AceMQ's broker and database engineers already work these incidents, so the cluster and the workload sit under one contract and one escalation path.
Cluster platform operations are delivered by AceMQ together with partner Kubernetes specialists, working to AceMQ's runbooks and contract. The proposal says who does what for your clusters, so you know who holds the pager for the control plane, the nodes and the workloads.
We run upstream-conformant clusters and your existing distribution, not a proprietary platform. Runbooks, the delivery repository, monitoring configuration and the upgrade calendar are maintained as yours, so bringing operations back in-house, or moving between your infrastructure and ours, starts from a current handover pack.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
Version windows
A managed cluster lives on a calendar. The project patches the three newest minor releases for about a year, the cloud providers add their own windows on top, and every window ends in a forced upgrade if nobody has done it first. Dates as of 31 October 2026, from each vendor's own page.
| Release | Kubernetes project end of life | Amazon EKS: end of standard / extended support | AKS end of life |
|---|---|---|---|
| 1.37 | 28 Oct 2027 | 1 Dec 2027 / 1 Dec 2028 | Oct 2027 |
| 1.36 | 28 Jun 2027 | 2 Aug 2027 / 2 Aug 2028 | Jun 2027 |
| 1.35 | 28 Feb 2027 | 27 Mar 2027 / 27 Mar 2028 | Mar 2027 |
| 1.34 | 27 Oct 2026 (ended) | 2 Dec 2026 / 2 Dec 2027 | Nov 2026 |
| 1.33 | 28 Jun 2026 (ended) | 29 Jul 2026 / 29 Jul 2027 | Jul 2026 (ended) |
| 1.32 | 28 Feb 2026 (ended) | 23 Mar 2026 / 23 Mar 2027 | Mar 2026 (ended) |
Sources: kubernetes.io/releases, the Amazon EKS Kubernetes version lifecycle page and the AKS supported versions page, all checked 31 October 2026. AKS gives 12 months for each GA release and offers extended cover only if long-term support is enabled. Google publishes standard and extended dates for GKE on its own release schedule. EKS extended support costs extra per cluster hour and is on by default.
Tiers 1 and 2 (escalation and proactive review for clusters your team runs) are on the Kubernetes support page.
EKS, AKS, GKE
EKS, AKS and GKE run the control plane for you, and for many teams that is all they need. It is not the same as a managed cluster, because the node, add-on and workload layers stay with you.
The API server and etcd, their availability and patching, and the control plane upgrade mechanism. Each provider's documentation defines the exact scope, and it differs between EKS, AKS and GKE and between their standard and fully managed modes.
On EKS, managed node groups, self-managed nodes, Fargate pods and hybrid nodes are not upgraded automatically when the control plane is (AWS documentation, checked 31 October 2026). Add-ons, ingress, certificates, backups, policy and every workload are yours on all three clouds.
EKS gives 14 months of standard support, then 12 months of extended support at an extra cost per cluster hour. AKS gives 12 months, with long-term support as an opt-in. At the end the provider upgrades the control plane on its own schedule, and your nodes do not follow.
Enough when platform engineers own the version calendar, a restore has been tested and workloads tolerate a node being replaced. Not enough when nobody owns upgrades, the cluster runs brokers that lose quorum on a careless drain, or you must run the same way on OpenShift, on premises and in two clouds.
Prefer to keep running the cluster and call for help when it breaks? Kubernetes support, Tiers 1 and 2
How an upgrade runs
Upgrades are most of the work in a managed cluster, and each step has a known way to fail. This is the sequence we follow and the checks behind it.
The control plane moves first, one minor version at a time. Kubelets may trail the API server by up to three minor versions, but the project warns that kubelets persistently three behind must be upgraded before the control plane moves again, and in-place minor kubelet upgrades are not supported, so we drain and replace nodes (Kubernetes version skew policy, checked 31 October 2026).
A removed API breaks at upgrade time, not at deploy time. We scan manifests, Helm releases and live objects against the target release and add the check to CI. The Kubernetes deprecation guide lists removals per release, for example flowcontrol.apiserver.k8s.io/v1beta3 in 1.32.
Operators, CSI drivers, CNI plugins and admission webhooks each have their own support matrix and are often the real blocker. A webhook must handle the new API versions, or use matchPolicy Equivalent, before the API server moves.
A percentage in a PodDisruptionBudget rounds up, so maxUnavailable of 50% on a three-member broker cluster allows two members down, which is a lost quorum, while minAvailable of 50% keeps two. We rehearse the drain on a clone and pause between nodes for the measured recovery time.
EKS allows an in-place minor upgrade to be rolled back within 7 days of completion; a cluster upgraded automatically at the end of extended support cannot be. We take a Velero backup before the control plane moves and record a rollback decision point for each step.
A cluster several minors behind needs several sequential upgrades, not one big change. The first deliverable is a minor-by-minor plan with timings from a rehearsal, an owner for each step and the window you approve.
A written assessment of upgrade blockers is also available on its own. Typical upgrade readiness assessment
Stateful workloads
Most Kubernetes incidents on messaging estates are not cluster outages. They are stateful workloads meeting platform defaults. These are recurring patterns from AceMQ's RabbitMQ, Redis and Kafka support work, and managed cluster operations covers them from the platform side.
An operator that cannot reconcile because an owned resource, such as a StatefulSet, was half deleted and now reports that it already exists. The cluster stays mid-change until the leftovers are removed in the right order.
Reclaim policy and PVC retention decide whether deleting a cluster deletes its data. Retain settings are not always honoured on cluster delete, so we check what is actually bound before any destructive change.
Scaling a broker StatefulSet to zero can leave pods in Terminating while the volume is still attached, which blocks the restart. The fix depends on whether the node and the volume attachment have both let go.
RabbitMQ pods that fail to boot in an IPv6-only cluster because Erlang's epmd name lookup returns nxdomain. The cluster, the DNS and the broker settings all have to agree on the address family.
A non-root securityContext, with runAsUser and fsGroup enforced by policy or by OpenShift's restricted settings, stops a container that expects to own its data directory. The volume ownership and the policy have to be fixed together.
Operator Helm charts that depend on cert-manager fail to install, or fail on the first certificate rotation, when cert-manager or its webhook is missing or not ready. The dependency is checked before the chart upgrade, not after.
The broker-side triage for each of these is on the support page, and the failure modes are written up in a post on messaging on Kubernetes. Messaging on Kubernetes: what breaks
Price drivers
AceMQ does not publish a price list for managed Kubernetes. A quote is built from these inputs, and the written quote returns within 1 hour of your request.
How many clusters you run, in which environments, and across how many clouds or sites. A production cluster and a development cluster are not priced alike.
Node count and the share of the cluster that is brokers, databases and caches, which need more hands-on work than stateless services.
From business hours to 24/7 on-call with the 15-minute Sev 1 response. Tell us which clusters are production.
At Tier 3 you pay your cloud provider for infrastructure and AceMQ for operations. At Tier 4 the infrastructure is in the AceMQ quote. A cluster several minors behind has its upgrade plan scoped in the quote.
Not a fit for
We would rather say so up front.
AceMQ is a specialist service under a contract, not a console where you click to provision a cluster. If you want pay-as-you-go clusters with no contract, the cloud provider's own service fits better.
Designing an internal developer platform, a multi-cluster architecture or a cloud migration is consulting work, set out on the Kubernetes consulting page. Once the platform exists, we can operate it.
A scratch cluster with no uptime target needs a current version and a calendar reminder, not a managed service. The service pays for itself where Kubernetes carries revenue, regulated data or stateful messaging.
Running several technologies? One contract can cover Kubernetes with RabbitMQ, Kafka and Redis. Kubernetes consulting and services
Escalation Path
Every tier reaches a senior Kubernetes engineer. There is no tier-1 triage layer to get through.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Typical engagements
Kubernetes support and stabilization work from AceMQ. Each card links to the full write-up: the cluster, what AceMQ diagnosed or changed, and the result.
Mid-Sized Distribution Company
A typical engagement for a company that wants to leave an Oracle Java SE subscription or avoid one: inventory every Java runtime, compare OpenJDK distributions against the estate, and write the migration plan.
JavaOpenJDK
Docker
KubernetesSaaS Platform Team
A typical engagement for Java services that restart with exit code 137 after a base image brings a newer JDK: the heap is not full, no OutOfMemoryError appears, and the memory that matters lives outside the heap.
JavaKubernetesDocker
Prometheus
Global Aviation Technology Provider
Troubleshooting cluster failover, partition handling, and quorum queue issues in a high-stakes aviation operational environment.
RabbitMQKubernetesQuorum QueuesPrometheus
GrafanaFortune 500 Software Company
Migration to supported RabbitMQ versions with managed services, standardization, compliance posture, and Tanzu commercial licensing.
RabbitMQTanzu RabbitMQ
AWSEKSKubernetesGlobal Telecom Leader
Resolving weekly RabbitMQ crashes, optimizing for 300,000+ connected devices, and architecting horizontal scaling strategy.
RabbitMQKubernetesQuorum QueuesPrometheusGrafanaEnterprise 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.
RabbitMQKubernetes
LinuxSupport options
AceMQ offers Kubernetes support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for clusters your team runs, proactive monitoring that finds sizing, probe and upgrade problems first, managed Kubernetes on your own infrastructure, and fully managed Kubernetes on AceMQ infrastructure. EKS, AKS, GKE, OpenShift and self-managed clusters are covered in all four, on the current Kubernetes release and the five end-of-life release lines before it.
You run it, we back you up
Best for: Platform teams that run Kubernetes themselves and need senior cover when a stateful workload breaks at 3am.
You run it, we watch it with you
Best for: Teams that want the rollout that wedges or the drain that loses quorum found in a review, not in production.
We run it in your cloud or data centre
Best for: Regulated estates that must keep clusters, and the data on them, inside their own boundary.
We host it and run it, as a service
Best for: Teams that want brokers, databases and caches on Kubernetes without running a platform team.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs Kubernetes day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for Kubernetes
Support is one part of what AceMQ does for Kubernetes. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
The cloud providers run the control plane. A managed Kubernetes service from AceMQ also covers the layers they leave to you: version upgrades and removed-API checks, node pool patching and replacement, ingress and DNS, certificate rotation, observability with on-call, Velero backup and restore tests, security patching and policy, and the operators for stateful workloads such as RabbitMQ, Redis and Kafka. It is delivered by AceMQ with partner Kubernetes specialists, on one contract.
Yes to both. Tier 3 runs in your AWS account, Azure subscription, Google Cloud project, data centre or OpenShift estate, using your access controls and change process, including air-gapped clusters. Rancher and RKE2, VMware Tanzu and self-managed kubeadm clusters are in scope too. Tier 4 is the alternative when you would rather not own the infrastructure at all.
AceMQ does, on a cadence agreed in the contract for patch releases and node images. Kubernetes ships a minor release about every four months, three a year recently (1.34 in August 2025, 1.35 in December 2025, 1.36 in April 2026, 1.37 in August 2026), so a cluster that stays supported upgrades two to three times a year. Each upgrade is rehearsed on a clone and run in a window you approve.
Yes. AceMQ works on Kubernetes in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Managed Kubernetes is quoted per scope, with no list price: the price depends on the number of environments and nodes, the SLA, whether AceMQ runs Kubernetes on your infrastructure (Tier 3) or on ours (Tier 4), and the access and change process you need. Request a quote and AceMQ replies within 1 hour.
Let's talk
Reactive cover, proactive reviews, or AceMQ running Kubernetes for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
Production incident right now?Email a Kubernetes Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
