Kubernetes 1.17 Brings Volume Snapshots, Easier Plugin Management

Kubernetes is one of the single most widely used open-source container orchestration tools for deploying, scaling, and managing of containers on the market. Originally created by Google, this tool is now maintained by the Cloud Native Computing Foundation and today marks the release of version 1.17.

Version 1.17 is the fourth and final release of 2019 and consists of 22 enhancements. Of these enhancements:

• 14 have been graduated to stable.
• 4 are moving to beta.
• 4 are entering alpha.

Let’s take a look at some of the new enhancements to be found in the newest release of Kubernetes.

First, let’s examine one of the more important features.

Volume Snapshot

Although volume snapshots have yet to find itself migrated to Stable, it is a feature that many Kubernetes admins will greatly appreciate. This feature creates a point-in-time copy of a persistent volume. These snapshots can be used to provision new volumes or to restore an existing volume to a previous state.

But why add volume snapshots to Kubernetes, considering it already includes a volume plugin (one that provides a powerful tool for the automation and provisioning, attaching, and mounting of block and file storage)? To answer this, the Kubernetes official documentation notes:

Underpinning all these features is the Kubernetes goal of workload portability: Kubernetes aims to create an abstraction layer between distributed systems applications and underlying clusters so that applications can be agnostic to the specifics of the cluster they run on and application deployment requires no “cluster-specific” knowledge.

Snapshot operations is seen as a critical function for stateful workloads. By providing the means to trigger snapshot operations within the Kubernetes API, admins can now handle use cases without having to go around the Kubernetes API.

To read more about the Kubernetes Volume Snapshot functionality, head over to the official documentation.

In-Tree Plugin Migration

As of 1.17, Kubernetes will be migrating in-tree plugins to Container Storage Interface (CSI). Why is this happening? Prior to 1.17, the Kubernetes volume plugins were part of the core Kubernetes code and shipped with the core Kubernetes binaries. Because of this, adding new volume plugins to Kubernetes was always challenging. If a vendor wanted to add their storage system to the core, they were forced into working in alignment with the Kubernetes release process. This was not always feasible.

On top of that, third-party storage code could lead to reliability and security issues within the core Kubernetes binaries.

This has led to migrating of in-tree plugins to CSI. Of this migration, the Kubernetes developers say, “When a Kubernetes cluster administrator updates a cluster to enable CSI migration, existing stateful deployments and workloads continue to function as they always have; however, behind the scenes Kubernetes hands control of all storage management operations (previously targeting in-tree drivers) to CSI drivers.”

Other Features

The list of features to be found in Kubernetes 1.17 includes:

• Taint Node by Condition: representing node conditions that block scheduling using taints.
• Configurable Pod Process Namespace: Users can configure containers within a pod to share a common PID namespace by setting an option in the PodSpec.
• Dynamic Maximum Volume Count: adding support for dynamic and generic mechanism of maximum volume per node.
• Provide environment variables expansion in SubPath mount.
• Support for the defaulting of custom resources.
• Move Frequent Kubelet Heartbeats To Lease Api: Kubelet creates and periodically renews a Lease on the node and the node lifecycle controller treats this lease as a health signal.
• Support for watch bookmarks to reduce load on kube-apiserver.
• Behavior-driven conformance testing: Behaviors for conformance are defined upfront, separately from the tests which validate those behaviors.
• Finalizer protection for service: Adding finalizer protection to ensure the Service resource is not fully deleted until the correlating LB is also deleted.
• Avoidance of serializing the same object independently for every watcher.
• IPv4/IPv6 dual-stack support.
• Topology aware routing of services.
• RunAsUserName for Windows.

To download the 1.17 release of Kubernetes, visit the official GitHub page for the release. To find out more about what’s new, read the complete changelog here.

The Cloud Native Computing Foundation is a sponsor of The New Stack.

Feature image by SplitShire from Pixabay.