Michelin Deleted Its Second CNI: What 70-Plus Clusters With Zero Network Visibility Teach a Self-Hosted PaaS About Day One

"Before Cilium we had no visibility at all. Troubleshooting network problems was painful, and we had very few tools to help us do it."

That is Arnaud Pons, Container as a Service Product Architect at Michelin — the century-old tire manufacturer — describing his company's Kubernetes network in a CNCF case study published July 14, 2026. His team ran 70 to 80 production clusters on two different CNI plugins simultaneously, with almost no ability to see what traffic was doing on any of them. In spring 2025 they consolidated all of it onto Cilium: roughly two months, more than 500 applications, zero customer-impacting outages.

Here is the verdict up front for operators running a self-hosted PaaS on their own machines under Cluster API: your CNI decision is the closest thing your platform has to permanent, so make it once, deliberately, on day one. Michelin proves the migration is survivable — but also proves how much toil, blindness, and deferred security work you pay in the years before you get around to it. This post walks through how a fleet ends up with two CNIs, what the blindness concretely costs, how 70-plus clusters moved without an outage, and ends with a five-item day-one checklist so your fleet never enters the two-CNI state at all.

How you end up with two CNIs​

Nobody plans a dual-CNI fleet. Michelin's archaeology is instructive because it is so ordinary. In 2024 the CaaS team rebuilt the company platform as Michelin Kubernetes Services (MKS), replacing a vendor-based solution that had grown costly and constraining — a migration covered in an earlier CNCF case study. The rebuild fixed cluster lifecycle management. But it left the networking layer exactly as history had deposited it: one CNI plugin that predated the vendor-managed solution, and a second one that came bundled with it. Both survived the rebuild. Both kept running.

That is the general mechanism, and it applies well beyond tire companies. A CNI rides along with whatever installs the cluster — the vendor bundle, the distro default, the tutorial you followed on day one. And unlike almost every other cluster component, the CNI cannot be swapped underneath running workloads: changing it means draining and re-provisioning nodes, re-addressing pods, and re-validating every network policy. So nobody switches. The day-one default becomes the forever default by inertia, and every platform migration, vendor change, or team handoff deposits another layer. Michelin is unusual only in that it admits the end state out loud: two CNIs, no visibility, years of accumulated operational debt in the one layer everything else depends on.

What "no visibility at all" concretely costs​

Blindness sounds abstract until you itemize it. Michelin's case study names three concrete bills, and each one maps to a failure mode self-hosted platform teams will recognize.

First, troubleshooting without instruments. When a tenant workload cannot reach its backend, the diagnosis path on a CNI without flow telemetry is tcpdump on nodes, educated guesses about iptables chains, and correlating application logs against infrastructure you cannot observe. Pons calls this "painful" with "very few tools." For a platform team, every one of those incidents is toil multiplied across every cluster in the fleet — 70 to 80 of them, in Michelin's case.

Second, security requirements deferred for years. Michelin's security team needed to control which external services each namespace could reach, with rules defined by domain name rather than IP address so policies would survive infrastructure changes. The existing CNIs could not express that at all. A requirement that basic — this namespace may talk to this domain, nothing else — sat unaddressed until the consolidation, because the enforcement point for it is the CNI and the CNI was untouchable.

Third, reliability you cannot verify. The case study notes the team spent significant time firefighting networking problems they could not clearly observe. A failure you cannot see is a failure you cannot distinguish from application bugs, DNS issues, or cloud-provider weirdness — so every incident starts with a misdiagnosis tax before the real debugging begins.

Add those three together and "no visibility" stops sounding like a missing dashboard. It is a standing tax on every incident, every audit, and every security review the platform undergoes.

Why Cilium won the evaluation​

When the CaaS team evaluated CNI options in early 2025, it wrote down three requirements: robustness, observability, and support for DNS-based egress network policies. That short list is worth pausing on, because each item answers one of the bills above — reliability you can trust, instruments included by default, and the namespace-to-domain egress control the security team had waited years for.

Cilium won because it answered all three inside a single CNCF project instead of three separate tools. One project to operate instead of a CNI plus a bolted-on observability agent plus a separate egress proxy. The team also read the eBPF substrate as a generational shift rather than an implementation detail, and treated Cilium's Graduated status plus its adoption as the default CNI by major cloud providers as evidence of longevity — the exact risk a team operating infrastructure alone at 3 a.m. needs priced in. "Cilium matched all the criteria we had," Pons said. "We were seeing a lot of the community move to Cilium, and the fact that observability was included by default was really important for us."

Note what is absent from the criteria: raw throughput benchmarks. The sibling conversation about packets-per-second mattered less than whether the network could be seen and constrained. For a platform carrying 500 applications, observability and policy expressiveness were the binding constraints, not dataplane speed.

How 70-plus clusters moved with zero outages​

This is the part of the story that should change your estimate of CNI-migration risk. The migration began in spring 2025 and finished across the whole fleet in roughly two months — a live migration, executed cluster by cluster, with Cluster API managing the node-level changes inside Michelin's GitOps-driven infrastructure. No customers were impacted. "What impressed us most was how smooth the migration was," Pons said. "There was no outage at all, and because of that our customers had no idea the network change was even happening."

The mechanics are worth naming because they generalize. A live CNI migration works by moving one failure domain at a time: pick a cluster, roll its nodes through the new CNI via machine-level reconciliation (exactly what Cluster API's MachineDeployments already orchestrate for upgrades), validate workloads on the new dataplane, then move to the next cluster. During the transition there is necessarily a period where pods exist on both networks, which is why the per-cluster blast radius matters more than the per-pod choreography — a lesson confirmed by earlier community migrations, from SkyBet's documented dual-CNI transition to the Multus-based tooling built specifically for CNI-to-Cilium moves. Michelin's contribution is proving the pattern at fleet scale: 70-plus clusters is not 70-plus times the risk of one cluster when each cluster is an independent migration unit. It is the same risk, repeated with a runbook that gets better each time.

Michelin is not the only 2026 data point converging here. Zynga's March 2026 CNCF case study describes consolidating an even wider sprawl — AWS VPC CNI, kube-proxy, an Istio service mesh, plus separate observability and security tooling — into the same unified Cilium platform, again with Hubble visibility cited as a first-class motivation. Two different industries, two different starting sprawls, the same end state: one eBPF layer for networking, observability, and policy.

Life after: what the visibility actually bought​

Consolidation paid off in the exact currencies the evaluation predicted. The team integrated Cilium's flow logs into its existing monitoring tooling, so connection-level evidence now flows into the dashboards operators already watch. DNS-based egress policies rolled out across namespaces, closing the security requirement that had waited years. And the reliability ledger flipped: since completing the migration, Michelin reports no CNI-related failures or incidents across the fleet. "The biggest value for us is that Cilium simply works, and works well," Pons said. "With our previous CNIs, failures were painful and hard to resolve. Now we know that once Cilium is deployed, it will work."

To make the "after" concrete, here is what the two capabilities look like in practice on a consolidated fleet. First, the diagnosis that used to take tcpdump and guesswork becomes one query against Hubble's flow data:

hubble observe --namespace tenant-a --verdict DROPPED --last 100
# Aug  4 10:32:01 tenant-a/web-7f9c4 -> tenant-a/postgres-0
#   TCP Flags: SYN  DROPPED (Policy denied)

Second, the DNS-name egress rule Michelin's security team asked for is a single declarative policy — stable across IP changes, scoped per namespace:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: tenant-a-external-egress
  namespace: tenant-a
spec:
  endpointSelector:
    matchLabels:
      app: web
  egress:
  - toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system
        k8s:k8s-app: kube-dns
    toPorts:
    - ports:
      - port: "53"
        protocol: UDP
      rules:
        dns:
        - matchPattern: "*"
  - toFQDNs:
    - matchName: api.stripe.com
    - matchName: registry.internal.example.com

One detail deserves emphasis for platform teams with roadmap discipline: Michelin is now evaluating Cilium's Cluster Mesh and service-mesh capabilities deliberately, explicitly shaped by a previous experience deploying a service mesh that saw little internal adoption. Features get rolled out against concrete business needs, not because the platform now makes them available. Consolidation did not become an excuse for scope creep — a stance worth copying.

The day-one checklist for a Cluster-API fleet​

Michelin survived the migration, but the lesson is not "migrations are easy." It is that every item below is an order of magnitude cheaper before the first workload lands than after the fiftieth cluster exists. If you operate a Cluster-API fleet — or plan to — run this audit before your next cluster template freezes:

1. Exactly one CNI, declared in Git. The CNI choice lives in your ClusterClass and GitOps repo, not in whichever installer default happened to be current. If a second CNI cannot appear without a reviewed pull request, you cannot drift into Michelin's archaeology by accident.
2. Observability on by default, not as phase two. Hubble (or your CNI's equivalent flow telemetry) ships enabled from the first cluster, with flow logs wired into the monitoring you already run. "We will add visibility later" is how "no visibility at all" happens.
3. DNS-name egress available from day one. Your CNI must be able to express namespace X may reach domain Y before your security team asks — because the question is when, not if, and retrofitting the enforcement point is the expensive part.
4. A written CNI-migration runbook, even if you never use it. Cluster-by-cluster, nodes rolled through MachineDeployments, validated per cluster. Writing it down forces you to confirm the migration unit actually exists in your fleet topology.
5. A revisit trigger with a date on it. "Picked on day one" must not mean "never questioned again." Define what reopens the decision — a Graduated alternative, a requirement your CNI cannot express, a toil threshold — and calendar it. Michelin revisited after years of accumulation; a scheduled revisit costs a meeting, an accumulated one costs a two-month fleet migration.

None of these items is exotic. That is the point. Michelin's two-CNI state did not come from exotic mistakes either — it came from ordinary inertia applied to the one component nobody wanted to touch. A Cluster-API fleet standardized on a single observable CNI from the start does not avoid this state by being cleverer. It avoids it by writing the decision down before inertia gets a vote.

Michelin's story is a reminder that the cheapest infrastructure migration is the one your day-one choices make unnecessary. Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.