Upgrade MinIO AIStor on Kubernetes (Helm)
This page provides guidance for upgrading MinIO AIStor Helm clusters on Kubernetes infrastructure.
Overview
MinIO AIStor Helm installations consist of two primary components:
- Operator Chart - Controls resources like CustomResourceDefinitions and core operator functionality
- Object Store Chart - Deploys and manages MinIO AIStor instances
Upgrades involve updating these charts and deploying new container images. The exact procedure depends on your cluster environment’s network configuration and registry access.
All MinIO AIStor software supports non-disruptive upgrades with zero downtime. In optimal environments, cluster-wide upgrades typically complete in under 500 milliseconds with large clusters (1000+ nodes) completing in less than 5 seconds.
S3 SDKs and applications typically implement retry mechanisms that mitigate the impact of any reduced availability.
Prerequisites
Before upgrading in any environment:
- Review the upgrade prerequisites
- Back up your existing Helm configurations
- Ensure you have a valid, current MinIO AIStor license
- Verify the health of your current cluster
- Review release notes for breaking changes
See the scenario-specific guides above for detailed prerequisites and step-by-step instructions.
Choose your cluster scenario
Select the upgrade guide that matches your environment:
Common upgrade concepts
Regardless of your cluster scenario, MinIO AIStor upgrades follow this general workflow:
- Update Operator Chart - Upgrade the operator chart and deploy the new operator image
- Update Object Store Chart - Upgrade the object store chart and deploy new object store images
- Bump the API version - Synchronize the API version across all nodes after the upgrade
You can also upgrade only the MinIO AIStor Object Store image version without updating the chart itself if you only need to update the running software version.
The image-only shortcut above applies to the MinIO AIStor Object Store image, not to the operator.
Always upgrade the operator through its Helm chart. That chart owns the operator’s RBAC (its ClusterRole and bindings) and the CustomResourceDefinitions, and keeps them in sync with the operator version. If you replace only the operator image and leave the chart in place, those resources stay at the previous version.
When a newer operator needs permissions or CRD fields that the older chart never created, the operator cannot finish syncing its informer caches. Its reconcile workers never start, and object store rollouts stall until you upgrade to the matching operator chart.