Kubernetes Cluster Build Series

This article is part of a step-by-step series on building a production-style Kubernetes cluster from scratch.

Series so far:

• Part 0 – Before You Begin (Prerequisites & Planning)

• Part 1 – Preparing Linux Nodes for Kubernetes

• Part 2 – Installing and Configuring containerd Runtime

• Part 3 – Installing Kubernetes and Bootstrapping the Cluster (kubeadm + Calico)

• Part 4 – Understanding Kubernetes DNS and CoreDNS Stability

• Part 5 – Deploying Persistent Storage with Longhorn

• Part 6 – Object Storage in Kubernetes After MinIO (Current Article)

Each part builds on the previous one, so it is recommended to follow the series in order.

---

Why object storage matters in Kubernetes?

At this point in the series, the Kubernetes cluster can already run workloads and provide persistent block storage through Longhorn. However, many modern applications also need object storage.

Object storage is useful for:

• Backups

• Application artifacts

• Log archives

• Machine learning datasets

• Kafka backups

• Static file hosting

• CI/CD pipelines

Unlike block storage, object storage is accessed through APIs such as Amazon S3.

This makes it ideal for workloads that need to store and retrieve files rather than mount a filesystem directly.

---

Why MinIO became the default choice?

For many years, MinIO was the most popular way to run S3-compatible object storage inside Kubernetes.

It became popular because it was:

• Lightweight

• Easy to deploy

• S3 compatible

• Fast

• Well documented

In my original on-prem Kubernetes setup, I also used MinIO Operator and MinIO Tenants successfully.

For a long time, this was the standard approach.

---

What changed in 2025–2026?

Starting in 2025, MinIO began shifting away from the traditional open-source model and toward its commercial AIStor offering.

The old community edition entered maintenance-only mode and stopped receiving active development. The newer AIStor platform became the primary supported path for distributed object storage deployments.

As part of this shift:

• The traditional MinIO operator workflow became outdated

• Public documentation for older tenant-based Kubernetes setups became harder to find

• New distributed deployments increasingly require AIStor licensing

• The free tier is now focused mainly on single-node usage rather than highly available Kubernetes clusters

Because of that, I no longer recommend writing or following older MinIO-on-Kubernetes tutorials without understanding these changes.

---

Is the old MinIO setup still usable?

Technically, yes.

If you already have an existing MinIO deployment running in Kubernetes, there is no immediate need to replace it. Older MinIO setups can still work for:

• Homelabs

• Test environments

• Small internal systems

However, there are tradeoffs:

• Documentation is aging (almost extinct from official sources)

• Community support is shrinking

• Future Kubernetes compatibility is uncertain

• New features and fixes are unlikely to arrive

For long-term production use, it is safer to evaluate alternatives.

---

What should you use instead?

Today, there is no single replacement for MinIO. The right choice depends on your goals.

Option 1 – Continue with MinIO AIStor

Best for:

• Enterprises

• Large on-prem clusters

• Teams that need vendor support

AIStor is now the actively developed successor to MinIO Community Edition. It supports distributed, highly available deployments and remains fully S3 compatible. However, multi-node deployments now generally require a commercial subscription.

---

Option 2 – Ceph RGW

Best for:

• Serious on-prem environments

• Teams already using Ceph

• Large storage clusters

Ceph RGW provides S3-compatible object storage as part of the Ceph ecosystem.

Pros:

• Mature

• Highly scalable

• Strong community

Cons:

• More complex to operate

• Heavier than MinIO

---

Option 3 – Garage

Best for:

• Homelabs

• Small Kubernetes clusters

• Teams wanting a lightweight distributed option

Garage is an open-source distributed object store that has become more popular as MinIO changed direction.

Pros:

• Lightweight

• Actively developed

• Distributed by default

Cons:

• Smaller ecosystem

• Less documentation than MinIO

---

Option 4 – SeaweedFS

Best for:

• Mixed storage workloads

• Clusters needing object + file storage

SeaweedFS can provide:

• Object storage

• File storage

• Distributed volumes

Pros:

• Flexible

• Efficient

• Kubernetes friendly

Cons:

• More concepts to learn

• Less commonly used than MinIO

---

My recommendation for different scenarios

Scenario	Recommended Choice
Learning / homelab	Garage or older MinIO
Small internal production	Garage or SeaweedFS
Existing MinIO users	Continue short-term, plan migration
Large enterprise on-prem	AIStor or Ceph RGW

The most important thing is not which tool you choose.

The important thing is to choose a storage platform that:

• Is actively maintained

• Matches your scale

• Has a future roadmap

---

What this series will do going forward

Because the MinIO ecosystem has changed significantly, this series will not include a step-by-step MinIO Tenant installation article.

Instead, the remaining parts of the series will assume that:

• An S3-compatible object store exists

• It can be reached from inside the cluster

• Applications can use it through standard S3 APIs

This keeps the rest of the platform architecture valid regardless of which object storage platform you choose.

---

What’s next

In the next part, we will move from storage into platform identity and deploy an authentication system inside the cluster using Keycloak.