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.

Manage a MinIO Tenant

Table of Contents

Overview
Expand a MinIO Tenant
Upgrade a MinIO Tenant
Delete a MinIO Tenant

Overview

This page documents several common procedures for managing an existing MinIO Tenant.

Expand a MinIO Tenant

This procedure documents expanding a MinIO Tenant by adding a new Pool of MinIO Pods and storage resources.

1) Configure the Persistent Volumes

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

The following steps create the necessary 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 configured for use by the MinIO Tenant.

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 new Pool. For example, given a Kubernetes cluster with 4 available nodes with 4 locally attached drives, create a total of 16 local PVs.

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

kubectl get PV

2) Expand the MinIO Tenant

Use the kubectl minio tenant expand command to create the MinIO Tenant.

The following example expands a MinIO Tenant with a Pool consisting of 4 Nodes with 4 locally-attached drives of 1Ti each:

kubectl minio tenant expand minio-tenant-1   \
  --servers                 4                \
  --volumes                 16               \
  --capacity                16Ti             \
  --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.

3) Validate the Expanded MinIO Tenant

Use the kubectl minio tenant info command to return a summary of the MinIO Tenant, including the new Pool:

kubectl minio tenant info minio-tenant-1 \
  --namespace minio-tenant-1

Upgrade a MinIO Tenant

This procedure documents upgrading pods running on a MinIO Tenant.

1) Validate the Active MinIO Version

Use the kubectl minio tenant info command to return a summary of the MinIO Tenant, including the new Pool:

kubectl minio tenant info TENANT_NAME \
  --namespace TENANT_NAMESPACE

Replace TENANT_NAME with the name of the Tenant.
Replace TENANT_NAMESPACE with the namespace of the Tenant.

The output includes the version of the MinIO Server used by all Pods in the Tenant.

2) Upgrade the MinIO Tenant

Use the kubectl minio tenant upgrade command to upgrade the Docker image used by all MinIO Pods in the Tenant. MinIO upgrades all minio server processes at once. This may result in downtime until the upgrade process completes.

kubectl minio tenant upgrade TENANT_NAME \
  --image     minio:minio:RELEASE:YYYY-MM-DDTHH-MM-SSZ    \
  --namespace TENANT_NAMESPACE                              \

Replace TENANT_NAME with the name of the Tenant.
Replace RELEASE:YYYY-MM-DDTHH-MM-SSZ with the specific release to use. Specify minio/minio to use the latest stable version of MinIO.
Replace TENANT_NAMESPACE with the namespace of the Tenant.

See MinIO Tags for a list of release tags. MinIO Releases use RELEASE:YYYY-MM-DDTHH-MM-SSZ format.

Delete a MinIO Tenant

Use the kubectl minio tenant delete command to delete a MinIO Tenant and its associated resources.

The delete behavior of each Persistent Volume Claims (PVC) generated by the Tenant depends on the Reclaim Policy of its bound Persistent Volume (PV):

For recycle or delete policies, the command deletes the PVC.
For retain, the command retains the PVC.

Deletion of the underlying PV, whether automatic or manual, results in the loss of any objects stored on the MinIO Tenant. Perform all due diligence in ensuring the safety of stored data prior to deleting the Tenant.

kubectl minio tenant delete TENANT_NAME \
  --namespace TENANT_NAMESPACE

Replace TENANT_NAME with the name of the Tenant.
Replace TENANT_NAMESPACE with the namespace of the Tenant.

The command includes a confirmation prompt that requires explicit approval of the delete operation.