Kubernetes 1.16 is out with new and stabilized features. There are several Kubernetes Special Interest Groups (SIGs) that have stepped up to deliver some critical functionality that users have been wanting. In addition, one of the most crucial extensions of Kubernetes is landing as stable and generally available with this release. Making Kubernetes an extensible platform allows it to be tailored for almost anything imaginable.
This release also deprecates several commonly used APIs, which might affect your cluster upgrade plans. Take a moment to review the community’s guidance on how to migrate to the current APIs. Now, let’s dive in to what’s new in Kubernetes 1.16.
CRDs
Custom Resource Definitions have been a part of Kubernetes before many governing processes were in place, including Kubernetes Enhancement Proposals, or KEPs. The CustomResourceDefinition has seen the long haul (#95), but it’s now implemented for general availability as a stable feature. It is one of the most extensible features of Kubernetes—it allows the impossible to become a reality. Kubernetes distributions, backup and recovery technologies, are just a few examples of applications that can use CRDs in some way. CRDs let custom resources be defined with a name and schema that a developer specifies. The Kubernetes API takes over and handles the custom resource so a custom API server doesn’t have to be implemented.
Other Custom Resource components that are moving to stable are the CRD OpenAPI Schema, Webhook Conversion for Custom Resources, Pruning for Custom Resources, and Subresources for Custom Resources. Each of these play a role in making Custom Resources standardized, mutable, secure, and even more extensible. The advancement of these features to stable lays the groundwork for more projects to leverage the Kubernetes API as a common language to define application resources.
Storage
It’s 2019—are we still talking about storage? Yes! The value of Kubernetes is more than just knowing how to run a scalable number of stateless apps. Being able to run both traditional and cloud native applications is what makes Kubernetes appealing to every organization out there. Take PostgreSQL as an example. PostgreSQL isn’t a cloud native app, but it can be repackaged into a container and gain all the benefits from Kubernetes as a stateful application. Going forward, no new storage plugins will be added in-tree, which means many new storage features will only be available through Container Storage Interface (CSI). SIG Storage aims to deprecate the code associated with in-tree storage plugins in future Kubernetes releases.
Swiftly off the heels of making its alpha debut in 1.15, PVC Cloning moves to beta in 1.16. The feature will duplicate an existing Kubernetes volume that can be used as though it were a standard volume. PVC Cloning happens during provisioning and requires the back-end device to create an exact duplicate of the volume.
It might seem trivial, but when a PV is created, there has been no way to programmatically resize the volume. This is a crucial use case when volume sizes are underestimated and thin provisioning isn’t available. With 1.16, resizing support is moving to beta for CSI volumes. So don’t worry if you forgot to put an extra zero in your volume size requirement.
Inline CSI volumes, graduates to beta in 1.16. Ephemeral volumes can now be mounted to inject configurations, secrets, or variables within pods.
Lastly, support for CSI drivers for Windows containers is now alpha in 1.16. This is big news for Windows users that are looking at implementing enterprise-class storage in their environment.
Networking
Connecting the dots of how our applications communicate with each other and the outside world is a crucial part of operating Kubernetes. There are overlay networks that satisfy inter-pod communication while services interact with load balancers and ingress controllers to make our applications available to the world.
For the longest time, you’ve had a choice: Would you like to use IPv4 or IPv6? Not both (well, not easily) … until now. IPv4/IPv6 dual-stack support, introduced as Alpha in Kubernetes 1.16, gives Kubernetes users the ability to leverage both IPv4 and IPv6 address assignments per pod along with native IPv4-to-IPv4 and IPv6-to-IPv6 communications to, from, and within a cluster. Only limited CNI functionality has been tested, but support will be expanded in the future.
Summary
Kubernetes 1.16 showed a good balance of what it takes to continually innovate while providing the stabilization of core components. This harmony is what will propel Kubernetes into a platform that is ready for mainstream adoption while lending itself to be ever-evolving with new features. To read about all the features in the Kubernetes 1.16 release, check out the 1.16 Enhancement Tracking spreadsheet and sign up for the What’s New with Kubernetes 1.16 webinar hosted by the CNCF.
Getting Involved in Kubernetes 1.17
VMware remains committed to being leaders in the upstream Kubernetes community and we want you to come contribute, too!
Participating in the Kubernetes Release Team is a wonderful way to contribute to the project. The team comprises multiple roles, many of which require no prior development experience. The application to shadow the Kubernetes 1.17 Release Team is now open. Read more about it here and join us in the community.
