We promised April would be eventful, and it delivered. The platform work that landed quietly through January, February, and March made room for a busy release month: four new cloud providers in private preview, a long-requested networking option for Hetzner Kubernetes deployments, a reliability fix for self-managed nodes, and a fresh Kubernetes minor version. Here’s the tour.
Four new cloud providers, one cluster
On April 10, we rolled out native instance and load balancing auto-provisioning for Upcloud, Exoscale, Scaleway, and OVH. These are all in private preview right now. Reach out to your account manager or Cloudfleet support to get early access.
It’s worth pausing on what this actually unlocks, because “we support more clouds” undersells it.
Cloudfleet’s model has always been that a single cluster can span multiple clouds. Your workloads on AWS and Hetzner live in the same Kubernetes API, share a private network through our WireGuard-based mesh, and get scheduled by the same scheduler. Adding a cloud provider to that mesh isn’t just a new region to deploy into. It’s a new option for the node auto-provisioner to consider when it’s looking for the cheapest acceptable home for a pending pod.
Four new clouds at once is meaningful for two specific use cases:
- European data sovereignty without single-vendor lock-in. Upcloud (Finland), Exoscale (Switzerland), Scaleway (France), and OVH (France) are all EU-headquartered providers with EU data center footprints. For teams that already needed to be inside the EU and were quietly worried about depending on one cloud to get there, this is a meaningful diversification option.
- Better economic surface area for AI and bursty workloads. Different providers price GPU and high-memory instances very differently, and the prices change. Having more providers in the auto-provisioner’s candidate set means more chances to land on the right instance type at the right price at the moment you need it.
If you want to understand how this fits with the rest of the Fleet model, our docs have you covered.
Hetzner: bring your own network
On April 16, we shipped a feature that several Hetzner customers had been asking us for: instead of letting Cloudfleet create its own dedicated cfke-CLUSTER_ID-... network per region, you can now attach a Hetzner Cloud Fleet to a Hetzner Cloud network you already manage.
Why this matters:
- Coexistence with non-Kubernetes workloads. If you’ve already got managed databases, bastion hosts, or legacy VMs sitting in a Hetzner network, your cluster nodes can now join the same network and talk to them over private IP without a hop through the public internet.
- Your own topology, your own rules. Custom subnets, routes, and firewall policies are yours to manage. Cloudfleet stops trying to be the sole owner of that network and lives as a polite tenant inside it.
- A natural pairing with February’s network preservation fix. February’s work ensured we wouldn’t accidentally remove a Hetzner network that had customer VMs attached. April’s work is the other half of that story: full first-class support for customer-managed networks, not just defensive non-destruction.
This is opt-in for now and gated through Cloudfleet support. The Hetzner Cloud fleet configuration documentation has the details.
Kubectl is reliable again on re-added self-managed nodes
A smaller fix, but a really annoying one to live without. If you were running self-managed nodes and a node got removed and re-added to the cluster, kubelet-proxied commands like kubectl logs, kubectl exec, and kubectl port-forward could fail intermittently against that node. The root cause was the control plane resolving self-managed node addresses inconsistently after re-registration.
The April 22 fix gives address resolution a stable preference order. Re-added self-managed nodes now serve kubectl commands reliably, with no manual intervention required.
This is the kind of fix where the goal is for you to stop noticing the problem. If you were quietly working around it by avoiding node re-registration, you can stop now.
Kubernetes 1.36 “Haru” landed upstream
Right at the tail end of the month, on April 22, the Kubernetes release team shipped v1.36 “Haru”. Kubermatic has a friendly overview if you want a digestible read.
A few highlights that matter for Cloudfleet customers:
- Continued maturation of Dynamic Resource Allocation. DRA went stable in 1.33 and 1.36 keeps refining the surrounding API surface for things like structured parameters and partitionable devices. If you’re running GPUs at any meaningful scale, the long-term path is DRA, and 1.36 keeps it on rails.
- More cleanup of legacy beta APIs. A handful of beta APIs that the community has been deprecating for years are now removed. We’re validating this against our Pro cluster customers’ workloads as part of the upgrade rollout. If you’ve been using deprecated APIs and want to know whether you’re affected, the Kubernetes deprecated API migration guide is the canonical reference.
- Improvements to scheduling and admission performance. Less visible at small scale, but meaningful for the larger multi-tenant clusters we operate behind the scenes.
As always, Cloudfleet manages the upgrade for you. Pro clusters will pick up 1.36 on the usual cadence once we’ve validated it across our test matrix. There’s nothing you need to do to prepare beyond making sure your own controllers and operators are using the current API versions.
And looking ahead to May
May is shaping up to be an even busier month. A few things on our near-term roadmap that we’re aiming to land, though as always with software, dates and scope can move:
- Fleet constraints, static capacity, and auto-provisioning profiles to give you finer control over how the auto-provisioner picks and consolidates nodes.
- Native CI/CD integration with GitHub Actions and GitLab over OIDC, so workflows can authenticate to your clusters without long-lived API tokens or kubeconfigs in your repos.
- Publicly signed TLS certificates on the control plane endpoint, removing the need for
kubectlto trust an embedded private CA bundle. - A first-party support ticketing system to replace the embedded third-party form.
We’ll cover whatever actually ships in the May recap. See you in a month.
