Deploy a MinIO Tenant on RedHat OpenShift

Create a Namespace

MinIO supports deploying no more than one MinIO Tenant per namespace. Create the namespace before creating the Tenant.

Check Security Context Constraints

The MinIO Operator deploys pods using the following default Security Context per pod:

securityContext:
  runAsUser: 1000
  runAsGroup: 1000
  runAsNonRoot: true
  fsGroup: 1000

Certain OpenShift Security Context Constraints limit the allowed UID or GID for a pod such that MinIO cannot deploy the Tenant successfully. Ensure that the Project in which the Operator deploys the Tenant has sufficient SCC settings that allow the default pod security context. The following command returns the optimal value for the securityContext:

oc get namespace <namespace> \
-o=jsonpath='{.metadata.annotations.openshift\.io/sa\.scc\.supplemental-groups}{"\n"}'

The command returns output similar to the following:

1056560000/10000

Take note of this value before the slash for use in this procedure.

Create Kubernetes Secrets

MinIO Root User Secret

Create an opaque secret with two data keys, where all values are base64-encoded. The MinIO Operator uses this secret for setting the root user permissions. The name of the secret must match the value specified to the spec.credsSecret.name key in the Tenant object specification.

accesskey	The access key for the root user.
secretkey	The secret key for the root user.

The value for both data keys should be a string that is long, secure, and unique. The following example YAML describes a secret that meets the stated requirements. The name minio-creds-secret assumes the tenant YAML has spec.credsSecret.name set to a matching value. Consider using the tenant name as a prefix to the secret name to ensure each tenant has its own secret key (e.g. minio-tenant-1 should have its MinIO secret named minio-tenant-1-creds-secret).

apiVersion: v1
kind: Secret
metadata:
  name: minio-creds-secret
type: Opaque
data:
  accesskey: bWluaW8=
  secretkey: bWluaW8xMjM=

MinIO Console User Secret

Create the opaque secret with four data keys, where all values are base64 encoded. The MinIO Operator uses this secret for configuring the MinIO Console access to the MinIO tenant. The name of the secret must match the value specified to the console.consoleSecret.name key in the Tenant object specification.

CONSOLE_PBKDF_PASSPHRASE	Passphrase used by the MinIO Console to encode generated authentication tokens.
CONSOLE_PBKDF_SALT	The salt used by the MinIO Console to encode generated authentication tokens.
CONSOLE_ACCESS_KEY	The access key for the MinIO Console administrative user
CONSOLE_SECRET_KEY	The corresponding secret key for the MinIO Console administrative user

The value for all data keys should be a string that is long, secure, and unique. The following example YAML describes a secret that meets the stated requirements. The name minio-console-secret assumes the tenant YAML has console.consoleSecret.name set to a matching value. Consider using the tenant name as a prefix to the secret name to ensure each tenant has its own secret key (e.g. minio-tenant-1 should have its MinIO Console secret named minio-tenant-1-console-secret)

apiVersion: v1
kind: Secret
metadata:
  name: console-secret
type: Opaque
data:
  CONSOLE_PBKDF_PASSPHRASE: U0VDUkVU
  CONSOLE_PBKDF_SALT: U0VDUkVU
  CONSOLE_ACCESS_KEY: WU9VUkNPTlNPTEVBQ0NFU1M=
  CONSOLE_SECRET_KEY: WU9VUkNPTlNPTEVTRUNSRVQ=

Create Local Persistent Volumes and Storage Class

MinIO automatically generates one Persistent Volume Claim (PVC) for each volume in the MinIO Tenant using a user-specified StorageClass.

• The cluster must have an equal number of Persistent Volumes (PV) to the number of volumes in the Tenant. MinIO strongly recommends using locally-attached storage to maximize performance and throughput.

• The storage class must have volumeBindingMode set to WaitForFirstConsumer.

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

apiVersion: v1
kind: PersistentVolume
metadata:
   name: <PV-NAME>
spec:
   capacity:
      storage: 1Ti
   volumeMode: Filesystem
   accessModes:
   - ReadWriteOnce
   persistentVolumeReclaimPolicy: Retain
   storage-class: local-storage
   local:
      path: </PATH/TO/DISK>
   nodeAffinity:
      required:
         nodeSelectorTerms:
         - matchExpressions:
            - key: kubernetes.io/hostname
               operator: In
               values:
               - <NODE-NAME>

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

1) Access the MinIO Operator Interface

You can find the MinIO Operator Interface from the Operators left-hand navigation header.

1. Go to Operators, then Installed Operators.

2. For the Project dropdown, select openshift-operators.

3. Select MinIO Operators from the list of installed operators.

Click Create Tenant to begin the Tenant Creation process.

2) Create the Tenant

The Form View provides a user interface for configuring the new MinIO Tenant.

• Ensure the Tenant Secret -> Name is set to the name of the MinIO Root User Kubernetes Secret created as part of the prerequisites.

• Ensure the Console -> Console Secret -> Name is set to the name of the MinIO Console Kubernetes Secret created as part of the prerequisites.

You can also use the YAML view to perform more granular configuration of the MinIO Tenant. Refer to the MinIO Custom Resource Definition Documentation for guidance on setting specific fields. MinIO also publishes examples for additional guidance in creating custom Tenant YAML objects. Note that the OperatorHub YAML view supports creating only the MinIO Tenant object. Do not specify any other objects as part of the YAML input.

Changes to one view are reflected in the other. For example, you can make modifications in the YAML View and see those changes in the Form View.

Click Create to create the MinIO Tenant using the specified configuration. Use the credentials specified as part of the MinIO Root User secret to access the MinIO Server.

3) Connect to the Tenant

For applications internal to the Kubernetes cluster, you can connect directly to the MinIO service created by the Operator. Use oc get svc --namespace NAMESPACE to retrieve the services for the tenant.

For applications external to the Kubernetes cluster, you must configure Ingress or a Load Balancer to expose the MinIO Tenant services. Alternatively, you can use the oc port-forward command to temporarily forward traffic from the local host to the MinIO Tenant.

• The minio service provides access to MinIO Object Storage operations.

• The *-console service provides access to the MinIO Console. The MinIO Console supports GUI administration of the MinIO Tenant.