Welcome to the upcoming version of the MinIO Documentation! The content of these pages may change at any time. If you can't find what you're looking for, check our legacy documentation. Thank you for your patience.

Deploy a MinIO Tenant

Overview

This page documents procedures for using either the MinIO Operator Console or the kubectl minio plugin for deploying a MinIO Tenant.

Deploy a Tenant using the MinIO Console

This procedure documents deploying a MinIO Tenant using the MinIO Operator Console.

Deploy a Tenant using the MinIO Kubernetes Plugin

This procedure documents deploying a MinIO Tenant using the MinIO Kubernetes Plugin kubectl minio.

Kubernetes administrators who require more specific customization of Tenants prior to deployment can use this tutorial to create a validated yaml resource file for further modification.

The following procedure creates a MinIO tenant using the kubectl minio plugin.

1) Initialize the MinIO Operator

kubectl minio requires the MinIO Operator. Use the kubectl minio init command to initialize the MinIO Operator:

kubectl minio init

The example command deploys the MinIO operator to the default namespace. Include the --namespace option to specify the namespace you want to deploy the MinIO operator into.

2) Configure the Persistent Volumes

MinIO automatically generates one Persistent Volume Claim (PVC) for each volume in the cluster. The cluster must have an equal number of Persistent Volumes (PV). MinIO strongly recommends using locally-attached storage to maximize performance and throughput.

The following steps create the necessary StorageClass and local Persistent Volumes (PV) resources such that each MinIO Pod and their associated storage are local to the same Node.

You can skip this step if the cluster already has local PV resources and a StorageClass configured for use by the MinIO Tenant.

a. Create a StorageClass for the MinIO local Volumes

The following YAML describes a StorageClass with the appropriate fields for use with the local PV:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

The StorageClass must have volumeBindingMode set to WaitForFirstConsumer to ensure correct binding of each pod’s Persistent Volume Claims (PVC) to the Node’s local PV.

b. Create the Required Persistent Volumes

The following YAML describes a PV local volume:

apiVersion: v1
kind: PersistentVolume
metadata:
   name: PV-NAME
spec:
   capacity:
      storage: 1Ti
   volumeMode: Filesystem
   accessModes:
   - ReadWriteOnce
   persistentVolumeReclaimPolicy: Retain
   storageClassName: local-storage
   local:
      path: /mnt/disks/ssd1
   nodeAffinity:
      required:
         nodeSelectorTerms:
         - matchExpressions:
         - key: kubernetes.io/hostname
            operator: In
            values:
            - NODE-NAME

Field

Description

 
metadata:
   name:

Set to a name that supports easy visual identification of the PV and its associated physical host. For example, for a PV on host minio-1, consider specifying minio-1-pv-1.

 
nodeAffinity:
  required:
    nodeSelectorTerms:
    - key:
        values:

Set to the name of the node on which the physical disk is installed.

 
spec:
   storageClassName:

Set to the StorageClass created for supporting the MinIO local volumes.

 
spec:
   local:
      path:

Set to the full file path of the locally-attached disk. You can specify a directory on the disk to isolate MinIO-specific data. The specified disk or directory must be empty for MinIO to start.

Create one PV for each volume in the MinIO tenant. For example, given a Kubernetes cluster with 4 Nodes with 4 locally attached drives each, create a total of 16 local PVs.

c. Validate the Created PV

Issue the kubectl get PV command to validate the created PVs:

kubectl get PV

3) Create a Namespace for the MinIO Tenant

Use the kubectl create namespace command to create a namespace for the MinIO Tenant:

kubectl create namespace minio-tenant-1

MinIO supports exactly one Tenant per namespace.

4) Create the MinIO Tenant

Use the kubectl minio tenant create command to create the MinIO Tenant. The command always uses the latest stable Docker image of the MinIO Server and MinIO Console.

The following example creates a 4-node MinIO deployment with a total capacity of 16Ti across 16 drives.

kubectl minio tenant create minio-tenant-1   \
  --servers                 4                \
  --volumes                 16               \
  --capacity                16Ti             \
  --storageClassName        local-storage    \
  --namespace               minio-tenant-1

The following table explains each argument specified to the command:

Argument

Description

minio-tenant-1

The name of the MinIO Tenant which the command creates.

--servers

The number of minio servers to deploy across the Kubernetes cluster.

--volumes

The number of volumes in the cluster. kubectl minio determines the number of volumes per server by dividing volumes by servers.

--capacity

The total capacity of the cluster. kubectl minio determines the capacity of each volume by dividing capacity by volumes.

--namespace

The Kubernetes namespace in which to deploy the MinIO Tenant.

--storageClassName

The Kubernetes StorageClass to use when creating each PVC.

On success, the command returns the following:

  • The administrative username and password for the Tenant. Store these credentials in a secure location, such as a password protected key manager. MinIO does not show these credentials again.

  • The Service created for connecting to the MinIO Console. The Console supports administrative operations on the Tenant, such as configuring Identity and Access Management (IAM) and bucket configurations.

  • The Service created for connecting to the MinIO Tenant. Applications should use this service for performing operations against the MinIO Tenant.

5) Configure Access to the Service

kubectl minio creates a service for the MinIO Tenant and MinIO Console. The output of kubectl minio tenant create includes the details for both services. You can also use kubectl get svc to retrieve the service name:

kubectl get svc --namespace minio-tenant-1

The command returns output similar to the following:

NAME                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
minio                    ClusterIP   10.109.88.X     <none>        443/TCP             137m
minio-tenant-1-console   ClusterIP   10.97.87.X      <none>        9090/TCP,9443/TCP   129m
minio-tenant-1-hl        ClusterIP   None            <none>        9000/TCP            137m

  • The minio service corresponds to the MinIO Tenant service. Applications should use this service for performing operations against the MinIO Tenant.

  • The minio-tenant-1-console service corresponds to the MinIO Console. Administrators should use this service for accessing the MinIO Console and performing administrative operations on the MinIO Tenant.

  • The minio-tenant-1-hl corresponds to a headless service used to facilitate communication between Pods in the Tenant.

By default each service is visible only within the Kubernetes cluster. Applications deployed inside the cluster can access the services using the CLUSTER-IP. For applications external to the Kubernetes cluster, you must configure the appropriate network rules to expose access to the service. Kubernetes provides multiple options for configuring external access to services. See the Kubernetes documentation on Publishing Services (ServiceTypes) and Ingress for more complete information on configuring external access to services.

You can temporarily expose each service using the kubectl port-forward utility. Run the following examples to forward traffic from the local host running kubectl to the services running inside the Kubernetes cluster.

MinIO Tenant

MinIO Console

kubectl port-forward service/minio 443:443

kubectl port-forward service/minio-tenant-1-console 9443:9443
©2020, MinIO