Bottlerocket Killed Bare-Metal Kubernetes After 1.28: Picking a Node OS for Your CAPH Fleet

If your Cluster API fleet on owned Hetzner hardware still boots Bottlerocket's metal-k8s variants, here is the news in one sentence: the last bare-metal variant stopped receiving patches when Kubernetes 1.28 went end-of-life in October 2024, no metal-k8s-1.29 will ever exist, and the nodes you are running today have been unpatched for nearly two years.

That is not speculation. It is Bottlerocket issue #3794, where the maintainers state plainly that "bare metal variants for Kubernetes 1.29 and beyond will not be released," with maintenance of the existing metal-k8s-1.25 through metal-k8s-1.28 variants continuing only "until the respective Kubernetes versions reach end-of-life." Kubernetes 1.28 reached end-of-life on October 28, 2024. The maintenance window closed with it — while the main release train kept rolling on AWS-only work like aws-k8s-1.35 variants, EKS add-on port reservations, and NVIDIA kubelet templates.

So the question for anyone running Kubernetes on bare metal through Cluster API — the CAPH (Cluster API Provider Hetzner) crowd especially — is no longer "should we move off metal-k8s" but "which of the three surviving options do we standardize on: Talos Linux, Flatcar Container Linux, or Kairos?" This post gives you the decision up front, then the honest tradeoffs behind it.

***.

The decision table: Talos vs Flatcar vs Kairos for a CAPH fleet​

If you only read one section, read this one. All three are immutable, auto-updating, container-optimized operating systems. They differ in how much of a general-purpose Linux they let you keep — and that single axis drives almost everything else.

The spectrum, in short: Talos is the maximum paradigm shift with the strongest guarantees, Flatcar is the familiar end with the cheapest migration, and Kairos sits in the middle — immutability with an off-ramp to a real distro userland.

Why AWS exited bare metal — and why it matters for your upgrade cadence​

Bottlerocket was never really a general-purpose container OS. It is the node OS for EKS the way the EKS-optimized AMI is: variants are built per Kubernetes version per platform (aws-k8s-1.35, aws-ecs-2, and so on), and the release train follows EKS support windows. Recent releases tell the story — cgroup v2 defaults aligned with EKS 1.35 behavior, reserved EKS add-on ports, NVIDIA templates for EKS GPU node groups. Every investment lands on AWS.

Bare metal could never ride that cadence. A metal-k8s variant needs testing against hardware diversity AWS does not own, and its users upgrade on their own schedule, not Amazon's. So AWS did the rational thing: it stopped at 1.28 and kept the train moving for EKS, which is now shipping 1.35/1.36-era variants.

The lesson for a CAPH fleet is structural, not personal: your node OS must track your cluster's Kubernetes version, not a cloud vendor's support calendar. A self-hosted fleet on Hetzner upgrades when you decide — when the CAPI providers, the CNIs, and your tenant workloads are ready. Any OS whose release train answers to somebody else's managed-service windows will eventually strand you exactly the way metal-k8s did. All three contenders below pass this test, because none of them is a sidecar to a managed Kubernetes product.

The three contenders, honestly​

Talos Linux: the API-only purist​

Talos is the most opinionated option: there is no shell, no SSH, no package manager on the node at all. You manage machines through a gRPC API (talosctl), with declarative machine configuration, built-in etcd backup and restore, and atomic image-based upgrades. Sidero Labs calls it a second-generation container OS — where CoreOS and Flatcar hardened a general-purpose Linux, Talos deleted the general-purpose Linux.

The payoff is real: the smallest attack and drift surface of the three, and Kubernetes upgrades as a first-class OS operation rather than a kubeadm run against a mutable host. The 2026-era project is also expanding — native hypervisor capabilities and scheduling containers outside Kubernetes for edge sites, all managed through the same Omni fleet plane, showcased at TalosCon 2026.

The cost is equally real: you rebuild your operational tooling around the API. Debugging is talosctl logs, talosctl dmesg, and the API — never "just SSH in and look." If your team debugs nodes by shelling in, Talos will feel like handcuffs until the muscle memory changes. And Talos is Kubernetes-only: anything that is not a Kubernetes node does not belong on it.

Pick Talos if your fleet is Kubernetes and only Kubernetes, and you want the OS to enforce that. Skip it if your nodes carry non-K8s workloads or your on-call culture depends on SSH.

Flatcar Container Linux: the familiar workhorse​

Flatcar is the spiritual successor to CoreOS Container Linux: a minimal, immutable, auto-updating Linux with Ignition provisioning and update orchestration through the Flatcar update operator (the Nebraska-protocol lineage). It is SSH-able, it is a real Linux box under the immutable rootfs, and migrating from any traditional distro is cheap — the shape is familiar even though the update model is image-based.

Its great virtue for a CAPH fleet is neutrality. Flatcar is a standalone OS, not bundled with a Kubernetes distribution, so it pairs with whatever Cluster API bootstrap and whatever Kubernetes version your fleet runs. Commercial LTS editions exist (roughly 18 months of support versus the two-month stable cadence) if your fleet wants a slower OS train than upstream stable. And the CoreOS lineage means a decade of Ignition configs, PXE-boot recipes, and bare-metal war stories to borrow from.

The tradeoff: Flatcar does not track Kubernetes for you. The kubelet version, the container runtime pairing, and the K8s upgrade procedure are your fleet's job — the OS handles OS updates, not cluster upgrades. That is freedom if you have platform engineers, and toil if you do not.

Pick Flatcar if you have Ignition/CoreOS muscle memory, need SSH and a real userland on nodes, or run mixed workloads. Skip it if you want K8s-version tracking and cluster upgrades handled by the OS vendor.

Kairos: immutability with an off-ramp​

Kairos takes a different architectural bet: instead of shipping one minimal OS, it is a factory for building immutable, atomic-upgrading OS images on top of familiar distributions — openSUSE, Ubuntu, Debian flavors — with tooling like AuroraBoot and osbuilder to produce custom images from container definitions. Provisioning leans on cloud-init, upgrades are A/B atomic, and there is first-class thinking about edge scale-down (P2P mesh coordination) and a dedicated Cluster API provider.

The appeal is the middle of the spectrum: you get atomic upgrades and declarative provisioning while keeping the entire userland, package ecosystem, and debugging familiarity of your base distro. Teams that flinch at Talos's "no shell" rule but want stronger immutability guarantees than Flatcar's "hardened Linux box" find Kairos's bargain attractive.

The honest caveat is mileage. Kairos is the youngest of the three — an active 2026 project with regular planning and releases, but without Talos's K8s-only production base or Flatcar's CoreOS lineage. Evaluate the CAPI provider and the upgrade path on your actual Hetzner server types before committing the whole fleet.

Pick Kairos if you want atomic immutability without giving up a full distro userland, or you build custom node images from containers. Skip it if you need the longest production track record.

What to actually pick​

Map your fleet to a profile:

• Kubernetes-only fleet, platform team, want hands-off upgrades: Talos. The API-only model pays off fastest when every node is a K8s node and nobody needs a shell.
• Mixed workloads, CoreOS/Ignition history, SSH-dependent on-call: Flatcar. Cheapest migration, most familiar operations, you own the K8s pairing.
• Custom node images, distro userland required, edge or heterogeneous hardware: Kairos. The factory model earns its keep when one stock image does not fit all your machines.

One CAPH-specific note for the migration itself: your infrastructure provider must know your OS. Provisioning Talos means driving its gRPC API in maintenance mode; provisioning Flatcar means SSH plus Ignition; Kairos means cloud-init. Budget the bootstrap work, not just the image — the OS choice reshapes your machine controller path.

And if you are still on metal-k8s-1.28 today: you are not "one upgrade behind," you are on an OS line whose last patch predates Kubernetes 1.29. Treat the migration as overdue maintenance with a CVE clock attached, not a someday roadmap item. Inventory which pools still boot metal images, pick your successor from the table above, and roll one pool at a time.

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.

Sources​

• Bottlerocket issue #3794 — "No metal-k8s-1.29 variant for Bottlerocket" (maintainer statement ending bare-metal variants at 1.28): https://github.com/bottlerocket-os/bottlerocket/issues/3794
• Bottlerocket releases (v1.57.0-era: kubernetes-1.35 templates, EKS add-on ports): https://github.com/bottlerocket-os/bottlerocket/releases
• Kubernetes end-of-life schedule (1.28 EOL October 28, 2024): https://endoflife.date/kubernetes
• Talos Linux philosophy (API-only, no SSH, second-generation container OS): https://www.talos.dev/v1.7/learn-more/philosophy/
• Sidero Labs 2026 announcements (native hypervisor, edge containers, TalosCon 2026): https://www.siderolabs.com
• Flatcar Container Linux (CoreOS successor, Ignition, LTS editions): https://www.flatcar.org
• Kairos (immutable meta-distro, AuroraBoot, osbuilder): https://kairos.io
• Container OS spectrum analysis (Talos / Kairos / Flatcar positioning): https://podostack.com/p/talos-kubernetes-only-os-no-ssh
• Container-optimized Linux comparison (Flatcar, Bottlerocket, Talos, Fedora CoreOS): https://dev.to/matheus_releaserun/container-optimized-linux-distributions-compared-flatcar-bottlerocket-talos-and-fedora-coreos-4fj2