Kubermates announced that KubeOne 1.3 is generally available. The previous release paved the way for a lot of new features and this time the developers are excited to present those features to you. KubeOne 1.3 brings a brand new Addons API, managed support for encryption providers, automated Docker to containerd migration, and much more! Here are the major highlights of this release:
Enhanced addons experience
KubeOne Addons was introduced back in the KubeOne 0.11 release, which offered an easy-to-use mechanism for deploying various additional components to improve the user experience. It did, however, require you to provide the YAML manifests along with the KubeOneCluster manifest, even if you used the addons we provided.
The developers heard your feedback and they’re introducing several improvements with this release, including the new Addons API. Now, all of the addons that they provide (e.g., cluster-autoscaler) are embedded in the KubeOne binary. If you want to use any of these addons, you can just request them in the KubeOneCluster manifest using the Addons API.
In addition, all existing Go structs used for deploying the core components, like the machine-controller, have been replaced with YAML-based Addons. If you want to change any component they deploy, all you have to do is put the appropriate manifest in your addons directory. There’s no need to change anything in code or recompile KubeOne.
Find out more about the new API along with how to use all the latest features in Kubermatic Addons guide.
Improved security with managed support for encryption providers
Kubernetes Encryption Providers allow you to encrypt your data at rest. This means that selected resources will be stored in an encrypted form in etcd. KubeOne 1.3 provides managed support for Encryption Providers for the following operations:
- Enabling/disabling Encryption Providers
- Generating and rotating encryption keys
- Using custom Encryption Providers configurations
- Using KMS-based Encryption Providers
Enabling Encryption Providers based on AESCBC for all Secret objects in the cluster is as easy as using the following KubeOneCluster manifest and running `kubeone apply`:
```yaml apiVersion: kubeone.io/v1beta1 kind: KubeOneCluster versions: kubernetes: '1.22.1' features: encryptionProviders: enable: true ```
Check out Encryption Providers docs for more advanced use cases, such as how to use a custom configuration file, as well as information on KMS-based providers.
Automatically migrate your clusters to containerd
The Kubernetes 1.20 release deprecated support for Docker (dockershim) as an underlying container runtime. With the upcoming Kubernetes 1.23 release, the support for Docker as a container runtime will be entirely removed. Instead, a container runtime compatible with Container Runtime Interface (CRI), such as containerd, is required. This means that you can still use Docker in your development workflow, but a CRI-compatible container runtime must be used on Kubernetes nodes.
That’s why the developers introduced containerd support in the latest 1.2 release. Now you can migrate your remaining clusters running Docker to containerd by running a single command. In addition, containerd is now supported on Flatcar Linux with this release, so you can provision Flatcar Linux clusters running containerd, or migrate your existing clusters. To learn more about this feature, we recommend checking out the migration guide.
Optimize your workloads with advanced AWS spot instances support
For power users that really scale-out, cloud works really well. Costs on the other hand are a significant topic when it comes to optimization. So the developers integrated advanced AWS Spot Instances support to configure not only the Spot Instances themselves but the amount the user is willing to pay for them as well. In combination with the unique machine controller, the rescheduling of nodes is completed without interruptions. For more sensitive workloads, KubeOne can run machine deployments with Spot Instances and reserved Instances side by side in a single cluster.
Improved support for OpenStack, vSphere, and Hetzner
The new release brings many improvements to OpenStack, vSphere, and Hetzner. The developers are now automatically deploying a CSI driver for all three providers, so you can use cloud provider-backed volumes. In addition, the external cloud controller managers (CCMs) have been updated to their latest versions for all supported providers to include the most current bug fixes and improvements.
The developers also implemented a CCM/CSI migration for OpenStack and vSphere clusters to answer the in-tree cloud providers’ deprecation. Originally, the controllers responsible for connecting your clusters to the cloud provider were integrated directly into Kubernetes. Those controllers are now considered deprecated and replaced by external cloud controller managers (CCMs) and CSI drivers.
If you still have OpenStack or vSphere clusters using in-tree cloud providers, you can now easily migrate them using just a single KubeOne command.
Cover highly complex use cases with our empowered KubeOneCluster API
In addition to the Addons API, the KubeOneCluster API has improvements to better support advanced and enterprise use cases. You can now provide a custom CA bundle that can be used by the control plane components, including CCM, CSI, and machine-controller. This is a very important feature for OpenStack and vSphere clusters if your setup uses a custom CA, which is not trusted by operating systems out of the box.
There are also new options for configuring kube-proxy. You can choose between running it in the iptables mode, which is the default, or in the IPVS mode. Running kube-proxy in the IPVS mode offers some additional options, such as enabling strict ARP, choosing a scheduler, or configuring timeouts. You’ll find some of those options useful, especially if you’re a MetalLB user or want to utilize better scalability of IPVS.
Kubernetes support policy changes
The latest Kubernetes 1.22 is supported with this release, so you can enjoy all of the newest features and improvements. Kubernetes has deprecated many old APIs in Kubernetes 1.22, so the developers had to change the minimum supported Kubernetes version to 1.19. If you have any clusters running Kubernetes 1.18 or older, make sure to upgrade to 1.19 using an older KubeOne release before upgrading to KubeOne 1.3. The Compatibility document includes a list of supported Kubernetes versions for each KubeOne release.
The new release introduces/includes so many other features, so we recommend checking out the entire changelog. If you’re an existing user upgrading to KubeOne 1.3, please pay additional attention to the “Attention Needed” part before upgrading.