Kubernetes 1.16 Arrives with Custom Resource Definitions, Dual IPv4/IPv6 Support

The latest release of Kubernetes, version 1.16, has officially landed.

“For this release, the overall theme was one of easing the creation and long term management of APIs hosted within Kubernetes,” wrote Red Hat engineers David Eads and Stefan Schimanski, in a blog post announcing the release. Anyone that has grown to depend on Kubernetes, especially enterprise users, will find that theme to crucial for long-term usage and massive deployments.

Although there are plenty of exciting features to be found in Kubernetes 1.16, it is widely accepted that CRDs (Custom Resource Definitions), now released under general availability, will offer the biggest improvement for the development and deployment of applications and services.

What are CRDs?

CRDs were introduced into the upstream version of Kubernetes (version 1.7) as a future-proof implementation of what was originally started as ThirdPartyResources. This feature quickly became central to Kubernetes API extensions, as it brought an unheard-of level of data consistency to the platform. With the help of CRDs, data:

• Follows a well-known schema.
• Is strictly typed.
• Only contains values that were intended by the developers.

According to the Red Hat engineers, “CRDs have been fully supported in Red Hat OpenShift for several releases, but developing OpenShift 4 as an automated platform built on Operators gave us the chance to find the remaining gaps first hand.” So borrowing a bit of technology that has become central to the evolution of OpenShit, Red Hat was able to migrate CRDs to Kubernetes. As the Operator APIs evolved, Red Hat was able to turn their attention to the functionality missing from the current state and bring CRDs to General Availability (GA) as a solid basis for any API. “We’ve focused on allowing API evolution over time with features like pruning and structural schemas, and added them back to the upstream project.”

But because APIs are never perfect, Red Hat made it possible for CRD authors to express intent via an enforceable OpenAPI Specification. With this spec, a cluster can self-document how any given API can work for the developer or admin.

According to Lachlan Evenson, Kubernetes release lead, “As we transition to GA, the focus is on data consistency for API clients. The combination of these, along with CRD conversion mechanisms are enough to build stable APIs that evolve over time, the same way that native Kubernetes resources have changed without breaking backward-compatibility.”

Another really smart feature for CRDs is Defaulting. Effectively, what Defaulting means is that unspecified fields in a manifest will always be automatically set to default values by the kube-apiserver. For example, if an admin forgets to set pod.spec.restartPolicy, the API server will know to set it to the default value of “always.” This can make a big difference when creating manifests and you fail to set a necessary value. With Defaulting in place, you know those required fields will always be automatically defined.

Other Enhancements in Kubernetes 1.16

CRDs aren’t the only enhancement to Kubernetes that should excite enterprise businesses. According to Lachlan, there are four features which 1.16 have enabled. These features are still in development but offer some exciting possibilities for large businesses.

• Windows container workload identity: Support for Active Directory Group Managed Service Account (GMSA) has now graduated to beta. The GSMA is a type of AD account that allows Windows containers to communicate to other resources across a network.
• RunAsUserName: This has reached alpha and is a string specifying the windows identity (in Windows) to run the entry point of a container. This is part of the newly introduced windowsOptions component.
• Improvements to setup and node join with kubeadm: There is now alpha support for kubeadm to enable Kubernetes users to easily join Windows worker nodes to an existing cluster (in the same manner found in Linux).
• Container Storage Interface (CSI) is now in alpha support: This introduces CSI plugin support for out-of-tree providers, which will enable Windows nodes in a Kubernetes cluster, to leverage persistent storage for Windows-based workloads.

Kubernetes 1.16 will introduce two new enhancements that improves scalability. These features are:

• Endpoint slices will play a big role in network routing. Each network endpoint is tracked within endpoint slices to help kube-proxy generate proxy rules to allow pods to better communicate with Kubernetes.
• IPv4/IPv6 dual-stack enables the allocation of both IPv4 and IPv6 addresses to Pods and Services. This means clusters will be able to access larger blocks of IP addresses.

Kubectl

For some time, the idea of splitting kubectl out of the main Kubernetes repository was discussed. Why? According to Eads and Shimanski, kubectl independence would allow faster iteration and shorter release cycles. This was no easy feat. In fact, several Red Hat engineers were involved in the effort and many hurdles presented themselves. However, with the release of Kubernetes 1.16, kubectl is now being published into its own repository.

Other Improvements

There are many other new features and improvements that have found their way into Kubernetes. This list includes the likes of:

• Feature parity between Container Storage Interface (CSI) and in-tree drivers.
• Improved stability of CSI sidecars (a set of standard containers that aim to simplify the development and deployment of CSI Drivers on Kubernetes).
• Volume cloning will allow users to create volumes from existing sources.
• CSI volume expansion is now set as the default.
• Raw block support improvement.
• etcdv3 is now the default controller.
• Direct dependency on a single container runtime has been removed, so users can now work with runtimes other than Docker (such as rkt or CRI-O).
• Role-Based Access Control (RBAC) is now in beta.
• Automatic provisioning of StorageClass objects means the automated volume provisioning is now created by Kubernetes.
• DaemonSet (which allow you to specify nodes to run a particular set of containers) now allows you to perform a rolling update.
• A new beta feature allows you to have multiple schedulers, each controlling a different set of pods.
• You can now set stubDomains, which define the nameserver(s) used for specific domains.

As you can see, Kubernetes 1.16 has a lot to offer. In order to enjoy these new features, make sure you upgrade to the latest iteration as soon as your company will allow. For even more detail on the new enhancements, make sure to give the official changelog a read.

Red Hat is a sponsor of The New Stack.

Feature image by Youssef Jheir from Pixabay.