March was a deliberate build month for Cloudfleet. The engineering team spent it laying foundations for the much larger April release, and the cloud-native world spent a week of it in Amsterdam. Here’s what was happening on both fronts.
Building the runway for April
A lot of what closed in March is the kind of work that only becomes visible the moment the next round of features lands on top of it. Two big examples:
- Foundations for bring-your-own Hetzner networks. A Cloudfleet-managed Hetzner network was an implicit assumption baked into a lot of the cloud controller code. March was the month we untangled that assumption so April could ship the feature cleanly. If you’ve ever asked us “can we attach a Fleet to an existing Hetzner network we already manage,” the answer is about to become yes.
- Four new cloud provider integrations in pre-flight. Native instance and load balancing support for Upcloud, Exoscale, Scaleway, and OVH was in the final stages of validation throughout March, ahead of the private preview launches you’ll see in the April recap.
In parallel, the node auto-provisioner picked up a set of upstream improvements around disruption budgets and consolidation that will surface as user-facing controls in upcoming releases.
A debrief from KubeCon EU 2026
KubeCon + CloudNativeCon Europe ran in Amsterdam from March 23 to 26 this year. A few threads kept coming back, and they map cleanly onto what we hear from Cloudfleet customers.
AI workloads have officially moved into platform-team territory
Two years ago the AI track at KubeCon was niche. This year, it felt like every other talk had a GPU diagram somewhere in it. The interesting shift is that the conversation is no longer “how do we get a model to run on Kubernetes.” It’s “how do we run a fleet of inference services across mixed accelerator types in three different clouds without paying twice for capacity we’re not using.”
The CNCF’s own writeups echo this. Coverage like Solo.io’s recap and Virtualization Review’s final-day post both pull out the same point: AI infrastructure is becoming a platform engineering problem, not a data science problem.
This is exactly the wedge Cloudfleet was built for. Running a single Kubernetes cluster that spans GPU-rich providers alongside CPU-heavy hyperscaler regions, then scheduling workloads to whichever capacity is cheapest at the moment, used to be exotic. It is rapidly becoming table stakes for any team with a real AI bill.
FinOps is eating the cloud bill
The other dominant theme was cost. Not in the abstract “the cloud is expensive” way that dominated earlier years, but in a much more concrete way: teams now have FinOps practitioners involved in design reviews, and they want infrastructure that supports continuous optimization rather than periodic audits.
This pushes platforms toward two specific properties:
- Easy substitution between providers. If the right answer is “move this workload from cloud A to cloud B for the next quarter,” the infrastructure shouldn’t fight you. Multi-cloud as a cost lever, exactly as the State of Cloud Native 2026 report flagged.
- Aggressive bin-packing. Idle capacity is wasted spend. Node auto-provisioning, consolidation, and smart workload disruption budgets all become first-class concerns rather than nice-to-haves.
If you’ve been following our recent release notes, you’ll see we’re pulling on both threads.
Platform engineering is finally a normal job
The third theme was the one that felt least controversial: platform engineering is now a recognized discipline with its own conferences, certifications, and career paths. The relevant question for vendors like us is no longer “should we build a platform team” but “what does the platform team’s life look like, and what should we automate away from them?”
For Cloudfleet specifically, this is shaping our roadmap toward things like first-class CI/CD integration with workload identity, self-service Fleet configuration, and tighter Terraform support. The platform team should be running platforms, not babysitting infrastructure.
Upstream Kubernetes: the v1.36 release is right around the corner
Kubernetes v1.36 “Haru” is scheduled for late April. It continues the trend of formalizing dynamic resource allocation, hardening sidecar containers, and trimming legacy beta APIs that the community has been deprecating for years.
A note on our upgrade philosophy, because we get this question a lot. We deliberately do not jump to the newest Kubernetes minor the day it ships. We track every release as soon as it lands, build it through our internal validation pipeline, and watch how the early patch versions stabilize upstream. By the time a minor reaches Cloudfleet production clusters, the inevitable first-release fixes for kubelet edge cases, scheduler regressions, and API server changes have been published and rolled in. Patch versions land on a steady cadence so customers stay current on CVEs and bug fixes without being volunteered as the early-adopter cohort for upstream regressions.
Cloudfleet customers don’t need to do anything to prepare for 1.36; we manage these upgrades for you. If you’ve been holding onto deprecated API usage in your own controllers or operators, this is a good prompt to take a look.
Looking ahead
April is shaping up to be a notably more eventful month. The work that landed in March made room for it. We’ll cover the new cloud provider integrations, the Hetzner BYO network support, the kubectl reliability fixes, and the Kubernetes 1.36 upgrade in the next recap.
Until then, if you were at KubeCon Amsterdam and have thoughts on what we should be prioritizing, we’d genuinely like to hear them. Drop a note via Cloudfleet support or your account manager.
