MinIO Adds Kubernetes Operator for Object Storage Platform
MinIO, a provider of an object-based storage platform, announced today it has added an open source Operator tool that makes it easier for IT administrators to deploy its platform on Kubernetes clusters.
In addition, MinIO has added a MinIO console based on the MinIO Operator Custom Resource Definition application programming interfaces (APIs) it created for Kubernetes clusters. That console surfaces a graphical user interface (GUI) that makes object storage in a multi-tenant Kubernetes environment accessible to IT administrators that are being asked to take on that task.
Finally, MiniIO has included a SUBNET Health multipoint inspection tool to automate root cause analysis of Kubernetes infrastructure, including all the drives, underlying networks, CPUs, memory, operating systems, containers and MinIO software components.
Anand Babu Periasamy, MinIO CEO, says one of the things that has held back adoption of stateful application deployments is the lack of a tool that makes it practical for IT administrators to deploy and manage software-defined storage on behalf of developers. While developers, in theory, could deploy object storage systems themselves, Periasamy notes that, as a practical matter, most developers still prefer to have an internal IT team manage storage because it’s not their primary area of expertise.
IT administrators have been reluctant to take on that task, because they don’t have the expertise required to work with low-level Kubernetes APIs. Graphical tools, such as Operators and MinIO console, eliminate the need for IT administrators to learn how to program just to manage storage, says Periasamy.
The MinIO Operator supports all major Kubernetes distributions, including Red Hat OpenShift, VMware vSphere 7.0 u1, SUSE Rancher, HPE Ezmeral and stock upstream, in addition to Kubernetes services provided by Amazon Web Services, Microsoft and Google. That cloud capability is critical, because IT teams want to be able to employ the same object storage system across multiple cloud to make it both easier to move data and avoid becoming locked in to a specific platform, notes Periasamy.
Despite the number of storage options organizations now have when it comes Kubernetes clusters, Periasamy says it’s clear that object storage platforms will become dominant as more organizations build and deploy stateful applications that need to both dynamically scale up and out across multiple Kubernetes clusters.
It’s not clear, however, the rate at which stateful applications are being rolled out on Kubernetes clusters. Initially, most Kubernetes clusters were employed to run stateless applications. The data these applications created was stored on storage systems external to the cluster. However, as more database platforms have become available on Kubernetes, there’s been a corresponding increase in the number of stateful applications directly accessing persistent storage on the cluster itself. A recent survey published by the Cloud Native Computing Foundation (CNCF) found 55% of respondents have now deployed stateful container applications in production environments, with another 11% planning to deploy them in the next 12 months. Another 12% are evaluating them, according to the survey.
Regardless of who winds up managing storage on Kubernetes clusters, it’s apparent the amount of data being accessed is only going to exponentially increase. The challenge now is figuring out the best way to manage it before it actually arrives.