Shulou(Shulou.com)06/02 Report--

Anyone who has been following the cloud computing space in recent years must know about the rise of Docker and Kubernetes. Today, the world's public cloud giants (Google, Amazon, Microsoft, Huawei Cloud, Alibaba Cloud, etc.) offer hosted Kubernetes services on top of their traditional public cloud services. Kubernetes is powerful and scalable, and in the eyes of many, it is becoming the ultimate solution for cloud computing.

But it has to be said that although Kubernetes is built on Google's more than 15 years of experience running workloads in production environments, it is very complex and some design decisions are always difficult for users to understand. Even for the most experienced engineers, Kubernetes has a steep learning curve.

Take storage for example. Do you know the difference between PV and PVC? What is the relationship between storage class and provisioner? What are VolumeClaimTemplates? When should I use a statefulset?

In this article, I will try to explain some of the key concepts in Kubernetes and what I think of them. I hope this will also help you learn more about Kubernetes. When using Kubernetes, there are many design choices and caveats that surprise me. Today I'm going to talk about PV, PVC, Storage Class, and Provisioner.

Volume in Docker

Before we dive into Kubernetes, let's talk about Docker-Kubernetes is built on top of Docker, after all.

Docker is known for its simplicity and ease of use, which is why Docker has become so popular and the foundation of Kubernetes. Docker containers are stateless, fast, and can be destroyed and rebuilt without much cost. But, just like people suffering from amnesia, it is very difficult to remember meaningful things. Whether it's a database, a key-value store, or some raw data, each one needs persistent storage.

Creating persistent storage in Docker is simple. In earlier versions, users could use-v to create a new anonymous empty volume of undefined size or to create a bound mount in a directory on the host. At that time, although it was easy to mount directories that were already mounted on hosts by storage vendors, there was no third-party interface to help you mount them directly to Docker. Docker released v1.8 in August 2015, officially introducing volume plugins that allow third parties to connect to their storage solutions. Docker calls installed volume plugins to create/delete/mount/unmount/get/list those volumes, and each volume has a name, and the framework of volume plugins remains largely unchanged to this day.

Persistent volumes and persistent volume declarations

When you're trying to figure out how to create persistent storage in Kubernetes, you might come across two concepts: Persistent Volume (PV) and Persistent Volume Claim (PVC).

What are they? Which of them is closer to the volume in Docker?

In fact, none of them look like volumes in Docker. In addition to PV and PVC, Kubernetes also has a concept of Volume, but it differs from the concept in Docker, which we'll discuss later.

If you know something about PV and PVC, you might realize that PV is the allocated storage and PVC is the request to use that storage. If you've had previous experience with cloud computing or storage, you might think of PV as a storage pool and PVC as a volume split from the storage pool.

However, this is not the true meaning of PV and PVC, in Kubernetes, a PV maps to a PVC and vice versa, it is a one-to-one mapping.

I've explained these questions many times to people with extensive storage and cloud computing experience, and they're almost always scratching their heads and wondering what's going on.

And when I first encountered these two concepts, I couldn't understand them either.

We list PV and PVC definitions here

Persistent Volume (PV) is an administrator-configured piece of storage in a cluster. It is a resource in the cluster, just as a node is a cluster resource. PV is a volume plug-in such as Volumes, but its lifecycle is independent of any pod that uses PV. This API object captures details of implementing storage, including NFS, iSCSI, or specifically cloud service vendor-specific storage systems.

Persistent Volume Claim (PVC) is a user request for storage. It is similar to a pod, where a pod consumes node resources and a PVC consumes PV resources. Pods can request specific levels of resources (CPU and content), while Claims can request specific sizes and access patterns (e.g., read/write once or read only multiple times).

Note the difference between "administrator" and "user."

In short, Kubernetes divides the basic unit of storage into two concepts. PV is a storage that should be pre-allocated by an administrator, while PVC is a user request for storage.

That is, Kubernetes expects administrators to implement the assignment of PV of various sizes. When a user creates a PVC to request storage, Kubernetes will attempt to match that PVC to a pre-assigned PV. If a match can be found, the PVC is bound to the PV and the user can begin using the pre-allocated storage.

This approach differs from traditional approaches, where administrators are not responsible for allocating each storage space. All they need to do is grant users access to a storage pool, determine what their quota is, and then let them split the storage they want out of the pool.

However, in Kubernetes 'design, PV has been split from the storage pool, waiting to match PVC, so users can only request a fixed amount of pre-allocated storage space. Two things happen:

If the user only needs a 1 GiB volume and the minimum PV available is 1TiB, then the user must use this 1TiB volume. This leaves the volume unavailable to other users who may require more than 1 GiB of capacity. Not only does this result in wasted storage space, but it can also lead to situations where some workloads cannot be started due to resource constraints, while others may be hogging resources that are not needed.

To solve the first problem, administrators either need to constantly communicate with users to determine the storage size/performance they need, or predict demand and pre-allocate PV accordingly.

This makes it difficult to enforce separate allocation (PV) and use (PVC). In actual use, I don't see people talking about PV and PVC as their design approach. It is likely that the administrator quickly relinquishes the right to create PV and delegates it to the user for execution. Since PV and PVC are still bound one-to-one, the presence of PVC becomes less necessary.

In my opinion, examples using PV and PVC are uncommon to say the least.

Storage Class and Provisioner

Perhaps because PV and PVC are too cumbersome to use, Kubernetes introduced the concepts of dynamic provisioning, Storage Class and Provisioner with the release of v1.6 in March 2017. Dynamic nanotubes are similar to traditional storage methods. Administrators can use Storage Class to describe the storage "class" they provide. Storage Classes can have different capacity limits, different IOPS, or other parameters supported by the Provider. Storage vendor-specific Provisioners are used in conjunction with Storage Class to automatically assign PV based on parameters set in the Storage Class object. Additionally, Provisioner is now able to enforce user quotes and permission requirements. In this design, administrators have been freed from the hassle of predicting and assigning PV, which makes more sense.

Alternatively, you can use Storage Class without creating Storage Class objects in Kubernetes. Since Storage Class is also a field for PVCs and PVs (which do not have to be created by the Provisioner), you can manually create a PV with a custom Storage Class name and then create a PVC that requests the same Storage Class name. Kubernetes binds PVCs to PVs with the same storage class name, even if the Storage Class object does not exist.

Dynamic provisioning, Storage Class, and Provisioner make a lot of sense to me, solving the biggest usability issues in the original PV and PVC designs. But at the same time, these new concepts exacerbate another problem with Kubernetes storage, namely the confusion caused by the various ways persistent storage is handled. In the next article in this series, we'll share volumes and persistent storage in Kubernetes, so stay tuned!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.