K0smotron

k0smotron v2.1.0 is out. Alongside a batch of fixes and dependency bumps, this release closes a gap that’s been open for a while: in-place upgrades, now also available for worker nodes. Check the full changelog for everything included. This post focuses on the in-place upgrade story, where we came from and what changes now. In-place upgrades, before v2.1.0 k0smotron has supported in-place upgrades for control plane nodes for a while, through spec.updateStrategy: InPlace on K0sControlPlane. This is a standalone mechanism: the control plane controller detects a k0s version change, builds an autopilot Plan targeting the control plane nodes that require a k0s version update, and lets autopilot roll out the new k0s version without replacing the underlying machine. No CAPI involvement beyond the control plane controller itself. ...

k0smotron v2.0.0 is here. This is a big release: a new API version, new storage backends, Windows support, better operator internals, and more. The version bump to v2.0.0 is not arbitrary, it reflects the promotion of v1beta2 as the new resource storage version across all k0smotron API groups, a change that affects every existing k0smotron user and requires attention before upgrading. On top of that, the release includes a handful of bug fixes and small improvements. Check the changelog for the full list. We will cover the major features in detail in a series of posts coming soon. This post gives you the full picture. ...

With k0smotron, every workload cluster gets a Kubernetes control plane that runs as pods inside a management cluster. Hosted control planes (HCPs) become ordinary Kubernetes workloads: schedulable, patchable, killable like any other Deployment. The tradeoff is that the management cluster pays the bill. Ten HCPs cost almost nothing. A hundred is a different story. Storage backends, pod limits, watch delivery, and k0smotron reconciliation all start to matter at the same time, and the question is which one cracks first. ...

It’s been a while since our last k0smotron update, but the project has been evolving at full speed. Over the past few months, we’ve worked on strengthening k0smotron both as a standalone solution and as a first-class citizen within Cluster API. Along the way, we’ve also expanded k0smotron’s own API so it can support a wider range of use cases. One example is the new customUserData field, which gives you direct control over how your VMs are prepared to run k0s. This makes it possible to adapt cluster startup to very specific requirements. And this is only the beginning, support for Ignition as an alternative bootstrapping method is planned for the next minor release, further extending bootstrap configuration flexibility. ...