Kubernetes v. 1.15 came out on June 19, 2019, and is the second major release of the year. In our opinion, the most interesting additions of the new release have to do with the extensibility of the platform, which is one of its best features. For example, Kubernetes allows creating custom API using custom resources and aggregated APIs.
This release introduces a number of enhancements to this extensibility functionality, which we will discuss in this overview. Specifically, we’ll focus on the new features for CustomResourceDefinitions (CRDs) extensively used by Supergiant. We’ll also discuss new updates related to kubeadm and Container Storage Interface (CSI).
As we discussed in a previous tutorial, CRD is an API primitive that allows users to create new custom resources in Kubernetes. With CRDs, users can define new API objects similar to Pods and Deployments and apply a controller logic to them. New resources can be enriched with user-defined fields and validation schemas.
In the new release, Kubernetes introduced the automatic removal of unknown fields in CRD objects sent to a Kubernetes API. How does this differ from earlier K8s versions?
Previously, any custom object created via a CRD could have two types of fields: required fields specified during a CRD declaration and any custom fields submitted during an API object creation. Required fields are obligatory fields that have to pass validation using the OpenAPI validation schema. Before creating an API object with required fields, Kubernetes would check their type (“string,” “Boolean,” etc.) and ensure that it matches the validation schema.
However, along with these required fields, the user could also enrich the API object with any custom fields that would be saved along with required fields as part of the API object to etcd. In the new release, these custom fields will be automatically removed to protect API consistency. Kubernetes ensures that only the data specified by the CRD developer is persisted to etcd. The CRD pruning will be available as a beta feature in Kubernetes 1.15. A future apiextensions.k8s.io/v1 variant of CRDs will enforce pruning.
Just to illustrate how it works, take a look at this CRD definition:
preserveUnknownFields: false</code> group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: myresources singular: myresource kind: MyResource shortNames: - mr validation: openAPIV3Schema: required: ["spec"] properties: spec: required: ["cert","key","domain"] properties: cert: type: "string" minimum: 1 key: type: "string" minimum: 1 domain: type: "string" minimum: 1
Here, we define three required fields (“cert,” “key,” “domain”) validated using the openAPIV3Schema. In order for the API object to pass the check of the API server, each field value should have a type specified in the above CRD definition. Also, all custom fields will be automatically pruned.
custom: "to be pruned"
For example, the field “custom” in the MyResource object above will be automatically pruned because it’s not defined as the required field in the CRD validation schema.
Users can activate pruning by setting spec.preserveUnknownFields: false in the CustomResourceDefinition.
Another very convenient feature introduced in the new release is the CRD defaulting. It can be used to autofill unspecified fields with default values in any object sent to the API, as well as when reading it from etcd. It introduces flexibility to the APIs, allowing developers to define API requirements and defaults. Users can specify these default values using the default keyword in the OpenAPI validation schema. This feature is available as an alpha in Kubernetes v1.15, and it requires structural schemas.
Kubernetes v.1.15 introduces a number of improvements to kubeadm cluster provisioning tool maintained by the Kubernetes community. The following improvements drew our attention:
As you might already know, Kubernetes is gradually moving away from in-tree volume plugins to the Container Storage Interface (CSI) plugins. This allows the platform to de-link user volume implementations from the upstream code, and it comes with portability benefits because a number of platforms support CSI.
In Kubernetes v1.15. SIG Storage actively worked on bringing CSI to feature parity with in-tree storage functionality, including such features as volume resizing, inline volumes, and more. SIG Storage also introduced a completely new volume cloning feature that did not exist in the in-tree Storage subsystem. This new feature allows users to use another Persistent Volume Claim (PVC) as a “DataSource” when provisioning a new volume. In this case, the new volume becomes a clone of the source volume.
Kubernetes v.1.15 offers a number of new features that improve the platform’s extensibility with custom resources, make cluster provisioning more efficient, and facilitate the migration to cloud-native standards in storage like CSI. You can find more information about the new release in this article.
The Supergiant team is closely following the developments in the Kubernetes codebase and is planning to make K8s 1.15 clusters available in the Supergiant Control in the near future. Stay tuned to our updates to find out more.