Run Kubernetes 1.20

KubeOne 1.2 is now general available. The latest release of the open source cluster lifecycle management tool focuses on community-driven improvements. Ongoing support for the latest Kubernetes version gives users access to the latest Kubernetes features and improvements.

Highlights of the release:

  • Docker (Dockershim) is deprecated (read more about this in the containerd section)
  • Volume Snapshot advances the application and cluster level backups
  • kubectl debug 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.

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)
  • Kubermatic 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:


Easily Define Your Static Worker Nodes via Terraform

Until now, you could not define Static Worker nodes only via the KubeOne configuration manifest. The Kubermatic community 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.

Kubermatic updated the AWS example Terraform config to show how to use this feature. Check out this link to learn more. And  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.

Attention Needed — Breaking Changes

Please check out the Attention Needed section in the changelog for more information, particularly highlighting 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.


Leave a Reply