MinIO Object Storage on k3s

Overview

MinIO provides an S3-compatible API for application uploads, artifacts, and local development. On a single VPS it is convenient object storage, but it is not an independent backup destination because MinIO and the workloads share the same host and disk failure domain.

When to Use It

  • Applications require an S3 API but external object storage is unavailable.
  • Development or staging needs buckets, presigned URLs, and lifecycle rules.
  • Data is reproducible or also replicated outside the VPS.

Prefer a managed S3-compatible provider for database backups, Velero backups, and irreplaceable user files.

GitOps Deployment

For one small tenant, deploy MinIO in standalone mode with a ClusterIP service, one persistent volume, explicit storage limits, and credentials from the secret manager. The MinIO Operator is more useful when managing multiple tenants or distributed MinIO clusters; it adds unnecessary controller overhead for one standalone instance.

Use separate internal and console services. Applications normally connect to http://minio.storage.svc.cluster.local:9000; keep the console on port 9001 private and access it through port-forward:

kubectl port-forward -n storage svc/minio-console 9001:9001

Verification

kubectl get pod,pvc,svc -n storage
kubectl port-forward -n storage svc/minio 9000:9000
mc alias set vps http://localhost:9000 "$ACCESS_KEY" "$SECRET_KEY"
mc mb vps/smoke-test
mc stat vps/smoke-test

Configure bucket quotas, lifecycle expiration, encryption, and alerts for disk usage. Never allow logs, metrics, Kafka retention, and MinIO objects to grow without bounds on the same disk.