We are proud to announce KubeOne 1.15!
This release makes cluster lifecycle management easier by introducing managed control planes on AWS, Azure, Google Cloud, and DigitalOcean. Teams can now create and remove control plane machines directly with KubeOne, without relying on a separate infrastructure tool. This release also keeps infrastructure credentials out of KubeVirt-hosted clusters and adds Kubernetes 1.37.
Release Highlights of KubeOne 1.15
Managed Control Planes Across Seven Infrastructure Providers
Previously, building a KubeOne cluster on a public cloud required two tools. Terraform created the control plane machines and the load balancer in front of the Kubernetes API, and then KubeOne installed Kubernetes on them. This meant maintaining two sets of state and managing two separate workflows.
With KubeOne 1.15, you can describe the control plane in the KubeOne configuration file (how many machines, what size, which zones), and kubeone apply creates the machines and the API load balancer automatically. When a cluster is retired, kubeone reset can now delete those machines and the load balancer too. You still need to provide the network, for which KubeOne continues to offer example Terraform configurations.
This brings the entire cluster lifecycle under one tool and configuration across seven providers: AWS, Azure, Google Cloud, DigitalOcean, Hetzner, OpenStack, and KubeVirt. If you run clusters on a hyperscaler and on European or self-hosted infrastructure, the workflow is the same on both, so moving a cluster from one to the other doesn’t mean rebuilding your pipeline. Short-lived clusters can be torn down without leftover machines or load balancers to clean up by hand.
Improved Security for KubeVirt Clusters
Previously, on KubeVirt, the components managing a cluster’s machines, storage, and load balancers ran inside the cluster itself, along with credentials for the underlying virtualization platform. Anyone allowed to read secrets in the cluster could take those credentials, which often had broad infrastructure permissions.
KubeOne 1.15 moves these components to the infrastructure side and gives each one only the permissions it needs. Clusters no longer store any infrastructure credentials, and several clusters can cleanly share the same infrastructure area. This follows the architecture already used by Kubermatic Kubernetes Platform. Existing clusters move over automatically the next time you run kubeone apply.
For security and compliance owners, this puts a real boundary between the clusters people use and the platform underneath them. A misconfigured permission or a compromised workload in one cluster no longer exposes the virtualization layer. The boundary matters most for organizations that run many clusters on one KubeVirt platform, including teams moving VM workloads off VMware.
Kubernetes 1.37 Support
KubeOne 1.15 supports Kubernetes 1.35, 1.36 and 1.37. The bundled networking, storage and cloud provider integrations have also been updated accordingly, including Cilium 1.20.
Enhanced Authentication Configuration
Clusters can now use Kubernetes’ structured authentication configuration, so the API server can trust several identity providers and audiences instead of one. It also supports checking and mapping token claims through rules and restricting anonymous access to selected endpoints.
Simplified Add-On Management
The new kubeone addons apply command allows you to install, update, and remove add-ons and Helm releases without modifying the control plane. This makes routine add-on changes easier and lower-risk.
Add-ons are now applied with Kubernetes server-side apply. This replaces a deprecated pruning mechanism and cleans up removed resources more reliably.
Add-on secrets such as the backup password can now go in the credentials file instead of the cluster configuration, and the backup schedule is configurable. Disruption budgets in several add-ons now protect their pods during node drains as intended. The Flatcar update operator is installed only on clusters that have Flatcar nodes.
Additional Improvements
KubeOne 1.15 also includes several improvements to everyday cluster operations:
- Worker Upgrade Retries: Failed static worker upgrades now retry only the affected worker.
- System Log Management: You can configure how much disk space system logs may use on each node.
- Cilium Certificate Monitoring: The Cilium add-on now detects expiring certificate authorities months in advance through its certificate job, helping prevent unexpected Hubble observability disruptions.
- Faster KubeOne UI: The KubeOne UI now loads faster.
Leaner Air-Gapped Mirrors and Dual-Stack on OpenStack
KubeOne 1.15 makes it easier to manage air-gapped environments by allowing users to limit mirrored cloud provider images to the providers they actually use.
OpenStack clusters also now support dual-stack networking with IPv4 and IPv6.
Breaking Changes and Action Required
KubeOne 1.15 introduces several changes that users should review before upgrading:
- Kubernetes 1.34 is no longer supported. Upgrade your clusters to 1.35 or newer before moving to KubeOne 1.15.
- KubeVirt clusters move their infrastructure components and storage driver on the next
kubeone apply. The migration is automatic; schedule that run as a maintenance step. - On clusters that have the unattended-upgrades add-on enabled but have no Flatcar nodes, the next
kubeone applyremoves the Flatcar update operator; delete its leftover cluster-wide permissions by hand. - The example Terraform configurations for OpenStack and for the Hetzner managed control plane renamed their cluster name variable to
cluster_name. Update your variable files. - Add-ons are applied with server-side apply, so KubeOne rather than
kubectlowns their fields in the cluster. - If the Cilium certificate job fails after the upgrade, rotate the Cilium certificate authority.
The release notes have the details for each item.
Deprecations
There are no deprecations in this release.
How to Upgrade
KubeOne 1.15 continues our focus on simplifying Kubernetes cluster operations across different infrastructure providers. We encourage all users to upgrade to KubeOne 1.15 and explore the new capabilities.
- Download KubeOne 1.15 from the GitHub release page.
- Follow the upgrade guide for upgrade instructions.
- Explore the KubeOne documentation for managed control plane setup for each provider.
- Check out the release on GitHub and give us a star!
If you run KubeOne on AWS, Azure, Google Cloud or DigitalOcean, build your next test cluster with a managed control plane and tell us on GitHub what’s missing.
Thank you to our community, customers, and contributors who continue to help us improve KubeOne.
