Kubernetes 1.7 is here just in time for the Fourth of July weekend, adding some fireworks of its own with new security features and broader support for stateful apps that are sure to appeal to the coveted enterprise market.
On the security front, a network policy API promoted from beta to stable allows users to set rules to restrict communication between individual Kubernetes pods, and isolate network traffic for individual apps as well as individual users in a multi-tenant architecture. In previous releases, each app could be given its own Kubernetes namespace, but now specific services within those apps can be controlled within the namespace.
New node authorizer and admissions control plugins allow more fine-grained control of communication between the kubelet (the main software agent that runs Kubernetes on each host in a cluster) and secrets, pods and other objects on the node level. Kubernetes secrets management also makes gains on Docker Secrets with an alpha feature that encrypts secrets in the etcd data store.
Many enterprises are after Kubernetes stateful application support in production, and this Kubernetes release refines StatefulSets to include support for new update methods such as rolling updates. Kubernetes persistent volumes also take a step forward in Kubernetes 1.7 with alpha support for local storage volumes, which are popular for many big data and HPC use cases.
Databases are still a new area of development for Kubernetes and there is plenty still on the roadmap for StatefulSets. Rolling upgrades, for example, are supported now but rollback with StatefulSets is still being developed.
Kubernetes 1.7 broadens container runtime support, extensibility
While Kubernetes 1.7 technical features are sure to make waves, another intriguing aspect of the announcement has to do with the potential implications for the industry as the container runtime becomes standardized – and commoditized. Enterprises could see greater stability in container runtime support as Kubernetes begins its integration with Docker containerd in this release, for example. Docker open-sourced containerd, its core container runtime, and donated it to the Cloud Native Computing Foundation earlier this year.
“There were definitely some concerns with the stability and modularity of the platform [before containerd],” said Sam Ghods, co-founder and solutions architect for online document sharing and collaboration firm Box. “The container runtime should be very swappable.”
In future Kubernetes releases, it will be. For now, Kubernetes 1.7 lays the groundwork for better support of alternative container runtimes with enhancements to the Container Runtime Interface, a container runtime plugin API. With version 1.7, developers can more closely monitor various container runtimes through the interface, and use newly published validation tests for container runtime integration with the interface as well. .
In subsequent releases, there will be full production-ready support for runtimes that include CRI-O and rkt in addition to Docker containerd.
Docker Inc. has been an active participant in developing Kubernetes 1.7, according to Google project overseers, and if anything, containerd has drawn Docker the company and the Kubernetes community closer together, they say. However, some industry watchers might wonder about the future direction of Docker’s business now that vendors can standardize around core containerd features without Docker’s value-add offerings, and as the prospect of CRI-O integration resurfaces with this release.
New extensibility features in this Kubernetes release, such as API aggregation, will benefit container orchestration offerings based on Kubernetes, such as Red Hat OpenShift. This new feature enables power users to tinker with third-party tools for management as part of the Kubernetes cluster.
Commercial results of this extensibility update will include the Red Hat / AWS service catalog previewed at this year’s Red Hat Summit. Advanced Kubernetes users such as Box look forward to getting their hands on these features as well.
“We can now reuse the API server and Kubernetes etcd to build in third-party resources instead of doing our own hacking to create a data store and API server for every microservice,” Ghods said. “It cuts down on the time and complexity of developing services.”
Ghods added that he hopes the new extensibility features will give rise to a Kubernetes CI/CD tool similar to Netflix Spinnaker. There aren’t any concrete plans for such a tool right now, but Kubernetes has now built the foundational technology to allow it. Ghods said.