Today, we are thrilled to announce general availability of KubeOne 1.2. The latest release of our open source cluster lifecycle management tool focuses on community-driven improvements and paves the way for upcoming releases that incorporate even more features. We have been adding quite some alpha-level features that will be improved and graduated in the near future.
Since we had to introduce a couple of breaking changes to improve the user experience, please carefully read the Attention Needed section below.
Run Kubernetes 1.20
Ongoing support for the latest Kubernetes version gives users access to the latest Kubernetes features and improvements. We’d like to highlight the following changes:
- Docker (Dockershim) is deprecated (read more about this in the containerd section)
- Volume Snapshot advances the application and cluster level backups
kubectldebug facilitates debugging any Kubernetes workflow- Exec Probe timeouts are now handled properly. Previously, Exec Probes had no timeout if it was not explicitly specified. With this release, all Exec Probes that don’t explicitly specify the timeout will have the default timeout of one second. So make sure to adjust your Exec Probes accordingly if you’re using those
- API Priority and Fairness (APF) allows the Kubernetes API server to categorize incoming requests by priority levels
Provision Your Clusters With Containerd
As of Kubernetes 1.20, Dockershim — a component that connects Kubelet and Docker, is deprecated. Starting with Kubernetes 1.23, it will not be possible to use Docker on Kubernetes nodes anymore. Instead, a Container Runtime Interface (CRI) compatible container runtime like containerd must be used.
Starting with this KubeOne release, you can provision clusters using containerd. We’ll also provide a migration path for existing clusters created by KubeOne in one of the upcoming releases.
Basically, there are two key things that you should know:
- KubeOne will install containerd by default on all freshly created clusters using Kubernetes 1.21+ (it’s possible to opt-out as long as Docker is still supported)
- We recommend using containerd for all newly created clusters regardless of the Kubernetes version. This will save you time from migrating to containerd once Docker support is removed. This can be easily done via KubeOne configuration manifest:
apiVersion: kubeone.io/v1beta1
kind: KubeOneCluster
...
containerRuntime:
containerd: {}
For more information about this change, please read the official announcement and FAQ.
Easily Define Your Static Worker Nodes via Terraform
Until now, you could not define Static Worker nodes only via the KubeOne configuration manifest. We got many requests to make it possible to source information about Static Workers from the Terraform state, just like for the control plane instances. With KubeOne 1.2, this is finally possible!
We’ve updated our AWS example Terraform config to show you how to use this feature. Check out this link to learn more.
Note that we highly recommend using Kubermatic machine-controller for managing worker nodes if your provider is officially supported.
Create Reliable and Secure Kubernetes Clusters With Amazon EKS-D
KubeOne 1.2 brings alpha-level support for the Amazon EKS Distribution (EKS-D). With EKS-D, you can rely on the same versions of Kubernetes and its dependencies deployed by Amazon EKS. This includes the latest upstream updates as well as extended security patching support.
You can learn more about how to use KubeOne to provision and maintain the EKS-D clusters in this demo or in this blog post.
Attention Needed — Breaking Changes
Stability and user experience are one of the most important values for us. We pay a lot of attention to ensuring that we don’t introduce breaking changes that would affect users. However, this time we had to introduce a couple of such changes to improve the user experience and pave the way for upcoming features.
Please check out the Attention Needed section in the changelog for more information. We would like to particularly highlight the following change.
kubeone reset will require explicit confirmation starting with KubeOne 1.3
kubeone reset is the most destructive command — it reverts everything done by other KubeOne commands. As such, users should be able to explicitly confirm that they want to run it on the provided instances. Starting with the next KubeOne release (1.3), the kubeone reset command will ask for explicit confirmation by typing yes. It will work in the same way as the kubeone apply command. It will output which instances will be affected, followed by the confirmation request.
If you’re using the kubeone reset command in scripts and want to automatically confirm it, you can use the auto-approve flag. The flag is already implemented in this release as a no-op flag, so you can already start modifying your scripts.
We hope you like the improvements brought by this release and are looking forward to further growing and improving this project. Feel free to share your ideas and thoughts via Github or Slack.
