Deploy a MinIO Tenant
Table of Contents
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
|
nodeAffinity:
required:
nodeSelectorTerms:
- key:
values:
|
Set to the name of the node on which the physical disk is installed. |
spec:
storageClassName:
|
Set to the |
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
.
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 |
---|---|
The name of the MinIO Tenant which the command creates. |
|
The number of |
|
The number of volumes in the cluster. |
|
The total capacity of the cluster. |
|
The Kubernetes namespace in which to deploy the MinIO Tenant. |
|
The Kubernetes |
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.
kubectl port-forward service/minio 443:443
kubectl port-forward service/minio-tenant-1-console 9443:9443