K8s awaits due date for latest, greatest slate: Extension versioning will reach beta, mates

Kubernetes, the software container orchestration system, is expected to hit version 1.11 on Wednesday, bringing with it a handful of potentially useful enhancements.

The software currently supports an alpha version of Custom Resource Definitions (CRDs), an API that allows people to define custom resources (aka extensions) to their container clusters. Starting in 1.11, described in detail here by Red Hat's CoreOS team, CRD versioning moves to a more stable beta status.

Versioning provides a mechanism to automate the management of applications as they evolve instead of manually adapting custom extensions to accommodate version changes in client software.

In a phone interview with The Register, Derek Carr, senior principal software engineer and OpenShift architect at Red Hat, said the goal is to enhance Kubernetes to allow users to manage their extensions as they change over time.

"Just like the Kubernetes API evolves, extensions of the platform need to evolve," he said. "And the key mechanism to do so involves versioning."

The CRD specification now implements support for two subresources: "scale" and "status."

The former helps systems like HorizontalPodAutoscaler and PodDisruptionBudget controllers communicate with clusters.

The latter provides authors of operators – packaged Kubernetes applications – with more specific resource access controls by separating two Kubernetes object fields: spec and status.

The spec is the desired state of the object, as defined by the user; the status is actual state of the object, as reported by the system. Keeping the two distinct from a permissions perspective makes for more trustworthy systems.

Pod priority and preemption features are also entering into beta. As the name suggest, pod priority allows Kubernetes users to set the scheduling priority of a pod – a group of containers on the same host – to be higher than other pods.

Carr explained that not all workloads running on a cluster are equal. "For many users, their clusters have a fixed node size or are capped at a certain cost profile," he said. "What pod priority lets you do is assign a relative rank between two pods."

The Kubernetes Scheduler uses the ranking to prioritize certain clusters or to preempt existing ones to make room for a more critical cluster.

Asked about the focus of recent Kubernetes work, Carr said there's been a lot of effort to make sure the orchestration software doesn't get in anyone's way.

"We want to unleash everyone else who wants to build around Kubernetes to do what they want to do," said Carr. ®