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

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

  • October 5, 2019
Table of Contents

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

We’re pleased to announce the delivery of Kubernetes 1.16, our third release of 2019! Kubernetes 1.16 consists of 31 enhancements: 8 enhancements moving to stable, 8 enhancements in beta, and 15 enhancements in alpha. CRDs are in widespread use as a Kubernetes extensibility mechanism and have been available in beta since the 1.7 release.

The 1.16 release marks the graduation of CRDs to general availability (GA). Kubernetes has previously made extensive use of a global metrics registry to register metrics to be exposed. By implementing a metrics registry, metrics are registered in more transparent means.

Previously, Kubernetes metrics have been excluded from any kind of stability requirements. There are quite a few enhancements in this release that pertain to volumes and volume modifications. Volume resizing support in CSI specs is moving to beta which allows for any CSI spec volume plugin to be resizable.

As the Kubernetes API has evolved, we have promoted some API resources to stable, others have been reorganized to different groups. We deprecate older versions of a resource and make newer versions available in accordance with the API versioning policy.

Source: kubernetes.io

Share :
comments powered by Disqus

Related Posts

Building a Kubernetes platform at Pinterest

Building a Kubernetes platform at Pinterest

Over the years, 300 million Pinners have saved more than 200 billion Pins on Pinterest across more than 4 billion boards. To serve this vast user base and content pool, we’ve developed thousands of services, ranging from microservices of a handful CPUs to huge monolithic services that occupy a whole VM fleet. There are also various kinds of batch jobs from all kinds of different frameworks, which can be CPU, memory or I/O intensive.

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