MinIO Kubernetes Operator

Silo is an S3-compatible object store. MinIO Operator is an upstream Kubernetes component whose repository was archived and made read-only on 2026-03-20. Its final release, v7.1.1, can manage a Silo server image through the Tenant CRD. The Operator name, API groups, CRD kinds, resource names, image names, and environment variables remain upstream contracts and are not rebranded here.

MinIO Operator installs Custom Resource Definitions (CRDs), including the Tenant kind used to describe managed object-storage workloads as Kubernetes objects.

The pinned v7.1.1 Kustomize manifest deploys the Operator in the minio-operator namespace as one minio-operator Deployment with two controller replicas. It does not deploy a separate Operator Console pod.

This site verifies the Silo image override used by its deployment examples. The archived Operator has no ongoing upstream platform-support or commercial-support commitment, and this site does not create one.

See the pinned MinIO Operator v7.1.1 CRD Reference for the upstream CRD contract.

Operator Prerequisites

Kubernetes Version

The archived v7.1.1 README requires Kubernetes 1.30.0 or later. Use a currently maintained Kubernetes release whose APIs remain compatible, and validate the exact combination in your own cluster. See the maintained Kubernetes releases and the Operator v7.1.1 release; Silo does not publish a broader Kubernetes support matrix.

Kubernetes infrastructure running end-of-life API versions may exhibit unexpected or undesired behavior if used for deploying the Operator.

Kustomize and kubectl

Kustomize is a YAML-based templating tool that allows you to define Kubernetes resources in a declarative and repeatable fashion. Kustomize is included with the kubectl command line tool.

This procedure assumes that your local host machine has both the matching version of kubectl for your Kubernetes cluster and the necessary access to that cluster to create new resources.

The pinned MinIO Operator v7.1.1 Kustomize template provides a reproducible starting point. You can modify that Kustomization file or apply your own patches for your cluster. Do not infer that a newer supported upstream release exists; review any fork or replacement independently.

Kubernetes TLS Certificate API

The MinIO Operator manages TLS Certificate Signing Requests (CSR) using the Kubernetes certificates.k8s.io TLS certificate management API to create signed TLS certificates in the following circumstances:

• When autoCert is enabled.
• For the Tenant Console when the MINIO_CONSOLE_TLS_ENABLE environment variable is set to on.
• For STS service when OPERATOR_STS_ENABLED environment variable is set to on.
• For retrieving the health of the cluster.

The MinIO Operator reads certificates inside the operator-ca-tls secret and syncs this secret within the tenant namespace to trust private certificate authorities, such as when using cert-manager.

For any of these circumstances, the MinIO Operator requires that the Kubernetes kube-controller-manager configuration include the following configuration settings:

• --cluster-signing-key-file - Specify the PEM-encoded RSA or ECDSA private key used to sign cluster-scoped certificates.
• --cluster-signing-cert-file - Specify the PEM-encoded x.509 Certificate Authority certificate used to issue cluster-scoped certificates.

The Kubernetes TLS API uses the CA signature algorithm when generating a new certificate. ECDSA (for example, the NIST P-256 curve) or EdDSA (for example, Curve25519) can require less computation than RSA. See Supported TLS Cipher Suites for the Silo server’s supported suites.

If the Kubernetes cluster is not configured to respond to a generated CSR, the Operator cannot complete initialization. Some Kubernetes providers do not specify these configuration values by default.

To check whether the kube-controller-manager specifies the cluster signing key and certificate files, use the following command:

kubectl get pod kube-controller-manager-$CLUSTERNAME-control-plane \
  -n kube-system -o yaml

• Replace $CLUSTERNAME with the name of the Kubernetes cluster.

Confirm that the output contains the highlighted lines. The output of the example command above may differ from the output in your terminal:

 spec:
 containers:
 - command:
     - kube-controller-manager
     - --allocate-node-cidrs=true
     - --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
     - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
     - --bind-address=127.0.0.1
     - --client-ca-file=/etc/kubernetes/pki/ca.crt
     - --cluster-cidr=10.244.0.0/16
     - --cluster-name=my-cluster-name
     - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
     - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
 ...