Kubernetes 1.8 is being released Thursday, with updates focused on stability, simplicity and security.

“Rather than being a grandiose release with many new features, this is a release that deepens existing features,” said Aparna Sinha, group product manager for Kubernetes at Google. Google initially released Kubernetes as open source, though the software codebase is managed by the Cloud Native Computing Foundation.

Releases for this open source container orchestration engine are scheduled for every three months. The latest included contributions from individual contributors as well as employees of Avi Networks, CoreOS, Google, Heptio, Huawei, Microsoft, Red Hat and Samsung SDS and other companies.

About 54 percent of the Fortune 100 companies run Kubernetes in some form, according to analyst firm Redmonk. Stability, simplicity, security are the major requirements of the market, notes Ihor Dvoretskyi, developer advocate for CNCF and Kubernetes 1.8 features release lead.

In the new release:

For security: Role-based access control, which moved to beta in 1.6 is now moved to stable. It allows cluster administrators to dynamically define roles to enforce access policies through the Kubernetes API. It graduated to GA with no API changes to the core types, CoreOS‘s Eric Chiang noted in a blog post. Additional features related to RBAC are in the works, including new APIs for determining the actions a user can perform in the system.

Read More:   Update This Week in News: Oracle’s Autonomous Database, InfluxData’s Timely One

Filtering outbound traffic through network policies, now in beta, augments existing support for filtering inbound traffic to a pod. Transport Layer Security (TLS) certificate rotation for the Kubelet node agent also graduates to beta with the new release.

For stability: Custom features for horizontal pod autoscaling moves to beta. “In the past [Kubernetes] allowed scaling up and down based on CPU utilization, but developers have wanted to scale their applications based on other types of metrics, such as queue length or load on a load balancer,” Sinha explained.

Providing this required stabilization of the resource metrics API and the custom metrics API. In addition, a new metrics server was built. It now has more readable and understandable error outputs, so you know why if it doesn’t work and where it failed, she said.

Workload APIs also moved to beta. They provide abstractions required to manage applications deployed to Kubernetes. Chiang explained the four kinds:

  • DaemonSets manage the complexity of running a Pod on all nodes, or a subset of nodes based on user-specified criteria.
  • A ReplicaSet provides a basic high-availability primitive to ensure a specified number of copies of a Pod are running.
  • The Deployment controller enables declarative updates to Pods and ReplicaSets, providing critical functionality such as canaries and rolling deployments.
  • A StatefulSet is one mechanism for supporting Pods that require persistence by imbuing them with a unique identity to enforce ordering and persistent volume access guarantees.

He cited Bootkube, which bootstraps highly available self-hosted clusters, as a project in which CoreOS has used the Workload APIs.

For Kubernetes 1.8, these APIs have been moved out of theextensions/v1beta1 API group into a dedicatedapps/v1beta2, laying the groundwork for workloads to be promoted to GA in a future release.

For workload diversity: Red Hat, in a blog post detailing what you need to know about Kubernetes 1.8, noted an addition that it says points to the next wave of cloud computing. They cited alpha code from the Resource Management Working Group, recently formed to support the increasingly complex classes of applications that are getting developed.  The group reflects the intersection of different ecosystems with Kubernetes as reflected in this venn diagram posted in the blog post about the new resource management working group.

Read More:   Update 3 Challenges to Monitoring StatsD and How to Tackle Them

For storage: There’s now the ability to set some limits to ephemeral storage, to specify mount options, there’s better coverage of storage usage metrics. The flex driver deployment has been introduced as alpha, which allows out-of-tree volume drivers.

The way Kubernetes works with storage is that there’s a storage driver and there’s a storage plug-in framework. In the past, these drivers had to be written and compiled into the Kubernetes core. They were called entry volume drivers. Now there’s decoupling so the volume drivers can be written out of tree, Sinha said.

For simplicity: The team has been working on making installation easier with the release of kubeadm about a year ago. It’s two lines to set up a Kubernetes cluster. Now the kubeadm command includes support for upgrading the cluster.

In addition, many users are running machine learning and big data and advanced computation workloads on top of Kubernetes. Those users will be very happy to know that cron jobs is in beta, Sinha said. There are scheduling and timing capabilities for running particular jobs. Cron is already supported in Swarm, which is Docker’s own orchestration engine.

And the team has been working for more than a year on supporting the Spark data analysis framework. It’s now natively supported on Kubernetes.

Custom Resource Definitions remain in beta for Kubernetes 1.8. CRDs allow extension of the Kubernetes API to provide features, not in core Kubernetes that look like first-class APIs to users. The switch requires users to migrate Third Party Resources to CRDs. For the 1.8 release, CRDs have added schema validation in alpha for a more robust client experience. This change lets CRDs define server-side validation of their resources, instead of the current schema-less “bag of values” that clients use today, according to Chiang.

What’s to Come

The alpha features indicate the direction in the future, Sinha said. They focus on making things more reliable.

Read More:   Update Neo: Graph Databases Are for More than Social Media

They include:

Priority and pre-emption: You can specify that a particular pod has priority over others, which might mean that other pods might be sacrificed if there are not enough resources in the cluster.

Automatic tainting of nodes: Taints and tolerations came in 1.6. This can be used in many different ways. For instance, you can dedicate a node to a certain type of application and say this node is not schedulable. In this release, Kubernetes figures that out, in effect saying in effect, “OK, this node is tainted because it’s down or has an error or something; it should not be scheduled.”

Volume snapshots updates: On the storage side, you can size persistent volumes, but now resizing is added.

The ability to extend kubectl, the command-line interface, to customize your interaction with clusters is also new with version 1.8.

Alex Williams contributed to this story.

The Cloud Native Computing Foundation, CoreOS, Google and Red Hat are sponsors of InApps.

Feature image via Pixabay.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.