Client Overview

The customer is an enterprise running MuleSoft across dedicated Data Centre, Disaster Recovery and UAT Kubernetes clusters, processing approximately six million transactions a day.

Despite deployments of 20-plus pods, Sunfire discovered that only two or three pods were actually carrying the workload — the application was using Kubernetes pods like persistent virtual machines, creating memory hotspots that pushed nodes toward instability and OOMKill terminations.

Challenges Faced

• MuleSoft .jar workloads were repeatedly loaded onto a small subset of pods instead of being distributed across the cluster.
• With 20-plus pods available, the imbalance was not obvious until it started causing failures.
• Overloaded pods drove memory pressure that pushed nodes into degraded or NotReady states.
• Memory pressure could progress all the way to Kubernetes OOMKill, terminating workloads outright.
• Larger nodes would have treated the symptom, not the cause, adding cost without fixing the underlying instability.
• All of this was happening under a live load of roughly six million transactions a day.

Solutions Provided

• Analyzed the Kubernetes environment from both infrastructure and application-behavior perspectives, rather than assuming the platform was undersized.
• Traced the root cause to application .jar files being repeatedly loaded onto just two to three pods, not the full pod set.
• Recommended enforced Kubernetes resource requests and limits so no single workload could exhaust node memory.
• Recommended distributing application processing across a larger number of pods so the cluster's horizontal scaling could work as intended.
• Determined the fix belonged at the application layer rather than continued node growth, protecting the customer from a costly, ineffective scaling path.
• Documented findings and shared them directly with the application's ISV for architectural correction.

Outcomes

• The root cause was identified before further infrastructure spend was committed to a fix that would not have worked.
• A clear, actionable resource-governance and workload-distribution roadmap was delivered.
• The ISV was engaged directly on the underlying application design issue, with findings documented in a form it can act on.
• A diagnostic method was established for distinguishing infrastructure issues from application ones going forward.
• The customer now has a clearer basis for future capacity and cost decisions.