Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2020 - Virtual, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Beyond File and Block Storage in Kubernetes - Sidhartha Mani, MinIO

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Beyond File and Block Storage in Kubernetes - Sidhartha Mani, MinIO

Kubernetes graduated Container Storage Interface (CSI) to GA status in v1.13. It has since evolved to support a large number of vendors and storage formats. It has brought the industry together in consensus about the best practices in storage. CSI only supports Block and File storage. Object storage is a fundamentally different paradigm where data is accessed over the network rather than locally. It allows applications to remain stateless, while offloading state into a blackbox over the network. Object storage is the key enabler for cloud migration. This paradigm however, does not have a standard mechanism for consumption in Kubernetes. In this talk, we discuss our efforts in bringing object storage into the forefront of kubernetes and introduce the Container Object Storage Interface (COSI) and cover: - Need for COSI - Best practices for using COSI - Designing apps to leverage COSI

https://sched.co/ekF8

A

Good afternoon everybody, my name is siddhartha mani and I'm a software engineer at minio, I'm here today to talk about one of the most exciting features coming to kubernetes object, storage, support. In the last 10 years, the amount of data in the world has grown faster than ever before.

A

This is due to the new age of data collecting applications that we all use and have come to love. Take. For instance, google maps, google maps has mapped 98 of our planet. Google maps continues to grow this data by collecting traffic information and maintaining an updated list of businesses and food activity at their locations.

A

Another huge data collector is social media. We spend a third of our day on the internet, using social media. We tweet half a million times every minute and we view half a billion instagram stories every day and it doesn't stop there.

A

Content creation networks and streaming services like netflix, hulu and youtube take up another eighth of our time on the internet every day. The amount of data today is truly staggering and it continues to grow at this accelerated pace. So how did we manage to scale to such heights if you've noticed the trend here? Almost all of the data described above are either photos, videos or some kind of point in time event like location information.

A

These kinds of data are also called as unstructured data. Unstructured data constitutes the majority of data today and also the majority of growth. One of the reasons we were able to scale to such heights is because of some inherent properties of unstructured data before going into the properties of unstructured data. Let's take a moment to also look at a parallel trend that accompanied this data growth trend. Let's talk about the evolution of hardware and software in these 10 years.

A

In the 10 years, the highest and commercial network switches went from 40 gigabits per second to 100 gigabits per second note that I'm talking about commercially available switches, not just the maximum possible. At that time, networking speeds have gone up two and a half times in just 10 years.

A

Just like improvements in networking storage has also shown impressive growth, both in terms of size of drives and also in terms of throughput drive sizes have gone up from 600 gigabytes being the maximum size in 2010 to 16 terabyte drives available for use today and then there's drive throughput.

A

Today's drives can sequentially read data at five gigabytes per second, that's 40 gigabits per second, the best data I could find about the drive speeds in 2010 were about 300 megabytes per second of read throughput. This was again from ssds back then, comparing networking and storage today, even though storage seems to have shown much larger growth. Networking throughput speeds are still higher over the network. We can transmit data at 100 gigabits per second to the local drives. We can transmit data at a maximum of 40 gigabits per second.

A

Obviously, networking is faster than storage. One thing: that's clear from this trend is that high scale applications should put their data over the network rather than store them locally on the drives. This does come at a small cost which is latency.

A

Now, let's go back and talk about properties of unstructured data and, let's see if we can tolerate this latency. One of the great properties of unstructured data is that it is much harder for applications to edit this data. All the edits that do happen are performed on a copy of the data and then saved back as a new object at first, this might seem like inefficient usage of storage space.

A

However, there are far reaching advantages to this approach. To start with, the lack of edits makes the data much more durable. It is much harder to cover up data if we don't make changes to the middle of it. So the first property of unstructured data is immutability, as you can see, immutability leads to higher durability.

A

Now. Applications that store data over the network also gain another property. They become stateless.

A

The great thing about stateless applications is that it's easier to manage it's easier to deal with when it does fail and easier for people and process around it to scale along with the application, and all that needs to be done for applications to become stateless is to use this form of storage that we described, which is called object. Storage.

A

It's no surprise that object. Storage is the fastest growing trend in storage and has been for the last 10 years now. Given all this object, storage should be a part of kubernetes and supported natively out of the box. Today, kubernetes does not support, object, storage out of the box; it only supports file and block storage.

A

It supports file and block storage. Using a standard called csi and csi stands for container storage interface. Csi became generally available in kubernetes in the version 1.13 since then. Currently, we are on version 1.20 of kubernetes, and it's been two years now.

A

What I'm currently working on is adding object, storage support in kubernetes, we're bringing in a new api called the bucket api in object, storage. The unit of abstraction is a bucket. A bucket is a collection of objects held behind a single endpoint where modeling this bucket api is very similar to csi.

A

The bucket api is going to allow any vendor to integrate their object, storage service with kubernetes and any application workload that wishes to utilize a bucket can simply just request that bucket through standard kubernetes objects and be able to use it.

A

The bucket api supports four different calls. The first one is create bucket. The create bucket call expects the back end of the object storage provider to provision a new bucket for any workload. That's requesting it once the bucket is created. The workload then needs access to the bucket grant. Access creates a set of new credentials and provides it for the workload to access the bucket.

A

Once the application is done using a particular bucket, then the application's access to that bucket should be removed. So the third call is revoke access.

A

The final one is once that bucket is no longer in use and will not be in use by any application in the future it when it needs to be deleted. That part is also automated by this bucket api and that's the delete bucket call any vendor that satisfies these four calls can become bucket api compatible.

A

The bucket api also introduces six new objects into kubernetes. These objects or custom resources are, namely buckets, bucket access, bucket request, bucket access, request, bucket class and bucket access class.

A

These symmetric pairs of objects between buckets and the access for those buckets represents the two different types of bucket related operations we undertake, which is creating updating and deleting buckets or creating, updating and deleting access to these buckets.

A

Our proposal to add bucket api support into kubernetes was accepted on the 20th of october 2020, so it's still very new. However, our team is very dedicated and we're moving super fast, we're planning to reach alpha status by version 1.21 of kubernetes.

A

That is about four to six months from now by the end of 2021, we hope to achieve general availability.

A

I welcome everyone from my audience here to participate in the design and development of the bucket api. You can join us on our weekly calls on thursdays at 10 am pacific standard time. The zoom link for these calls can be found in the slack channel sig storage, slash cozy for container object, storage interface in the kubernetes slack. All our code, contributions are made into the github organization, kubernetes dash six and all our repositories have the prefix container dash object, storage, dash interface.

A

You can reach out to me or any of the bucket api work group members to ask questions about how to contribute or anything else related to our efforts with this. I thank you for attending my talk and I look forward to seeing you all on the thursday meeting cheers.