Mercedes-Benz: A Fleet You Can Reason About
Mercedes-Benz Tech Innovation — the software subsidiary that builds and runs infrastructure for Mercedes-Benz AG — operates one of the largest documented on-premises Kubernetes footprints in the industry: roughly a thousand clusters, grown from a two-hundred-cluster Terraform estate that had become, in their own words, almost impossible to manage. This case is not about a flashy rewrite. It's about what happens when a large, serious enterprise decides that a pile of scripts — however clever — cannot be the thing standing between "we need a cluster" and "the cluster exists, correctly, forever." Every fact below is traced to a public source: the CNCF's case study on Mercedes-Benz, a Kubernetes Podcast episode with their product manager, an on-the-record InfoWorld interview, and their own KubeCon EU 2024 talk. Where the public record is thin or silent, this page says so rather than filling the gap.
Imagine a car company doesn't just build cars — it also has to build and maintain a thousand identical little workshops, each one needing the same tools, the same safety signs, and the same lightbulbs replaced on schedule. For a while, someone wrote down instructions for building a workshop and people followed them by hand — but by workshop number two hundred, nobody could remember which workshop had which version of which instructions, and a few had quietly drifted. So the company built a robot that reads one master blueprint and builds (and rebuilds, and repairs) every workshop from it automatically. Now "add workshop #847" is a form, not a favor from a tired engineer who remembers how the last one was wired.
The starting situation: outgrowing a script
☺ Like you're 10: They started with a helpful checklist for building one workshop. It worked great for a few workshops — and then stopped working at all once there were hundreds.
Mercedes-Benz Tech Innovation began experimenting with Kubernetes in 2015, the year after it was open-sourced, and the CNCF later recognised the scale of that bet: in April 2023 the company won the CNCF Top End User Award at KubeCon + CloudNativeCon Europe for its cloud-native adoption and open-source contributions. But the fleet grew faster than any one team's hand-tuned tooling could keep up with. Per the CNCF's published case study (February 2024), the company's early cluster-provisioning pipeline was a self-written Terraform setup — and by the time the fleet reached around 200 clusters on OpenStack, that pipeline had become, in the case study's own phrasing, "overly complex and almost impossible to manage." Every new cluster was a slightly different snowflake; nobody could confidently say what state any given cluster was actually in, and the tooling had no path to the multi-cloud future the company wanted (bringing AWS into the mix alongside their on-premises OpenStack data centers).
By the time Sabine Wolz, product manager for their monitoring/logging/database platform team, spoke on the Kubernetes Podcast from Google (episode 184), the fleet had grown past 900 clusters spread across data centers on three continents — all run on-premises, with operations staff based entirely in Germany providing 24/7 coverage with no offshore handoff. An InfoWorld interview with Peter Müller, a lead platform expert, put a sharper number on the growth: from 200 clusters managed by the old Terraform pipeline to nearly 1,000 today, alongside more than 6,000 Kubernetes nodes in production per the CNCF case study. This is not a toy number to compare against: InfoWorld's own framing noted it dwarfs even CERN's well-known ~210-cluster physics-computing footprint, and that only about 10% of organisations anywhere run more than 50 clusters at all.
"A Terraform module that provisions one cluster nicely is a script. A thousand clusters run from that same script, hand-invoked by whoever's on shift, isn't infrastructure — it's a thousand independent judgment calls waiting to disagree with each other. The problem was never Terraform; it's that nothing was continuously checking the result against a single source of truth."
The architecture decision: clusters as a reconciled fleet
☺ Like you're 10: Instead of a person following a checklist to build each workshop, they taught a robot to read one blueprint and build (and rebuild) every workshop itself.
The technology decision at the center of this case is Cluster API (CAPI) — the CNCF project, covered in this course's multi-cluster & fleet management lesson, that manages the entire lifecycle of Kubernetes clusters using Kubernetes' own declarative API machinery. According to the CNCF case study, Mercedes-Benz adopted Cluster API on OpenStack specifically to replace that unmanageable Terraform pipeline, alongside the OpenStack Cloud Controller Manager for load-balancer integration and Kubernetes NetworkPolicies for in-cluster network security. The shift matters structurally, not just cosmetically: a cluster stops being "the output of a script someone ran" and becomes a Cluster object that a controller running on a management ("hub") cluster continuously reconciles — exactly the pattern this course's GitOps lesson teaches for applications, applied one level down, to the infrastructure that hosts them.
The published, attributed payoff is concrete. Peter Müller told InfoWorld that the automation is now so thorough that adding 500 more clusters to the fleet would require adding roughly one more engineer — a statement about how declarative, reconciled infrastructure decouples headcount from cluster count. The CNCF case study reports that self-service cluster creation now completes in about 15 minutes, and that rolling upgrades became, in the case study's words, "100% faster" once the fleet moved onto continuously reconciled infrastructure instead of one-off scripted runs. A companion write-up on the Cluster API migration (a Cuemby blog post recapping the work) frames the same shift as enabling gradual, minimal-downtime upgrades across the whole fleet, plus a credible path to multi-cloud — because Cluster API's provider model (see multi-cluster for the CAPI/CAPA/CAPZ breakdown) means the same declarative Cluster object shape can, in principle, target AWS instead of only OpenStack.
| Before | After | Source |
|---|---|---|
| ~200 clusters, self-written Terraform | ~1,000 clusters, Cluster API on OpenStack | CNCF case study, Feb 2024 |
| Manual, script-driven cluster builds | ~15-minute self-service cluster creation | CNCF case study, Feb 2024 |
| One-off, risky upgrade runs | "100% faster" rolling upgrades via reconciliation | CNCF case study, Feb 2024 |
| Headcount scaling with cluster count | ~1 extra engineer per 500 more clusters | Peter Müller, via InfoWorld |
| 6,000+ nodes in production | Spread across data centers on 3 continents | CNCF case study; Kubernetes Podcast ep. 184 |
One caveat the company is upfront about: as of the CNCF case study, GitOps in the classic application-delivery sense — a controller like Argo CD or Flux continuously pulling application and add-on manifests from Git — was described as something Mercedes-Benz was exploring with FluxCD for deploying cluster add-ons (metrics exporters, custom controllers), while still relying on Ansible for parts of that job at the time of publication. That's an important nuance for this course: the best-documented, at-scale reconciliation win here is Cluster API reconciling infrastructure (the clusters themselves), which is precisely the "Application and Infrastructure" half of GitOps that the GitOps lesson insists you not skip. Whether the add-on layer runs on Flux, Argo CD, or a mix, the principle is identical: a controller inside the fleet pulling desired state and reconciling toward it, rather than a human (or a cron job) pushing changes and hoping.
Why declarative reconciliation matters at this scale
☺ Like you're 10: With three workshops, a person checking each one by memory is fine. With a thousand, only a tireless robot that never gets bored can actually keep them all matching the blueprint.
This is the crux the whole case teaches. At ten clusters, a skilled engineer really can hold "what should be running where" in their head, and a script that's run by hand, occasionally, mostly holds up. At a thousand clusters across three continents, that mental model is not just harder — it is categorically impossible. No human, and no batch script invoked on a schedule, can look at a thousand independent control planes and know, right now, which ones have drifted. This is exactly the "desired state vs. actual state" gap the GitOps lesson centers on: the four OpenGitOps principles — declarative, versioned, pulled automatically, continuously reconciled — aren't stylistic preferences at this scale. They're the only mechanism that scales sub-linearly with fleet size, because the thing doing the checking is software, not a person's attention span.
Concretely: a script run by a human answers the question "did this cluster get built correctly, once, at the moment I ran it?" A continuously reconciled fleet answers a completely different and much more valuable question: "is this cluster correct right now, and will it still be correct after someone fat-fingers a change at 2am?" Müller's own framing to InfoWorld captures this directly — he's on record saying that for his team, "managing Kubernetes is not hard," specifically because the platform team stays deeply, continuously involved rather than treating cluster creation as a one-time event. The reconciliation loop is what makes that sentence true at a thousand-cluster scale instead of only at ten.
A script answers "did I build this correctly once?" A reconciler answers "is this correct right now, continuously, forever?" Below roughly a few dozen clusters the difference is mostly theoretical. Past a few hundred, it's the only difference that matters — it's the reason Mercedes-Benz can credibly say adding 500 more clusters costs one more engineer, not five hundred more scripts to babysit.
Guardrails at fleet scale: a real policy trade-off
☺ Like you're 10: They tried one safety-checker, found it made every workshop annoyingly slow to open, and switched to a faster one built right into the blueprint-reader itself.
Reconciled infrastructure is only half the story; a thousand clusters also need identical guardrails, or — as this course's multi-cluster lesson puts it — the weakest cluster is where the breach happens. At KubeCon EU 2024, Mercedes-Benz engineers gave a talk (covered by InfoQ) on migrating away from the deprecated Pod Security Policies, securing more than 900 (per the CNCF case study, closer to 1,000) clusters in the process. Their first instinct was Kyverno, a policy engine this course covers in security & policy enforcement — but per InfoQ's write-up, they measured admission requests taking up to roughly 11 seconds under Kyverno in their environment, about 20 times slower than what they had before. Rather than accept that tax across a thousand clusters, they adopted native Kubernetes Validating Admission Policies (VAP), discovered while upgrading to Kubernetes 1.26, which evaluate Common Expression Language (CEL) rules against an in-memory abstract syntax tree without running an extra controller or webhook hop at all.
The nuance worth keeping is that VAP (at the version they adopted it) didn't yet support mutating admission — only validating — so they layered a custom controller to handle mutation, alongside VAP for validation. Their stated reasoning for needing mutation at all is blunt and quotable: per InfoQ, an engineer noted that "Kubernetes tends to have quite insecure defaults" — allowPrivilegeEscalation defaults to true, for instance — so a platform this size can't simply rely on developers remembering to set the safe value themselves; the platform has to mutate it in for them. This is a genuinely useful, honest data point for readers evaluating OPA Gatekeeper vs. Kyverno vs. built-in VAP: at enough scale, the performance profile of your policy engine is not an academic concern, it's an admission-latency tax multiplied by every request on every one of a thousand clusters.
The 11-second, 20x figure is Mercedes-Benz's own measurement in their own environment and policy set, reported at KubeCon EU 2024 and relayed by InfoQ — not a general benchmark of Kyverno everywhere. Kyverno has shipped performance work since, and plenty of platforms run it happily at real scale. The transferable lesson isn't "avoid Kyverno" — it's "measure your admission-control latency under your own policy set before you commit to it fleet-wide," because a fixable cost at ten clusters becomes an unfixable one at a thousand.
The organisational choices: five teams, not a hero
☺ Like you're 10: Instead of one exhausted expert who knows everything, they built five small crews, each owning one piece — and every application team runs its own stuff instead of waiting on a ticket.
The Kubernetes Podcast interview with Sabine Wolz is the clearest public account of how the organisation is actually structured, and it's a deliberate, small-teams design rather than a single central "platform team" trying to own everything. She described five dedicated platform teams: two providing Kubernetes-as-a-service itself, one covering logging, monitoring, and database-as-a-service (her own team), one dedicated to container security (notably the only one of the five that reaches for commercial tooling rather than open source), and one building "Golden Paths" — pre-packaged Helm charts aimed at satisfying IAM and compliance requirements out of the box, echoing this course's own platform-as-a-product / golden path framing almost exactly. InfoWorld separately reported the core Kubernetes-as-a-service team at around a dozen engineers — a strikingly small number to run infrastructure at this scale, and only credible because of the reconciliation and automation described above.
Two organisational principles run underneath the whole story. First, "you-build-it, you-run-it": application teams — several hundred of them — get their own dedicated clusters (typically production, staging, and development) through a largely automated, self-service request process, arriving within hours to minutes rather than the ticket-and-wait model this course calls Ticket Swamp. Second, Wolz described an explicit inner-source culture: teams share code and platform components internally the way an open-source project would, while keeping genuinely competitive boundaries where the business needs them. Neither principle is exotic on its own — this course teaches both under self-service & developer portals and team topologies — but seeing them actually hold together at nearly a thousand clusters, run entirely on-premises by an all-Germany, 24/7 operations staff, is the part of this case that's genuinely rare in the public record.
If Dot the Duck worked at an application team here, her experience per the public interviews is: file a self-service request, get a production/staging/dev cluster within hours to minutes, and pull a golden-path Helm chart off the shelf that already satisfies the compliance team. She never has to know there are 999 other clusters, or that a robot rebuilt a chunk of the fleet last Tuesday during an upgrade. That invisibility is the entire point of the org design, not an accident.
What actually changed — the numbers Mercedes-Benz has published
☺ Like you're 10: Here's the honest scoreboard — the numbers they've said out loud, not ones we made up to sound impressive.
Collecting every public, attributed figure in one place, because a case study you can't tie to a source is gossip, not evidence: the fleet grew from roughly 200 Terraform-managed clusters to roughly 1,000 clusters managed via Cluster API (CNCF case study, InfoWorld); the fleet runs 6,000+ Kubernetes nodes in production (CNCF case study) across data centers on three continents (Kubernetes Podcast ep. 184); self-service cluster creation takes about 15 minutes (CNCF case study); rolling upgrades became "100% faster" once reconciliation replaced one-off scripted runs (CNCF case study); adding 500 more clusters is estimated to need roughly one additional engineer given current automation (Peter Müller, via InfoWorld); the core Kubernetes-as-a-service team runs at roughly a dozen engineers (InfoWorld); admission-control latency under their initial Kyverno rollout ran up to ~11 seconds, about 20x their prior baseline, which motivated the move to native Validating Admission Policies (InfoQ, KubeCon EU 2024); and the company received the CNCF's Top End User Award in April 2023 for its cloud-native adoption (CNCF).
What's notably not in the public record, as far as this course's research turned up: a published cost figure for the migration, a hard SLA/incident-rate before-and-after comparison, or a definitive statement that FluxCD (or any GitOps engine) has since gone from "exploring" to "fully in production" for the add-on layer. Treat those as open questions, not settled facts — the CNCF case study is dated February 2024, and it's entirely plausible that has moved on since; this page reports what was published, not what may be true today.
What to steal for your own platform
☺ Like you're 10: Even if you'll never run a thousand workshops, some of their tricks work great with just three or four.
You don't need Mercedes-Benz's scale to benefit from its choices. First, treat cluster creation itself as a declarative, reconciled object — via Cluster API or an equivalent — the moment you have more than a handful of clusters, rather than waiting until your Terraform pipeline becomes "almost impossible to manage" the way theirs did; the pain is the same shape at 20 clusters as at 200, just quieter. Second, measure your policy engine's admission latency under your actual policy set before committing to it fleet-wide — Mercedes-Benz's Kyverno-to-VAP move is a concrete demonstration that "which policy engine" is a performance decision as much as a features decision, covered in depth in this course's security & policy lesson. Third, split platform ownership into small, named teams with clear scopes (Kubernetes-as-a-service, observability, security, golden paths) rather than one undifferentiated "platform team" — it's the same team-topologies thinking this course teaches, validated at genuinely large scale. Fourth, build the golden path as a packaged, compliance-satisfying default (their Helm-chart approach) so "secure by default" doesn't depend on every application team remembering the right YAML.
Compare this pattern against the other real-company files on the case studies hub: adidas & Zalando tell a similar self-service story from the retail side, while CERN shows what happens when the scale driver is scientific batch computing instead of a fleet of near-identical production clusters. The common thread across all of them, and the one this case makes unmissable, is that scale doesn't reward cleverness — it rewards boring, reconciled, auditable sameness.
On a throwaway machine, install clusterctl and initialize a local Cluster API management cluster (the Cluster API docs quickstart uses kind for exactly this). Declare a single workload Cluster object with a MachineDeployment, apply it, and watch Cluster API actually provision it — then change nothing by hand and bump the Kubernetes version field to trigger a rolling node replacement. That one small exercise is the mechanical core of what Mercedes-Benz scaled to a thousand clusters: infrastructure as a reconciled object, not a script's output.
Honest caveats: what doesn't transfer, and what the record doesn't say
☺ Like you're 10: This story is real, but don't copy it blindly — a car company's workshop problem isn't exactly your problem.
A few things matter before you treat this as a template. First, Mercedes-Benz's fleet is overwhelmingly on-premises, on OpenStack, across the company's own data centers — a materially different cost and control model than running everything on a public cloud, and the multi-cloud/AWS ambition described in the CNCF case study was, at time of publication, a stated direction rather than a completed migration. Second, the org design assumes real investment: five dedicated platform teams, an all-Germany 24/7 operations staff, and years of Kubernetes maturity dating back to 2015 — this is not a weekend refactor, and a smaller company copying the "five teams" org chart without the automation underneath it would likely just be reproducing headcount, not outcomes. Third, and most important for this course's honesty standard: several of the strongest numbers here (the 15-minute self-service figure, the "100% faster" upgrade claim, the one-engineer-per-500-clusters estimate) come from the company's own case study and interviews, not from an independent audit — they're genuine, attributed, public claims, but they are still self-reported, and this page treats them as such rather than as verified third-party benchmarks.
Finally, resist the temptation to read this case as "Mercedes-Benz uses GitOps," full stop. What's solidly documented is Cluster API reconciling infrastructure and native Kubernetes primitives (VAP) reconciling policy; what's documented as exploratory, as of the most recent public source, is Flux reconciling the application/add-on layer. That's a genuinely useful distinction for the exam and for your own platform: the reconciliation principle this course teaches in GitOps Workflows is bigger than any one tool, and Mercedes-Benz is the best public example of it applied to the infrastructure layer specifically — not proof that every layer of a huge fleet has to run through Argo CD or Flux to count.
Foxy: Two hundred clusters, one Terraform script, and it became "almost impossible to manage." That's the whole case file right there — what actually broke?
Benny: Nothing was checking the result, only running the steps. A script that builds a cluster correctly once says nothing about whether it's still correct next Tuesday.
Recon: BEEP. That's my job description, just one layer down from usual — I don't reconcile a Deployment, I reconcile the cluster itself. Same loop, bigger canvas.
Gizmo: A thousand clusters? Just SSH into whichever one's on fire and patch it live. Way faster than writing a policy! 🤑
Timmy: That's exactly how cluster #847 becomes the snowflake nobody can rebuild. They learned this the hard way with Kyverno too — measure the guardrail's cost before you ship it to all thousand.
Dot: Meanwhile some application team just filed a request and got a production cluster in twenty minutes. That's the only part I actually care about.
Read the reconciliation loop this case leans on in full in GitOps Workflows, see the fleet-management machinery — Cluster API, hub-and-spoke, fleet-wide policy — in Multi-Cluster & Fleet Management, and compare Argo CD against the add-on-layer direction Mercedes-Benz has said it's exploring. Then head back to the case studies hub for the rest of the evidence board.
1. What specifically broke about Mercedes-Benz's original Terraform-based cluster pipeline, per the CNCF case study? 2. Which CNCF project did they adopt to fix it, and what layer of the stack does it reconcile — infrastructure or application delivery? 3. Why did they move from Kyverno to native Validating Admission Policies, and what number did they cite? 4. Name two of the five platform teams Sabine Wolz described. 5. What claim in this case is explicitly still "exploring," not "in production," as of the most recent public source?
Check your answers
- Their self-written Terraform pipeline for provisioning clusters had become, in the case study's own words, "overly complex and almost impossible to manage" by around 200 clusters, with no credible path to multi-cloud.
- Cluster API (CAPI) — it reconciles the infrastructure layer (the clusters themselves), not the application/add-on layer that classic GitOps engines like Argo CD or Flux typically target.
- Kyverno's admission-request latency reached roughly 11 seconds in their environment — about 20x slower than their prior baseline — so they moved to CEL-based Validating Admission Policies, which evaluate in-memory without an extra controller hop.
- Any two of: two Kubernetes-as-a-service teams, one logging/monitoring/database-as-a-service team, one container security team (their only user of commercial tooling), one "Golden Paths" / Helm-chart / IAM-compliance team.
- Using GitOps engines like FluxCD to reconcile the cluster add-on layer — described in the CNCF case study as something being explored, with Ansible still handling parts of that job at time of publication.