The Kubernetes project is looking to get past unlucky 13 with the latest release of the container orchestration platform. The new 1.14 release includes new support for Windows containers and storage options but is light on new security features that overshadowed the previous release.
The update itself includes 31 “enhancements” that include moving some features from beta to general availability (GA), 12 features that are now in beta, and seven new features in alpha.
One of the biggest GA pushes from the release is official Kubernetes support for Windows-based containers. This allows for users to add Windows nodes as worker nodes and the scheduling of Windows containers. Kubernetes continues to support Linux-based containers that have been a staple of the platform since its inception.
Kubernetes has supported Windows containers in beta since release 1.9, which allowed users to “experiment and see the value of Kubernetes for Windows containers.” The GA move should prove most compelling for larger enterprises with an entrenched focus on the Microsoft ecosystem.
“It’s extremely important to people who like the powerful abstraction Kubernetes provides but have historically had to use something else to orchestrate and manage their Windows-based workloads,” explained Aaron Crickenberger, release lead for the latest Kubernetes update, in an email. “For people whose workloads are entirely Linux-based, it’s probably not so important.”
The move also provides a “very clear set of expectations around what will work now, what will work later, and what will never work unless there are changes to the underlying Windows OS,” Crickenberger explained. He added that this was made possible by the use of a Kubernetes Enhancement Proposal (KEP) that documented these expectations, a testing plan, and graduation criteria.
Crickenberger said timing of the Windows container support was based on both Kubernetes and the Windows container ecosystem gaining the necessary flexibility and maturity. “I can say that we collectively didn’t have clearly defined expectations when there was an attempt to bring this enhancement to GA last year, and so we opted to error on the side of clarity for our community,” he added.
It should be noted that Docker Inc. added support for Windows containers into its managed Enterprise Edition platform last year.
Another notable update is GA support for persistent local volumes. This makes it easier for Kubernetes to plug into external storage services like Rook and Gluster.
Crickenberger explained that containers with access to local storage have better performance than cloud provider block storage platforms. But, this option in the past has required a workaround because Kubernetes did not natively support such functionality.
This ties back to containers being developed to support stateless applications that did not require stored data to operate or support a running application. These were typically web services that acted as a go-between for any storage needs. Any actual storage within a stateless container was ephemeral, and thus a restart flushed out stored data.
However, as container use cases have evolved, stateful models have matured. These allow containers to maintain stored data even if a container is restarted and can support more developed applications. This model has become critical for enterprises that are running more advanced applications within containers.
It has also drawn considerable interest in developing platforms that can provide containers with a stateful storage option.
For instance, the Cloud Native Computing Foundation (CNCF), which houses the Kubernetes project, last year added the Rook project to its fold, which was the organization’s first storage-based project. Rook brings file, block, and object storage systems into the Kubernetes cluster as opposed to relying on an external storage source. This allows the systems to run alongside other applications that use their data, and it makes the cloud-native cluster portable across public and private clouds.
More than two dozen storage-related Kubernetes vendors are part of CNCF’s landscape map.
One area where the latest Kubernetes update is thin is in specific security updates. This despite a highly publicized security breach that overshadowed the previous Kubernetes update.
The Kubernetes 1.13 release last December was marred by the discovery of a “critical” flaw that gave hackers full administrative privileges on any compute node being run in a Kubernetes cluster. The flaw, which was discovered by a software engineer at Rancher Labs, garnered a 9.8 (critical) score out of 10 on the Common Vulnerability Scoring System (CVSS).
The 1.14 update does provide for a hardened set of default role-based access control (RBAC) policies that are designed to improve the privacy and security posture for clusters. They do this by removing discovery from the set of APIs that allow for unauthenticated access by default. This, in turn, limits attack vectors targeted at flaws like the one discovered late last year
Crickenberger said that the Kubernetes community does not view security as something tied to specific updates and instead is “something to be continually evaluated and improved.”
“There were numerous bug fixes and security fixes included in this release – as with any Kubernetes release – but few were as visible to people (or succinctly describable) as this RBAC change,” Crickenberger explained. He did add that deeper work was ongoing through the Security Audit Working Group that was established last year.
Security experts did note that more Kubernetes security flaws should be expected … and that’s a good thing.
“There are always going to be vulnerabilities,” explained Rani Osnat, vice president of product marketing at Aqua Security, at the recent KubeCon + CloudNativeCon North America 2018 event in Seattle. “The fact that one was found was to be expected. And I expect more will be found going forward. That’s just what should be expected with software.”