How Mercedes‑Benz Scaled Kubernetes with Cluster API: A Cloud‑Native Case Study

Business Challenge

Mercedes‑Benz, one of the world’s leading automotive manufacturers, needed a scalable Kubernetes management solution for its rapidly growing on‑premise OpenStack‑based clusters. Their custom Terraform pipelines became overly complex and hard to maintain, and they required a strategy that would also support multi‑cloud deployments such as AWS.

Solution

After evaluating several options, the team adopted Cluster API , a Kubernetes project that provides a declarative API for provisioning and managing clusters. Cluster API allowed the platform engineers to manage clusters using Kubernetes itself, offering a consistent experience across clouds and reducing the number of tools required.

Key benefits included the use of reconciliation loops that replaced the previous Terraform‑based lifecycle, providing continuous visibility into infrastructure state and eliminating manual drift. Rolling upgrades could be triggered with a single action, dramatically shortening deployment time and minimizing downtime.

“Thanks to Cluster API, rolling upgrades are smoother and, thanks to continuous reconciliation, the process can resume immediately once a pod becomes ready, reducing downtime and upgrade failures.” – Tobias Giese, Software Engineer, Mercedes‑Benz Tech Innovation GmbH

The team also leveraged the pluggable Cluster API cloud provider to add new public clouds quickly, and the open‑source nature of the project enabled them to contribute back to the CNCF community.

Self‑Service Philosophy

Mercedes‑Benz Tech Innovation follows a “self‑service for everything” approach, exposing resources via APIs and UI so users can manage load balancers, firewalls, and network policies without direct operator intervention. A custom API and user‑friendly interface were built to let users manage their own clusters.

Enterprise Benefits

Adopting Cluster API transformed the platform: special‑case handling was eliminated, deployment times were reduced, rolling upgrades became routine, new clouds could be onboarded rapidly, infrastructure was standardized, and the team could focus on core business while leveraging open‑source contributions.

Future plans include using the Cluster API Runtime SDK to extend management capabilities, exploring GitOps with FluxCD for deploying auxiliary components, and building a custom cluster controller to handle metadata and pre‑creation infrastructure, further improving flexibility and stability.