Kubernetes Consulting and Implementation Services for Enterprises

The Kubernetes project maintains the three newest minor releases, with about one year of patches each. As of 19 October 2026 those are 1.35, 1.36 and 1.37, and 1.34 reaches end of life on 27 October 2026. AceMQ supports the current release and the five end-of-life release lines before it, and plans each upgrade ahead of its date, including the deprecated API removals that block it.

A named AceMQ senior engineer joins a live bridge within 15 minutes, 24/7, when production on Kubernetes is down, with kubectl access to diagnose. Lower severities get a first response within 1 hour, 4 hours or the next business day. The engineer who takes the call stays on the case, and every P1 ends in a written root-cause analysis.

An AceMQ Kubernetes engagement starts with a free consultation with a senior engineer, booked in our reply within 1 hour. A cluster assessment of 1 to 2 weeks follows, covering node pools, requests and limits, storage classes, network policy, ingress, RBAC and deprecated APIs. Written findings arrive within a week, before anything in your cluster changes.

Yes. A named senior engineer works with your platform team, changing manifests, Helm values and operator settings together, one namespace at a time so every step can be rolled back. You keep the runbooks for node failure, upgrade and rollback when the work is done.

Usually because the storage class, reclaim policy or PodDisruptionBudget was never checked against how the workload fails. A drain can take a second member of a three-member cluster down while the first is still restarting, and a deleted StatefulSet can take its volumes with it. AceMQ reviews budgets, anti-affinity, volume claim templates and drain runbooks.

Kubernetes only waits for the readiness probe. If the probe checks that a port is open rather than that the service works, a broken release passes, and Kubernetes does not roll back a stalled Deployment by itself. AceMQ adds dependency-aware probes, startup probes, maxUnavailable at 0, a rehearsed rollout undo, and Argo Rollouts or Flagger to abort automatically.

Yes, and it is the largest part of AceMQ's Kubernetes work. We deploy RabbitMQ with the Cluster Operator and Kafka with Strimzi, and set storage, anti-affinity, disruption budgets and rolling-upgrade order, because brokers fail on Kubernetes in ways stateless services do not. Redis and ActiveMQ Artemis on Kubernetes are covered too.

A managed service fits most teams, and self-managed fits air-gapped sites and custom control planes. Either way, probes, quotas, storage and stateful middleware stay yours. AceMQ supports EKS, AKS, GKE, OpenShift, Rancher and self-managed clusters, so the recommendation follows your constraints rather than a preferred platform.

Red Hat publishes dates for each 4.x release. As of 4 November 2026, OpenShift 4.22 has full support to 31 December 2026, maintenance to 31 December 2027 and Extended Update Support to 30 June 2028, with a second term to 30 June 2029. Red Hat's policy for 5.x gives each minor release 12 months of full support and 12 months of maintenance, with an optional Extended Life Cycle for every third minor release from 5.2. Extended Update Support is a 4.x term. AceMQ plans upgrades against the dates for the release you run and does not provide Red Hat subscriptions or patches.

AceMQ offers Tier 3 managed operations inside your own OpenShift estate, including air-gapped clusters, using your access controls and change process, delivered by AceMQ engineers with partner OpenShift specialists. On ROSA and ARO, Red Hat and the cloud provider operate the cluster platform, so AceMQ's work is upgrade planning, operators and the workloads on top. Red Hat, AWS and Microsoft subscriptions stay with them, and AceMQ is not a partner of any of the three.

A written assessment first, then cluster and landing-zone design, migration of workloads onto Kubernetes or between EKS, AKS, GKE and OpenShift, upgrade planning, CI/CD and GitOps, security, and stateful workloads such as RabbitMQ, Kafka, Redis and PostgreSQL. AceMQ engineers work in your cloud account with your platform team, and can work with an existing cluster rather than starting from scratch. Running the platform afterwards is a separate managed service, quoted per estate.

One minor version at a time, because Kubernetes documents skipping minor versions as unsupported. Before each step, check manifests and Helm charts for removed APIs and confirm operator and add-on compatibility, then upgrade the control plane and drain and upgrade the nodes. On EKS, staying past the 14-month standard window moves a cluster onto extended support at $0.60 per cluster-hour instead of $0.10 (AWS, 31 October 2026).

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 partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.

Every AceMQ proposal is tailored to your requirements: your Kubernetes environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Kubernetes is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.