Hello Kubernetes 1.16: Custom Resource Definitions ease the creation and long term management of APIs

Kubernetes 1.16 is expected to arrive this week, and with it comes a host of new changes that help ease management for users of this container orchestration platform. For users of Kubernetes, and of Red Hat OpenShift, this release signals the arrival of the general availability for Custom Resource Definitions (CRDs). 

When building open source software, duties and tasks must be distributed among large numbers of contributors, some of whom may even be in direct competition with one another. While this may sound like a risky, Machiavellian scenario, in practice, there’s far less rivalry. Instead, the whole project becomes a collaborative board game with individual high scores.

Those high scores ebb and flow as teams take charge of features, lead them to completion and exchange leadership roles over the course of the development of the project. We say all that to say this: Kubernetes 1.16 saw a great deal of work and guidance across the ecosystem, as well as from Red Hat and Google (top upstream corporate contributors). All vendors and the community at large can benefit from the updates made in this release, especially with the prime time for CRDs, which are a main extension point for building cloud native applications on Kubernetes.

A focus on APIs

For this release, the overall theme was one of easing the creation and long term management of APIs hosted within Kubernetes, especially via Custom Resource Definitions, which makes it easier for Operator authors to define the resources they’re making available to users in their clusters. 

CRDs have been fully supported in Red Hat OpenShift for several releases, but developing OpenShift 4 as an automated platform built on Operators gave us the chance to find the remaining gaps first hand. As we evolved our own Operator APIs, we turned our attention on the functionality missing from CRDs and used those lessons to take CRDs to GA as a solid basis for any API. We’ve focused on allowing API evolution over time with features like pruning and structural schemas, and added them back to the upstream project.

APIs are never perfect and it’s critical to accept that and build in the ability to make changes. To that end the team worked hard with the community to make it possible for CRD authors to express their intent via an enforceable OpenAPI Specification (formerly known as swagger).  This lets a cluster self-document how it’s API works for a developer or admin. These self-documenting APIs are able to keep up with the constant changes that can take place behind the scenes, reworking schemas and API structures as software projects evolve over time. It’s a problem similar to that which NoSQL databases tried to solve, but in a different realm: schema-less custom resources turned out to be hard to manage over the lifecycle of a software like OpenShift, without accidentally breaking backward compatibility.

With that in mind, we worked with the community to make schemas in CRDs the default, serving as guide rails for developers. An API schema will grow and evolve over time. Support for multiple versions and conversion between them allow developers to cope with these changes. 

Defaulting support is another such feature that helps developers build enterprise grade software on-top of CRDs: they can add default values for new fields, and existing users of their software will see them for new cluster objects and also for existing cluster objects when read from the etcd database. This gives a natural feel of APIs, crucial for OpenShift and also third party products on top of OpenShift.

Red Hat and others have driven the design and the implementation of CRDs in Kubernetes and is proud to see them graduate to GA in Kubernetes 1.16.

Kubernetes 1.16 is expected to be available for download from the CNCF GitHub account this week and you can read more in our technical post on what’s new. This release of Kubernetes is planned to be integrated into a future release of Red Hat OpenShift.