In a calendar year, the final release of Kubernetes will typically lack new enhancements but advance the current feature set. With the holiday season coming on the heels of KubeCon + CloudNativeCon North America 2019, many contributors will work on tasks that can fit into their timeline and push larger enhancements to the next milestone.
For organizations that are beginning to adopt Kubernetes or move it to production, this subtle shift in focus is a welcome treat. For many enterprises, the rate of change in open source projects is hard to track, so it’s good to see something stabilize over a quarter. Having a reference point where many anticipated enhancements stabilize while new alpha-gated ones are minimized reduces unforeseen impact.
For Kubernetes 1.17, the SIGs representing storage, networking, and api-machinery account for over half of the enhancements that were tracked. In total, there were 4 new enhancements, 4 graduating to beta, and 14 moving to stable. Let’s look at some of the most important enhancements that were introduced or graduated in version 1.7.
CSI Topology Support
There can be constraints on how a volume can be attached to a running pod, and the constraints are amplified as a cluster grows and stretched beyond its original zones. CSI topology support, now stable in Kubernetes 1.17, solves this issue because the driver is assigned keys that contain the NodeID. The scheduler is now aware of these constraints and the pod will be available on nodes that can attach the PersistentVolumeClaim (PVC).
Taint Node by Condition
Graduating to stable in Kubernetes 1.17 is the ability to add taints on nodes based on resource availability. When any of the condition types are met, a status will be placed on the node of true, false, or unknown, allowing the scheduler to place workloads elsewhere. The new condition types are Ready, OutOfDisk, MemoryPressure, DiskPressure, NetworkUnavailable, and PIDPressure. If a node begins running out of memory, the node controller will mark it as NoSchedule until resources have freed up.
Topology-Aware Service Routing
With almost two years in design and development, the ability to support topology-aware routing of services by domains is now alpha in version 1.17. This feature allows a user to set a definition of locality based on node, rack, zone, region, and so forth by using node labels. For instance, if you have a region in which the hardware performs with lower latency than your other racks, you can specify that an application run only in that region.
Cloud Provider Labels
To follow on with all the topology enhancements in 1.17, there is another graduating to stable: the cloud provider labels. When a node or volume is created or registered using a provider-specific plugin, it will be applied with a label for that particular cloud provider. This label contains cloud provider information that could be used for more advanced features in the future. This change will be implemented over the next few releases to make sure beta labels are demoted according to the Kubernetes deprecation policy.
Kubeadm Structured Output
Creating a Kubernetes cluster can be hard but it doesn’t have to be. Kubeadm is the trusted tool that can automate everything needed to create a conformant cluster. Many higher-level applications rely on kubeadm, such as Terraform and Cluster API, to sift through unbuffered text output. This new enhancement, which makes its alpha debut in kubeadm, will begin supporting structured output in the form of JSON, YAML, and Go templates. Tooling can now take advantage of simple output formats and reduce unexpected errors.
The tight release schedule of Kubernetes 1.17 spurred contributors to add fewer new features while taking an approach that focused on stabilizing existing beta features. To read about all the features in the 1.17 release, check out the Kubernetes Enhancement Tracking spreadsheet for 1.17. Get signed up for the CNCF 1.17 Webinar to learn about what’s new.
Getting Involved in Kubernetes 1.18
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. Subscribe to this GitHub issue to be one of the first to know when the application form opens. Read more about how to participate in the Release Team and join us in the community.