Kubernetes 1.16: A big step for CRDs, kubectl and Container Storage Interface

Kubernetes 1.16: A big step for CRDs, kubectl and Container Storage Interface

  • October 5, 2019
Table of Contents

Kubernetes 1.16: A big step for CRDs, kubectl and Container Storage Interface

This week Kubernetes 1.16 is expected and we want to highlight the technical features that enterprise Kubernetes users should know about. With Custom Resource Definitions (CRDs) moving into official general availability, storage improvements, and more, this release hardens the project and celebrates the main extension points for building cloud native applications on Kubernetes. Custom Resource Definitions (CRDs) were introduced into upstream Kubernetes by Red Hat engineers in version 1.7.

From the beginning, they were designed as a future-proof implementation of what was previously prototyped as ThirdPartyResources. The road of CRDs has focused on the original goal of making custom resources production ready, bringing it to be a generally available feature in Kubernetes, highlighted with the promotion of the API to v1 in 1.16.

Source: openshift.com

Tags :
Share :
comments powered by Disqus

Related Posts

Kubernetes pod autoscaler using custom metrics

Kubernetes pod autoscaler using custom metrics

In this post we are going to demonstrate how to deploy a Kubernetes autoscaler using a third party metrics provider. You will learn how to expose any custom metric directly through the Kubernetes API implementing an extension service. Dynamic scaling is not a new concept by any means, but implementing your own scaler is a rather complex and delicate task.

Read More
Blog: Kubernetes 1.16: Custom Resources, Overhauled Metrics, and Volume Extensions

Blog: Kubernetes 1.16: Custom Resources, Overhauled Metrics, and Volume Extensions

Read More
Announcing etcd 3.4

Announcing etcd 3.4

In particular, etcd experienced performance issues with a large number of concurrent read transactions even when there is no write (e.g. “read-only range request … took too long to execute”). Previously, the storage backend commit operation on pending writes blocks incoming read transactions, even when there was no pending write. Now, the commit does not block reads which improve long-running read transaction performance.

Read More