It seems that not so long ago that the new bells and whistles available in Kubernetes 1.9 had captured the spotlight. However, Kubernetes 1.10 Beta is here, and as is the case with any popular technology in the container orchestration space, one is bound to be surprised by the rapid pace of new updates.

Notable in Kubernetes 1.10 Beta is the large number of features announced in the Beta and Alpha stages. Many these new features keep the cluster administrator in mind with a variety of  configuration and metric gathering options across a variety of SIG categories. Yet developers also have a reason to rejoice as the many updates in Kubernetes 1.10 Beta focus on extending the functionality of the Kubernetes API.

When considering new features across all SIG groups we can see that SIG-storage had the greatest number for Kubernetes 1.10 Beta. A large number of these releases were features promoted to Beta.

All together, Kubernetes 1.10 Beta promotes some key features to general availability, but also teases interesting and powerful features that may eventually find their way to Kubernetes 1.11 or later releases.

This article makes use of a variety of sources including the fantastic article written by Nick Chase on Kubernetes 1.10 Beta written on the Mirantis Blog as well conversations by core Kubernetes Contributors on the Kubernetes Github repo.

Stable/General Availability: Features that are deemed mature enough general Kubernetes community to be used in Production.

Kubelet TLS Bootstrapping (SIG-auth)

The promotion of Kubelet TLS Bootstrapping to General Availability is considered one of the most exciting updates in Kubernetes 1.10 Beta, as it makes it significantly easier to ensure kubelet can use TLS (Transport Layer Security). It operates on the principle of using a certificate signing authority that is trusted on a cluster level to approve Certificate signing requests from a given kubelet. This removes the need to have a cluster admin manually generate TLS credentials or have the kubelet self sign its own certificates, which is not recommended.

API Aggregation (SIG-api-machinery)

While Kubernetes is popular for the many capabilities it offers in the realm of workload orchestration, many production deployments of Kubernetes require the functionality of the Kubernetes API to be extended. API Aggregation allows third party developers to deploy apiservers alongside the Kubernetes API.

Greater Storage Metrics via Prometheus (SIG-storage)

One of #SIG-storage’s main initiatives has been to improve the ability to analyze different metrics at various points of times in the clusters storage. These improved metric gathering capabilities have now become stable in Kubernetes 1.10 Beta. Some of these improved metrics include the total volume mount and unmount time metrics, total volume attach and detach time metrics, as well as a number of other volume and storage related metrics.

Beta Features: Features that have been deemed more reliable and may eventually make their way into production

Separate API group for Pod Security Policy (SIG-auth)

To improve pod security capabilities, specifically related to what certain pods can and can’t do in relation to the permissions context in which they were created, a separate API Group for Pod Security Policy is now in Beta. As mentioned by Eric Tune, a Kubernetes contributor, this will “define policy objects that limit what security-related features pods and containers can use.”

Limit node access to API (SIG-auth)

This update, now in Beta, uses Node authorization mode and the NodeRestriction admission plugin, to ensure that, for certain APIs, a Node can only call its own API. These limitations extend such that Nodes can only modify Pods that belong to them as well only retrieve secrets and configmaps from this set of pods.

Support configurable pod resolve.conf (SIG-network)

As Kubernetes grows in popularity and in its number of production deployments, it becomes necessary to exert a finer grain of control in regards to DNS. A configurable pod resolve.conf will enable DNS for a single pod to modified.

Switch default DNS plugin to CoreDNS (SIG-network)

As CoreDNS support for Kubernetes grows, the intention to replace kube-dns as the default for Kubernetes with CoreDNS will continue to mature. For now the use of Core DNS has been proposed as alternative to kube-dns, however the change will not be implemented until Kubernetes 1.11.

Mount namespace propagation (SIG-storage)

This feature allows for volume mounts that occur in a host to be visible in the host’s mount namespace. It does this by letting a container mount a volume called rshared.

Local Ephemeral Storage Capacity Isolation (SIG-storage)

In Kubernetes, any on-disk files that a Pod stores is put into ephemeral storage. Despite the unreliability of this storage mechanism, a pod should still be aware of how much storage space it has left. “Local Ephemeral storage capacity isolation” enables a Pod to reserve its own storage via shared partition for pods and containers instead of sharing a pool of storage space with all other pods requiring ephemeral storage.

Out-of-tree CSI Volume Plugins (SIG-storage)

In an effort to promote the ecosystem of storage drivers from third party vendors in lieu of the Container Storage Interface, out-of-tree CSI Volume Plugins are now supported in Beta. This will allow third party developers to manage the development of their drivers without the approval (and code reviews) of the Kubernetes core community.

Local Persistent Storage (SIG-storage)

Without local persistent storage, persistent volumes must rely upon network attached storage. Now locally attached storage has obtain Beta support in Kubernetes 1.10.

Topology Aware volume Scheduling (SIG-storage)

This feature allows Persistent volumes to have topology constraints applied to them, such as what node or zone they belong to. This results in the Kubernetes scheduler being aware of volume topology constraints and optimizing the binding of volumes right before Pods are scheduled.

CRI validation test suite (SIG-node)

Kubernetes is primarily associated with being a platform to orchestrate Dockerized workloads. However, the Container Runtime Interface (CRI) enables Kubernetes to run other types of workloads as well. This feature provides a suite of test cases to provide developers a method of validating other workload types for the sake of compliance and operability.  

Dynamic Kubelet Configuration (SIG-node)

According to the Kubernetes documentation the kubelet “is the primary “node agent” that runs on each node”. Its functionality extends to ensuring that the all containers and pods running on a node match the intended “state” of a Kubernetes cluster provided by user. Therefore, updating kubelet is a primary mechanism by which to affect the entire cluster itself. In “Dynamic Kubelet Configuration”, the kubelet can be modified so that the node that it is running on can remain running during this update.

Deployment (SIG-Cluster Lifecycle): Support out-of-process and out-of-tree cloud providers (beta):

For Kubernetes to spread and become more widely adopted many of its pain points of integrating with various cloud providers will need to be smoothed out. One initiative designed to further this goal is providing a set of binaries unique to providers to improve the update cycle of Kubernetes across them.

Alpha Features: Newest features that are intended to introduce new functionality and expected to be less reliable.

External client-go credential providers (SIG-auth)

Seeing that Golang was the primary language used to develop Kubernetes, it makes sense that one of its most popular client libraries is client-go. As companies attempt to implement client-go in their Kubernetes clusters they might find themselves needing to integrate with their own or third party credential providers. This alpha feature will enable exactly that.

Token Request API (SIG-auth)

Multiple updates to service account tokens are included. Among these updates include binding for support audience, time, and key binding.

Topology Aware routing of services (SIG-network)

As stated by DuJun, a Kubernetes approver and product manager, “Kubernetes service proxy just randomly picks an available backend for service routing and this one can be very far from the user, so we need a topology-aware service routing solution in Kubernetes.” The solution to this problem, now in alpha, will ensure that scheduled Kubernetes resources that interact with services can be scheduled closer together from a geographic perspective.

Make NodePort IP Address configurable (SIG-network)

This features gives Kubernetes’ users the ability to determine a NodePort IP address before it is run. As Nick Chase mentions in Mirantis’ blog on Kubernetes 1.10 Beta “Not having to specify IP addresses in a Kubernetes cluster is great — until you actually need to know what one of those addresses is ahead of time, such as for setting up database replication or other tasks”.

Support for self-hosting authorizer webhook (SIG-api-machinery)

This feature enables webhooks that validate permissions prior to the execution of commands to be hosted within a Kubernetes cluster rather than externally.

Resize Support for Persistent Volumes and Flex Volume (SIG-storage)

This update will enable Persistent Volumes, among them Flex Volumes, to be resized without disrupting the availability of existing data in a volume.

Configurable Pod Process Namespace Sharing (SIG-node)

This feature provides the functionality of running multiple containers in a given pod as the same process or separate individual process each with a unique pid.

Support for windows Container configuration (SIG-node)

As seen in the CRI validation suite, Kubernetes 1.10 Beta includes provides extended functionality to the Container Runtime Interface. Among this includes the ability provide a WindowsContainerConfig.

Debug Containers (SIG-node)

In order to provide greater functionality for debugging pods, this features provides the ability to use debug containers with the necessary tools to do so.

Interested and intrigued by the possibilities in Kubernetes 1.10 Beta? We’d love to hear from you. Start a conversation with us here, please. Learn more about Nirmata while you are visiting.