Announcing the MinIO Kubernetes Operator and Operator Console

Object-storage-as-a-service is a game changer for IT.

For the better part of a decade, IT has watched as developers provisioned object storage for emerging applications on the public cloud - driving much of the adoption of this medium.

This creates many well-known issues for IT. This is not a simple control issue, it is a broader and much more critical governance issue with regard to security, compliance, budget and overall alignment.

The primary driver for developers turning to the public cloud was simply that IT couldn’t provision multi-tenant object storage as a service. While IT was adept at archival object storage and was able to protect the crown jewels when it came to data, they simply didn’t have the skill set to create, deploy, tune, scale and manage modern, application oriented object storage using Kubernetes.

Kubernetes Native DNA

MinIO is purpose-built to take full advantage of the Kubernetes architecture. Created from scratch in the last five years, MinIO has known nothing but containers and orchestration - it is simply how we think.  As a result, MinIO and Kubernetes work together to simplify infrastructure management, providing a way to manage object storage infrastructure within the Kubernetes toolset.  

The new Operator and Operator Console graphical user interface are an important evolution in our approach. They solve a key problem for IT (getting them going on Kubernetes) while further simplifying object storage for developers - without sacrificing granularity or control in the process.

The operator pattern extends Kubernetes's familiar declarative API model with custom resource definitions (CRDs) to perform common operations like resource orchestration, non-disruptive upgrades, cluster expansion and to maintain high-availability - operations that were previously handled in a Helm chart.

MinIO Kubernetes Operator

There are two components at play here: Operator and Operator Console.

First, there is the Operator. The Operator uses the command set kubectl that the Kubernetes community was already familiar with and adds the kubectl minio plugin . The MinIO Operator and the MinIO kubectl plugin facilitate the deployment and management of MinIO Object Storage on Kubernetes - which is how multi-tenant object storage as a service is delivered.

Examples include:

• deploying an application on demand
• taking and restoring backups of that application's state
• handling upgrades of the application code alongside related changes such as database schemas or extra configuration settings
• publishing a Service to applications that don't support Kubernetes APIs to discover them
• simulating failure in all or part of your cluster to test its resilience
• choosing a leader for a distributed application without an internal member election process
  

The Operator is inherently a command line proposition, but merely providing an Operator wasn’t our goal. MinIO goes further to simplify creation, deployment and management of Kubernetes native object storage with a straightforward list of commands that make it easy to execute all of the key capabilities outlined above.

The Operator Console makes Kubernetes object storage easier still. In this graphical user interface, MinIO created something so simple that anyone in the organization can create, deploy and manage object storage as a service.

Regardless of your chosen interface, Operator or Operator Console, the functionality is effectively the same. The result is an Operator experience that can be used to deploy MinIO on any Kubernetes distribution, be it OpenShift, vSphere 7.0U1, Rancher or stock upstream.

The Tenant Mentality

The primary unit of managing MinIO on Kubernetes is the tenant. The best way to think about tenancy is to start with the Kubernetes cluster. The MinIO Operator can allocate multiple tenants within the same Kubernetes cluster. Each tenant, in turn, can have different capacity (i.e: a small 500GB tenant vs a 100TB tenant), resources (1000m CPU and 4Gi RAM vs 4000m CPU and 16Gi RAM) and servers (4 pods vs 16 pods), as well a separate configurations regarding Identity Providers, Encryption and versions.

In multi-tenant configurations, each tenant is a cluster of server pools (independent sets of nodes with their own compute, network, and storage resources), that, while sharing the same physical infrastructure, are fully isolated from each other in their own namespaces. Each tenant runs their own MinIO cluster, fully isolated from other tenants giving them the ability to protect them from any disruption on upgrade, update, security incidents. Each tenant scales independently by federating clusters across geographies.

Since the server binary is fast and lightweight, MinIO's operator is able to densely co-locate several tenants and use resources efficiently.

In the spirit of Kubernetes everywhere, MinIO runs on any public cloud provider such as Amazon's EKS (Elastic Kubernetes Engine), Google's GKE (Google Kubernetes Engine), Google's Anthos or Azure's AKS (Azure Kubernetes Service).

Kubernetes Object Storage for Everyone

With the introduction of the Operator and the browser-based Operator Console, MinIO has delivered a material upgrade to its already strong Kubernetes story. Now, without even knowing how to spell Kubernetes, IT administrators can provision multi-tenant object storage as a service across hybrid cloud environments.

Get started and download MinIO! We have a tutorial, Simplifying Object Storage as a Service with Kubernetes and MinIO’s Operator, that can help you take the first steps. As always, if you have any questions to join our Slack Channel or drop us a note at hello@min.io. We are here to help you - whichever interface option you select.