Kubernetes: Overcoming Complexity

Kubernetes was created in 2014 to allow administrators to run distributed systems easily. Thanks to its 100% open source nature, it can run both on-premises and in the cloud, including public, hybrid, and multi-cloud environments.

Kubernetes has seen rapid adoption since its introduction. As it is built specially to deal with containers at scale, it is both fast and lightweight, can be used on top of any VM or bare metal server, and provides robust container-centric features. Kubernetes can run equally well on any VM infrastructure, which is huge from a DevOps perspective, as the portability of containers should be equally matched by the portability of the container manager.

For all of its advantages, Kubernetes presents unique challenges. Running stateful services such as databases on Kubernetes requires specific container-native storage systems. Without this technology, certain issues will become commonplace: stuck volumes, downtime, overprovisioning, lost data, and manual backups and migrations.

Below we outline the hardware challenges that make Kubernetes so hard, let’s look at what organizations need to do to create a successful deployment.

What Does Kubernetes Storage Need to Do?

To be successful, storage for Kubernetes requires six core features (see Figure 1):

Self-service: The ability to provision and manage the container-granular storage as needed, on-demand.

Application-aware: Kubernetes-based applications are composed of multiple containers that run across a fleet of hosts. This means that storage operations such as backup, recovery, DR, and encryption must be applied at the application-granular level, not the machine level, as is the case with traditional storage.

Automation: A layer that can carry out the details around storage implementation, as well as other operations that need to occur, such as BC/DR. Automation removes most manual processing and provides key advantages.

Infrastructure-agnostic SLAs: A consistent level of service no matter which infrastructure is being leveraged, or, not binding SLAs directly to any portion of the infrastructure, such as platform services.

Cost Optimization: Puts processes in place that can improve cost efficiencies. This includes automation of provisioning systems to ensure that no more storage is being allocated than needed.

How to Fulfill Requirements

Below are the key attributes of best-of-breed Kubernetes-native storage systems and their proper application into production.

Kubernetes-native: A subsystem, including storage and database systems, that is purpose-built for the Kubernetes platform. For instance, storage operations must be container-granular with additional operations at the namespace-level.

Kubernetes-scale performance: The storage typically must be scalable to 1,000-plus volumes per node, and thousands of concurrent operations per minute. Non-Kubernetes storage systems are often designed to handle a relatively small number of large volumes managed by an administrator, as opposed to a large number of small to medium volumes managed automatically via Kubernetes.

Application-focused: The storage must take an application or solution focus, as opposed to an infrastructure focus. Container-granular storage should be able to be provisioned on-demand when the application is deployed.

Comprehensive Kubernetes native storage stack: The ability to support both transactional- and analytic-oriented storage systems, including focusing on performance, BC/DR, data security, and data compliance, as well as the ability to support real-time backup as presented in Figure 2.

Getting It Right

There are many ways to solve Kubernetes storage, and most will work in proof-of-concept environments. However, most will not be optimal for the solution set you seek. Picking the right path is imperative to the total success of your Kubernetes-based applications where storage is on the critical path. The paths available to you can be seen in Figure 3.

Traditional approaches to storage: These systems are not Kubernetes-aware, but Kubernetes-based applications can leverage them. These typically come in two forms: native storage systems for on-premises systems, or a cloud-delivered storage system such as cloud block storage, an object-based storage system, or a cloud-native database.

Container orchestration-native: More often called Kubernetes-native, these storage systems are purpose-built for a specific container orchestration engine.

This Kubernetes-native approach does not require a translation layer between VM storage and container storage, as the traditional approach does. Thus, many of the requirements and features highlighted above are supported by this container orchestration-native approach and core Kubernetes-native storage technology.

Hybrid storage solutions: These provide support for both native and non-native Kubernetes storage. They are typically not the solution of choice, given that you are trying to be all things to two or more different platforms.

Conclusion

Kubernetes is changing the way distributed systems are run and is opening up new possibilities for cloud-based databases, but to make the most of this technology, the system has to support its core needs.

Storage systems are not complex core systems, but they require special consideration given their impact on the applications and business systems that leverage them. The movement to multi-cloud and container orchestration creates an incentive to move to Kubernetes-native storage.

from Gigaom https://gigaom.com/2020/07/10/kubernetes-overcoming-complexity/