Kubernetes 1.11: Custom Resources, Pod Priority and Preemption, and more

As we continue our work in upstream Kubernetes development to enable it for the community and enterprises alike, we’d like to celebrate the upcoming delivery of Kubernetes 1.11 expected this week.

With each release of Kubernetes, we see a continued effort in building extensible APIs. This latest release brings greater stability and enhancements to Custom Resource Definitions (CRDs), pod priority and preemption enabled by default, the ability to use CoreDNS as the DNS plugin for the cluster, and more. We are especially thrilled with the additional work in this release to help developers build richer Kubernetes-native applications, especially Operators.

Thank you to the community and the release team for the concerted efforts. Our team members worked within the community to develop a number of these elements across many special interest groups (SIGs). We also participated in the Kubernetes 1.11 Release Team serving in both the Release Lead and Features roles. Here are a few highlights.

CRD enhancements: Making it easier to build Operators

CRDs are an extension mechanism that enable you to create and program Kubernetes objects. We are thrilled that two major enhancements are coming in Kubernetes 1.11: CRD versioning is now graduating to beta as well as support for subresources. This brings the CRD experience closer to the feature set provided with out of the box Kubernetes resources.

Versioning is actually something most other Kubernetes objects support today. It’s a critical part of managing the lifecycle of an API over time. In the past, CRD users had to manually convert their resources and recreate them with each version change. By providing a way to evolve CRDs with multi-version support, it is easier for Operator authors to iterate and evolve how they automate management of particular applications over time. This ability can also lower the barrier and make it easier for you to start building Operators. Check out the recently released Operator Framework to get started.

In this release, the CRD specification also includes the "scale" and "status" subresources. The scale subresource support lets other systems like the HorizontalPodAutoscaler and PodDisruptionBudget controllers interact with your resource. In addition, native CLI commands like kubectl scale can scale custom resources. The status subresource support lets operator authors separate who can write the spec for their resource separate from the system component that reports back its status. This separation of concerns for writing spec and status is a central Kubernetes API concept. It enables finer-grained access control for operator authors, and helps provide for a more reliable system.

Pod Priority and Preemption Features Graduate to Beta

Administrators who are running cluster critical services on the Kubernetes control plane, such as logging agents or SDNs, will appreciate the pod priority and preemption feature moving to Beta in Kubernetes 1.11. Now you have the ability to set scheduling priority of a pod to be higher and lower than other pods -- an important feature for production clusters running mission-critical workloads. Imagine wanting to run jobs at night, run payroll processing or other functions that may have to be managed in a team with scarce resources. With the ability to associate relative weights to each pod, the scheduler evicts less critical pods in order to make room for the most important pods to run when the cluster is out of resources.

Cluster operators that self-host the control plane, or run multiple cluster critical services on the control plane should benefit from this feature.

Out of the box, there are two system priorities: 'system-node-critical', and 'system-cluster-critical' that have the highest scheduling priorities. Operators can use these priorities to allow pods that are required to support operation of the cluster to always schedule. Where those priorities are insufficient, operators can define additional priorities for their use case.

A few other notable features

Continued work on CRI (Container Runtime Interface) brings improvements to logging and metrics gathering. In addition to the observability plumbing, enhancements to CRI support for Windows containers bring us closer to general availability of a Windows version.

CoreDNS, a lightweight, fast, and pluggable cluster DNS module, graduates to general availability. This will help set the stage for the eventual replacement of kubedns as the de facto DNS plugin in Kubernetes.

Get started with Kubernetes 1.11

Try out Kubernetes 1.11 here, coming out this week, to make use of CRD enhancements, pod priority and preemption scheduling, and more!

Join us for an OpenShift Commons briefing online on July 18 at 9 AM PT for a deeper dive about the new features live with Red Hatters that participated on the release team.

For enterprises interested in Kubernetes 1.11, note this should be available in a future release of Red Hat OpenShift.