The latest release should help developers build richer Kubernetes-native applications, especially Operators.
Kubernetes has hit version 1.11. The 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.
The release is expected to help developers build richer Kubernetes-native applications, especially Operators.
CRDs are an extension mechanism that enable you to create and program Kubernetes objects. 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.
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.
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.
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.
Continued work on CRI (Container Runtime Interface) brings improvements to logging and metrics gathering.
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.