Operations on SILO

cert-manager for Operator

Mon, 01 Jan 0001 00:00:00 +0000

MinIO Operator manages TLS certificate issuing for the services hosted in the minio-operator namespace.

This page describes how to manage the Operator’s TLS certificates with cert-manager.

Prerequisites

A supported version of Kubernetes.
kustomize installed
kubectl access to your k8s cluster
Completed the steps to set up cert-manager
The MinIO Operator must not yet be installed.

1) Create a CA Issuer for the `minio-operator` namespace

This guide disables the automatic generation of certificates in MinIO Operator and issues certificates using cert-manager instead.

Deploy a MinIO Tenant

Mon, 01 Jan 0001 00:00:00 +0000

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

Deploying Single-Node topologies requires additional configurations not covered in this documentation. You can alternatively use a simple Kubernetes YAML object to describe a Single-Node topology for local testing and evaluation as necessary. MinIO does not recommend nor support single-node deployment topologies for production environments.

This documentation assumes familiarity with all referenced Kubernetes concepts, utilities, and procedures. While this documentation may provide guidance for configuring or deploying Kubernetes-related resources on a best-effort basis, it is not a replacement for the official Kubernetes Documentation.

Deploy MinIO on RedHat Linux

Mon, 01 Jan 0001 00:00:00 +0000

This page documents deploying MinIO on RedHat Linux operating systems, including distributions that are binary-compatible with RHEL. This page makes no distinction or special remarks between RHEL and those distributions, and guidance given for RHEL can typically be applied to those distributions.

MinIO strongly recommends that production deployments use RHEL versions in the Full Support or Maintenance Support phases of the Red Hat life cycle. At the time of writing, that includes:

Deploy Operator With Helm

Mon, 01 Jan 0001 00:00:00 +0000

Overview

Helm is a tool for automating the deployment of applications to Kubernetes clusters. A Helm chart is a set of YAML files, templates, and other files that define the deployment details. The following procedure uses a Helm Chart to install the MinIO Kubernetes Operator to a Kubernetes cluster.

Prerequisites

See the Operator Prerequisites for a baseline of requirements. Helm installations have the following additional requirements:

Helm (Use the Version appropriate for your Kubernetes API version)
yq

For more about Operator installation requirements, including supported Kubernetes versions and TLS certificates, see the Operator deployment prerequisites.

cert-manager for Tenants

Mon, 01 Jan 0001 00:00:00 +0000

The following procedures create and apply the resources necessary to use cert-manager for the TLS certificates within a tenant.

Note

The procedures use tenant-1 as the name of the tenant.

Replace the string tenant-1 throughout the procedures to reflect the name of your tenant.

Prerequisites

kustomize installed
kubectl access to your k8s cluster
Completed the steps to set up cert-manager
The MinIO Operator installed and set up for cert-manager.

1) Create the tenant namespace CA Issuer

Before deploying a new tenant, create a Certificate Authority and Issuer for the tenant’s namespace.

Deploy a MinIO Tenant with Helm Charts

Mon, 01 Jan 0001 00:00:00 +0000

Overview

This procedure requires the Kubernetes cluster have a valid Operator deployment. You cannot use the MinIO Operator Tenant chart to deploy a Tenant independent of the Operator.

Deploy MinIO on Ubuntu Linux

Mon, 01 Jan 0001 00:00:00 +0000

This page documents deploying MinIO on Ubuntu Linux operating systems.

MinIO officially supports Ubuntu Long Term Support (LTS) releases in the Standard or Ubuntu Pro support phases of the Ubuntu life cycle. MinIO strongly recommends only those releases that include the Linux 5.X kernel and above for best performance. At the time of writing, that includes:

Ubuntu 24.04+ LTS (Noble Numbat) (Recommended)
Ubuntu 22.04+ LTS (Jammy Jellyfish)
Ubuntu 20.04+ LTS (Focal Fossa)
Ubuntu 18.04.5 LTS (Bionic Beaver) (Ubuntu Pro Only)

The above list assumes your organization has the necessary service contracts with Ubuntu to ensure end-to-end supportability throughout the release’s lifespan.

Site Replication Overview

Mon, 01 Jan 0001 00:00:00 +0000

Site replication configures multiple independent MinIO deployments as a cluster of replicas called peer sites.

A site replication deployment with two peer sites. A load balancer manages routing operations to either of the two sites. Data written to one site automatically replicates to the other peer site.

Site replication assumes the use of either the included MinIO identity provider (IDP) or an external IDP. All configured deployments must use the same IDP. Deployments using an external IDP must use the same configuration across sites.

Upgrade a MinIO Deployment

Mon, 01 Jan 0001 00:00:00 +0000

Important

For deployments older than RELEASE.2024-03-30T09-41-56Z running with AD/LDAP enabled, you must read through the release notes for RELEASE.2024-04-18T19-09-19Z before starting this procedure. You must take the extra steps documented in the linked release as part of the upgrade.

MinIO uses an update-then-restart methodology for upgrading a deployment to a newer release:

Update the MinIO binary with the newer release.
Restart the deployment using mc admin service restart.

This procedure does not require taking downtime and is non-disruptive to ongoing operations.

Upgrade MinIO Operator

Mon, 01 Jan 0001 00:00:00 +0000

You can upgrade the MinIO Operator at any time without impacting your managed MinIO Tenants.

As part of the upgrade process, the Operator may update and restart Tenants to support changes to the MinIO Custom Resource Definition (CRD). These changes require no action on the part of any operator or administrator, and do not impact Tenant operations.

This page describes how to upgrade from Operator 5.0.15 to 7.1.1. See Upgrade MinIO Operator 4.5.8 and Later to 5.0.15 for instructions on upgrading to Operator 5.0.15 before starting this procedure.

Deploy MinIO as a Container

Mon, 01 Jan 0001 00:00:00 +0000

This page documents deploying MinIO as a Container onto any operating system that supports containerized processes.

This documentation assumes installation of Docker, Podman, or a similar runtime which supports the standard container image format. MinIO images use Red Hat Universal Base Image 9 Micro.

Functionality and performance of the MinIO container may be constrained by the base OS.

The procedure includes guidance for deploying Single-Node Multi-Drive (SNMD) and Single-Node Single-Drive (SNSD) topologies in support of early development and evaluation environments.

Expand a Distributed MinIO Deployment

Mon, 01 Jan 0001 00:00:00 +0000

MinIO supports expanding an existing distributed deployment by adding a new Server Pool. Each Pool expands the total available storage capacity of the cluster.

Expansion does not provide Business Continuity/Disaster Recovery (BC/DR)-grade protections. While each pool is an independent set of servers with distinct erasure sets for availability, the complete loss of one pool results in MinIO stopping I/O for all pools in the deployment. Similarly, an erasure set which loses quorum in one pool represents data loss of objects stored in that set, regardless of the number of other erasure sets or pools.

Modify a MinIO Tenant

Mon, 01 Jan 0001 00:00:00 +0000

You can modify tenants after deployment to change mutable configuration settings. See MinIO Custom Resource Definition for a complete description of available settings in the MinIO Custom Resource Definition.

The method for modifying the Tenant depends on how you deployed the tenant:

For Kustomize-deployed Tenants, you can modify the base Kustomization resources and apply them using kubectl apply -k against the directory containing the kustomization.yaml object.

Decommission Server Pools

Mon, 01 Jan 0001 00:00:00 +0000

MinIO supports decommissioning and removing server pools from a deployment with two or more pools. To decommission, there must be at least one remaining pool with sufficient available space to receive the objects from the decommissioned pools.

Starting with RELEASE.2023-01-18T04-36-38Z, MinIO supports queueing multiple pools in a single decommission command. Each listed pool immediately enters a read-only status, but draining occurs one pool at a time.

Decommissioning is designed for removing an older server pool whose hardware is no longer sufficient or performant compared to the pools in the deployment. MinIO automatically migrates data from the decommissioned pools to the remaining pools in the deployment based on the ratio of free space available in each pool.

Deploy MinIO on MacOS

Mon, 01 Jan 0001 00:00:00 +0000

This page documents deploying MinIO onto Apple MacOS hosts.

MinIO officially supports MacOS operating systems in service status, which is typically 3 years from initial release. At the time of writing, that includes:

macOS 14 (Sonoma) (Recommended)
macOS 13 (Ventura)
macOS 12 (Monterey)

MinIO may run on older or out-of-support macOS releases, with limited support or troubleshooting from either MinIO or RedHat.

Upgrade a MinIO Tenant

Mon, 01 Jan 0001 00:00:00 +0000

The following procedures upgrade a single MinIO Tenant, using either Kustomize or Helm. MinIO recommends you test upgrades in a lower environment such as a Dev or QA Tenant, before upgrading production Tenants.

Important

For Tenants using a MinIO Image older than RELEASE.2024-03-30T09-41-56Z running with AD/LDAP enabled, you must read through the release notes for RELEASE.2024-04-18T19-09-19Z before starting this procedure. You must take the extra steps documented in the linked release as part of the upgrade procedure.

Deploy MinIO on Windows

Mon, 01 Jan 0001 00:00:00 +0000

This page documents deploying MinIO onto Microsoft Windows hosts.

MinIO officially supports Windows operating systems in the Active Support of the Microsoft Modern Lifecycle Policy.

At the time of writing, that includes:

Windows Server 23H2 (Recommended)
Windows Server 2022 LTSC
Windows 11 Enterprise/Workstation 23H2
Windows 11 Enterprise/Workstation 22H2
Windows 10 Enterprise 21H2 (LTS)
Windows 10 IoT 21H2 (LTS)
Windows 10 Enterprise 22H2

MinIO may run on older or out-of-support Windows releases, with limited support or troubleshooting from either MinIO or Microsoft.

Expand a MinIO Tenant

Mon, 01 Jan 0001 00:00:00 +0000

This procedure documents expanding the available storage capacity of an existing MinIO tenant by deploying an additional pool of MinIO pods in the Kubernetes infrastructure.

Important

The MinIO Operator Console is deprecated and removed in Operator 6.0.0.

See Modify a MinIO Tenant for instructions on migrating Tenants installed via the Operator Console to Kustomization.

Prerequisites

MinIO Kubernetes Operator

This procedure on this page requires a valid installation of the MinIO Kubernetes Operator and assumes the local host has a matching installation of the MinIO Kubernetes Operator. This procedure assumes the latest stable Operator, version 7.1.1.

Migrate from Gateway or Filesystem Mode

Mon, 01 Jan 0001 00:00:00 +0000

Background

The MinIO Gateway and the related filesystem mode entered a feature freeze in July 2020. In February 2022, MinIO announced the deprecation of the MinIO Gateway. Along with the deprecation announcement, MinIO also announced that the feature would be removed in six months time.

As of RELEASE.2022-10-29T06-21-33Z, the MinIO Gateway and the related filesystem mode code have been removed. Deployments still using the standalone or filesystem MinIO modes that upgrade to MinIO Server RELEASE.2022-10-29T06-21-33Z or later receive an error when attempting to start MinIO.

Delete a MinIO Tenant

Mon, 01 Jan 0001 00:00:00 +0000

Prerequisites

MinIO Kubernetes Operator

This procedures on this page requires a valid installation of the MinIO Kubernetes Operator and assumes the local host has a matching installation of the MinIO Kubernetes Operator. This procedure assumes the latest stable Operator, version 7.1.1.

See Deploy MinIO on Kubernetes for complete documentation on deploying the MinIO Operator.

Tenant Persistent Volume Claims

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

Upgrade Legacy MinIO Operators

Mon, 01 Jan 0001 00:00:00 +0000

MinIO supports the following upgrade paths for older versions of the MinIO Operator:

Current Version	Supported Upgrade Target
5.0.15 or later	7.1.1
5.0.0 to 5.0.14	5.0.15
4.2.3 to 4.5.7	4.5.8
4.0.0 through 4.2.2	4.2.3
3.X.X	4.2.2

To upgrade from Operator to 7.1.1 from version 4.5.7 or earlier, you must first upgrade to version 4.5.8, then upgrade to 5.0.15. Depending on your current version, you may need to do one or more intermediate upgrades to reach v4.5.8.

Operations on SILO

cert-manager for Operator

Prerequisites

1) Create a CA Issuer for the minio-operator namespace

Deploy a MinIO Tenant

Deploy MinIO on RedHat Linux

Deploy Operator With Helm

Overview

Prerequisites

cert-manager for Tenants

Prerequisites

1) Create the tenant namespace CA Issuer

Deploy a MinIO Tenant with Helm Charts

Overview

Deploy MinIO on Ubuntu Linux

Site Replication Overview

Upgrade a MinIO Deployment

Upgrade MinIO Operator

Deploy MinIO as a Container

Expand a Distributed MinIO Deployment

Modify a MinIO Tenant

Decommission Server Pools

Deploy MinIO on MacOS

Upgrade a MinIO Tenant

Deploy MinIO on Windows

Expand a MinIO Tenant

Prerequisites

MinIO Kubernetes Operator

Migrate from Gateway or Filesystem Mode

Background

Delete a MinIO Tenant

Prerequisites

MinIO Kubernetes Operator

Tenant Persistent Volume Claims

Upgrade Legacy MinIO Operators

1) Create a CA Issuer for the `minio-operator` namespace