Kubernetes Native Storage: What It Is, How It Works, and Why It Drives Digital Transformation

Managing enterprise data is a time-consuming and arduous process which can slow down company growth. What’s more is DevOps pipelines are riddled with stages and between each stage is a gap of time wasted while data is reassembled, copied, replicated, moved, and migrated. Kubernetes Native Storage eliminates those gaps by moving data instantly in space and time while driving enterprise-wide digital transformation. This access to data — where and when you need it — saves dozens of painstaking pipeline hours per week in wait time.

But how exactly does Kubernetes Native Storage (K8sNS) work? What makes this technology so disruptive? We’ve put together a 4-part video series that provides an in-depth technical overview of K8sNS, what it is, how it works, and why it drives digital transformation. Continue reading for a summary of each video module and learn the unique characteristics of Kubernetes Native Storage.

Module 1: How the Magic Happens

In module 1, we uncover the “what” of Kubernetes Native Storage. At its core, K8sNS is a container-native storage (CNS) software solution. However, unlike other CNS, ionir has unique and powerful capabilities such as the ability to move data anywhere in 40 seconds or less. Additionally, K8sNS enables users to instantly access data as it existed at any point in time, regardless of volume size, in just a few seconds.

ionir K8sNS provides data agility in light of a K8s environment by augmenting the strength of an enterprise-class storage platform with the extensibility, flexibility, and future-proofing of a Kubernetes (K8s) microservices application.

Built using Kubernetes architecture and approaches, K8sNS eliminates the effects of data gravity. How? Essentially, Kubernetes Native Storage is a familiar kind of CNS virtualization platform but with distinctive characteristics. Traditional storage systems access data by location where data is stored. ionir breaks this mold, addressing data by what it’s called — its name. This enables data to be viewed as code, enabling DevOps teams to access the data they want, when they want it.

Furthermore, a proprietary metadata structure separates logical access from physical location. Typically, applications might access solid state disks located in the servers running the K8s nodes. This limits adaptability and agility. Instead, ionir collects that storage capacity into a virtual pool and then presents logical volumes to the applications. Separating the control plane from the data plane in this way gives you the ability to achieve:

• Continuous data protection
• Moving data from one place to another
• Global deduplication
• Automated tiering

For a closer look at how Kubernetes Native Storage separates location from name in the addressing of data, watch the 10-minute in-depth Module 1 here.

Module 2: Explore the Application of ionir’s Secret Sauce

As you know, Kubernetes Native Storage can move any volume of data across distances and clusters in 40 seconds or less. Keep in mind, removing location allows data mobility of place. Thus, data can be moved to any new place without affecting the requesting application. There are many benefits of data mobility. For example, the ability to move data instantly can eliminate as much as 40 hours from a single CI/CD deployment. Module 2 explains in-depth how this is possible.

In this video, we take a descriptive look at an example where a volume that exists in Washington, D.C. is copied all the way across the pond to Dublin, Ireland in less than 40 seconds. Basically, there are four simple steps involved in copying data to a new location:

1. Establish another metadata set for Volume 1 – Dublin
2. Copy “hot blocks” to Dublin to seed Volume 1
3. New writes are stored in Dublin immediately
4. Volume 1 rehydrates in background — the priority of updates is driven by a block level heatmap

Ultimately, K8sNS creates a volume that’s fully accessible in Dublin in 40 seconds or less by creating a metadata recipe for it, seeding it with the hottest read blocks that will be accessed first, and then very quickly filling in the background blocks as it rehydrates. Another great aspect of K8sNS is rehydration speed is policy controlled. Therefore, users can control the speed of the update.

To see a volume of data copied across a distance to a new location with Kubernetes Native Storage, watch Module 2 here.

Module 3: How ionir Instantly Creates Clones of Data

Data can be presented at any point in time simply by adjusting the metadata to include only blocks from that time. Data mobility in time is possible by storing time as a function of metadata. A timestamp is added to the metadata address, which allows us to present volumes as they existed in the past simply by ignoring writes that occurred after a chosen moment.

In module 3, we delve into how ionir instantly creates clones of data as it existed at any point in time. Why is this even necessary? Data mobility in time can fix issues in situations where the newer write contained malware or a bug and could have destroyed the entire data set. In just three simple steps, Kubernetes Native Storage can eliminate 99% of wasted wait time, enabling developers to be more productive, less frustrated, and spend their time engaged in value-add tasks.

Below are the steps to instantly clone and access data at any point in time:

1. Request (5:00:01)
2. Create a new metadata recipe — Washington, D.C. Volume 1 (5:00:01)
3. Ignore newly written blocks received after 05:00:01

Take a look at Module 3 here to watch as we use Kubernetes Native Storage to go back in time to access data as it was just five minutes ago.

Module 4: Microservices-Based Architecture

Microservices architecture is 100% adaptable and serves as the foundation of Kubernetes Native Storage — ensuring agility and flexibility throughout the storage platform. Modern microservices architecture enables rapid, linear scaling and extensibility of data, allowing developers to build new components of applications to meet the changing demands of their customers.

Module 4 dives deep into microservices architecture, what it is and how it works. There are three components of ionir microservices architecture: the Pitcher, the Catcher, and the Keeper.

The main purpose of the Pitcher is to maintain and update the most recent view of logical objects and generate a worldwide, unique name for the data. Essentially, the Pitcher can be viewed as the gateway from an application to the rest of the system.

Next is the Catcher, the heart of the system. The Catcher orchestrates tiering decisions and determines where data should be stored on physical blocks. It stores and manages metadata by saving the name of the data along with the context and time.

Finally, we have the Keeper. The Keeper is the interface to the storage and media as it aggregates media resources of the same type and manages them as a single pool. Additionally, the Keeper stores data on media, supports the retrieval of the data by name, de-duplicates data, and maintains redundancy across the managed pool.

For a more granular look into how microservices architecture creates a future-proofing approach to Kubernetes Native Storage, check out Module 4 here.

Final Thoughts

When viewed together, these four modules provide a clearer picture of the power, flexibility, and extensibility of Kubernetes Native Storage. By eliminating data gravity, Kubernetes data is able to move at the speed of applications. Full volumes, regardless of size or amount of data, are transported across clouds or across the world in 40 seconds or less. The time saved enables a 500x acceleration of deployments through the CI/CD pipeline. So, why wait? Reduce wait time pain in the deployment pipeline and become more agile with Kubernetes Native Storage.

Schedule a demo with our team to see how ionir Kubernetes Native Storage unlocks efficiencies speeding new features into competitive markets faster than your competition.