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

State of the cloud 2019: Multi-cloud and Kubernetes go hand in hand

State of the cloud 2019: Multi-cloud and Kubernetes go hand in hand

Read More
What’s new in Kubernetes 1.16?

What’s new in Kubernetes 1.16?

What’s new in Kubernetes 1.16: Ephemeral containers for easy pod debugging, support for dual-stack network, new options for the scheduler and much more. These are the features that look more exciting to us for this release (ymmv): Ephemeral containers are a great way to debug running pods, as you can’t add regular containers to a pod after creation (you should use sysdig tools like kubectl capture or kubectl trace for that though!), but you can run ephemeral containers. Right now the steps to run an ephemeral container aren’t straightforward.

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