Kubernetes is a container orchestration tool that is revolutionizing the way applications are being deployed and developed. With the rise of microservice architecture and infrastructure the coupling from the application, developers are focusing more on delivering value while building their software and applications.
With Kubernetes, developers can describe the memory and compute power they require without worrying about the underlying infrastructure. It also makes applications portable, allowing them to be deployed on multiple instances like a hybrid, public cloud, or Prem without changing the code.
However, the dynamic Kubernetes architecture (scalability, management, and portability) does not support storing state. Most production applications in Kubernetes are stateful; they require external storage to deploy applications.
In this article, you will learn about the confusing Kubernetes storage lingo while also learning about the best practices for Kubernetes storage.
Kubernetes Storage Concepts
Volumes
They are the basic entity containers that are used to access storage in Kubernetes. Volumes can support any storage infrastructure including cloud storage services, local storage devices, and NFS. You can access volumes directly from persistent volumes or pods.
Persistent storage
Kubernetes also supports persistent storage models like block storage, cloud services, object storage, and files. You can also define persistent storage as a database or data service. Referencing storage directly from within a pod violates its portability principle and is not recommended. Rather, pods should use persistent volumes and persistent volume claims for defining their storage requirements on Kubernetes.
Non-Persistent Storage
Storage in Kubernetes is temporary or nonpersistent by default. Any storage you define as a part of a container will be held in the host temporary storage space that exists only until the pod does. When the pod no longer exists, the storage is removed.
Persistent Volumes and Persistent Volume Claims (PV/PVC)
These two are supported storage implementations that allow pods to use storage in a portable way without violating the portability principle. Administrators can define storage resources, capacity, cost parameters, and performance in a persistent volume or PV. They can also define IP addresses lifestyle policy for the data, credentials, and routes. However, PVs are not portable between Kubernetes clusters.
On the other hand, a PVC or persistent volume claim describes the storage required by the application. They are portable between Kubernetes clusters and can be moved along with an application. Kubernetes first identifies the storage available in the defined persistent volume and binds the PVC to that storage if it matches the requirements.
Kubernetes Storage Best Practices
Here are the key best practices to keep in mind when managing ​​Kubernetes storage:
Limiting storage resource consumption
Placing limits on the usage of storage resources on containers reflects the number of resources they can get. You can limited storage resource consumption in one of the two ways:
Data persistence Resource quotas
They work on namespace and container levels to provide a layer of control over cluster resource usage. Resource quotas can limit the number of storage resources consumed by containers running in a namespace. You can also limit the consumption of storage resources based on individual storage classes of persistent volume claims.
StorageClasses
This method allows administrators to define the classes of storage they offer. It can also limit the amount of storage that is allocated for containers in response to a PVC.
Managing resource limit and request
Kubernetes has three types of resources: CPU, memory, and temporary storage. DevOps/IT teams can apply both hard limits (resource limits) and soft limits (resource requests) to the number of resources that containers can consume. However, Kubernetes storage resources can be managed on various levels of abstraction. Teams also can manage storage resource consumption in production.
Requests
These are what each container is guaranteed to get whenever a resource is requested. You need to keep an eye on the number of requests at any given time.
Limits
Ensure that containers never cross a certain value of resources. Limits can never be lower than Requests, and they are set on a per-container basis. When Pods have multiple containers, and since they are scheduled as a group, you have to add request and limit for each container while ensuring an aggregated value for the Pod. Also, you can set requests and limit quota at both Namespace and Container level.
Using Recommended Kubernetes volume settings
When creating a persistent volume, should follow these recommended Kubernetes documentation settings:
- Add PVCs as part of the container config.
- Avoid adding PVs in container configuration because this tightly couples your container to a specific volume.
- Do no set a default StorageClass as it will cause the PVCs to fail.
Achieving Kubernetes Storage with PortWorx
Persistent volume storage offers a convenient way for Kubernetes applications to request and consume storage resources. PVs are an ideal solution if you have data shared between pods. PortWorx’s Kubernetes native object storage delivers an efficient and consistent experience for DevOps and IT teams while running Kubernetes applications. Its end-to-end data and storage management solution for all Kubernetes projects offers disaster recovery, multi-cloud migrations, data security, container granule storage, and more.
This article gives you all the basics of Kubernetes storage and key best practices to keep in mind as you manage storage for cloud-native applications. If you’re looking for a solution that makes this entire process easy, do look at Portworx, the leading Kubernetes storage solution.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
