Upgrade MinIO Operator to v4.5.8
To upgrade from Operator to 5.0.15 from version 4.5.7 or earlier, you must first upgrade to version 4.5.8. Depending on your current version, you may need to do one or more intermediate upgrades to reach v4.5.8.
The following table lists the upgrade paths for older versions of MinIO Operator:
Current Version |
Supported Upgrade Target |
---|---|
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 |
Upgrade MinIO Operator 4.2.3 through 4.5.7 to 4.5.8
Prerequisites
This procedure requires the following:
You have an existing MinIO Operator deployment running 4.2.3 through 4.5.7
Your Kubernetes cluster runs 1.19.0 or later
Your local host has
kubectl
installed and configured with access to the Kubernetes cluster
Procedure
This procedure upgrades MinIO Operator release 4.2.3 through 4.5.7 to release 4.5.8. You can then upgrade from release 4.5.8 to 5.0.15.
(Optional) Update each MinIO Tenant to the latest stable MinIO Version.
Upgrading MinIO regularly ensures your Tenants have the latest features and performance improvements.
Test upgrades in a lower environment such as a Dev or QA Tenant, before applying to your production Tenants.
See Upgrade a MinIO Tenant for a procedure on upgrading MinIO Tenants.
Verify the existing Operator installation.
Use
kubectl get all -n minio-operator
to verify the health and status of all Operator pods and services.If you installed the Operator to a custom namespace, specify that namespace as
-n <NAMESPACE>
.You can verify the currently installed Operator version by retrieving the object specification for an operator pod in the namespace. The following example uses the
jq
tool to filter the necessary information fromkubectl
:kubectl get pod -l 'name=minio-operator' -n minio-operator -o json | jq '.items[0].spec.containers'
The output resembles the following:
{ "env": [ { "name": "CLUSTER_DOMAIN", "value": "cluster.local" } ], "image": "minio/operator:v4.5.1", "imagePullPolicy": "IfNotPresent", "name": "minio-operator" }
Download the Latest Stable Version of the MinIO Kubernetes Plugin
You can install the MinIO plugin using either the Kubernetes Krew plugin manager or manually by downloading and installing the plugin binary to your local host:
Krew is a
kubectl
plugin manager developed by the Kubernetes SIG CLI group. See thekrew
installation documentation for specific instructions. You can use the Krew plugin for Linux, macOS, and Windows operating systems.You can use Krew to install the MinIO
kubectl
plugin using the following commands:kubectl krew update kubectl krew install minio
If you want to update the MinIO plugin with Krew, use the following command:
kubectl krew upgrade minio
You can download the MinIO
kubectl
plugin to your local system path. Thekubectl
CLI automatically discovers and runs compatible plugins.The following code downloads the most recent version of the MinIO Kubernetes plugin and installs it to the system path:
curl https://github.com/minio/operator/releases/download/v5.0.14/kubectl-minio_5.0.14_linux_amd64 -o kubectl-minio chmod +x kubectl-minio mv kubectl-minio /usr/local/bin/
The
mv
command above may requiresudo
escalation depending on the permissions of the authenticated user.Run the following command to verify installation of the plugin:
kubectl minio version
The output should display the Operator version as 5.0.14.
You can download the MinIO
kubectl
plugin to your local system path. Thekubectl
CLI automatically discovers and runs compatible plugins.The following PowerShell command downloads the most recent version of the MinIO Kubernetes plugin and installs it to the system path:
Invoke-WebRequest -Uri "https://github.com/minio/operator/releases/download/v5.0.14/kubectl-minio_5.0.14_windows_amd64.exe" -OutFile "C:\kubectl-plugins\kubectl-minio.exe"
Ensure the path to the plugin folder is included in the Windows PATH.
Run the following command to verify installation of the plugin:
kubectl minio version
The output should display the Operator version as 5.0.14.
Run the initialization command to upgrade the Operator
Use the
kubectl minio init
command to upgrade the existing MinIO Operator installationkubectl minio init
Validate the Operator upgrade
You can check the Operator version by reviewing the object specification for an Operator Pod using a previous step.
Port Forwarding
The Operator Console service does not automatically bind or expose itself for external access on the Kubernetes cluster. Instead, configure a network control plane component, such as a load balancer or ingress, to grant external access.
For testing purposes or short-term access, expose the Operator Console service through a NodePort using the following patch:
kubectl patch service -n minio-operator console -p ' { "spec": { "ports": [ { "name": "http", "port": 9090, "protocol": "TCP", "targetPort": 9090, "nodePort": 30090 }, { "name": "https", "port": 9443, "protocol": "TCP", "targetPort": 9443, "nodePort": 30433 } ], "type": "NodePort" } }'
The patch command should output
service/console patched
. You can now access the service through ports30433
(HTTPS) or30090
(HTTP) on any of your Kubernetes worker nodes.For example, a Kubernetes cluster with the following Operator nodes might be accessed at
https://172.18.0.2:30443
:kubectl get nodes -o custom-columns=IP:.status.addresses[:] IP map[address:172.18.0.5 type:InternalIP],map[address:k3d-MINIO-agent-3 type:Hostname] map[address:172.18.0.6 type:InternalIP],map[address:k3d-MINIO-agent-2 type:Hostname] map[address:172.18.0.2 type:InternalIP],map[address:k3d-MINIO-server-0 type:Hostname] map[address:172.18.0.4 type:InternalIP],map[address:k3d-MINIO-agent-1 type:Hostname] map[address:172.18.0.3 type:InternalIP],map[address:k3d-MINIO-agent-0 type:Hostname]
Use the following command to retrieve the JWT token necessary for logging into the Operator Console:
kubectl get secret/console-sa-secret -n minio-operator -o json | jq -r '.data.token' | base64 -d
If your local host does not have the
jq
utility installed, you can run thekubectl
part of this command (before| jq
) and locate thedata.token
section of the output.
Upgrade MinIO Operator 4.0.0 through 4.2.2 to 4.2.3
Prerequisites
This procedure assumes that:
You have an existing MinIO Operator deployment running any release from 4.0.0 through 4.2.2
Your Kubernetes cluster runs 1.19.0 or later
Your local host has
kubectl
installed and configured with access to the Kubernetes cluster
Procedure
This procedure covers the necessary steps to upgrade a MinIO Operator deployment running any release from 4.0.0 through 4.2.2 to 4.2.3. You can then perform Upgrade MinIO Operator 4.5.8 and Later to 5.0.15 to complete the upgrade to 5.0.15.
There is no direct upgrade path for 4.0.0 - 4.2.2 installations to 5.0.15.
(Optional) Update each MinIO Tenant to the latest stable MinIO Version.
Upgrading MinIO regularly ensures your Tenants have the latest features and performance improvements. Test upgrades in a lower environment such as a Dev or QA Tenant, before applying to your production Tenants.
See Upgrade a MinIO Tenant for a procedure on upgrading MinIO Tenants.
Check the Security Context for each Tenant Pool
Use the following command to validate the specification for each managed MinIO Tenant:
kubectl get tenants <TENANT-NAME> -n <TENANT-NAMESPACE> -o yaml
If the
spec.pools.securityContext
field does not exist for a Tenant, the tenant pods likely run as root.As part of the 4.2.3 and later series, pods run with a limited permission set enforced as part of the Operator upgrade. However, Tenants running pods as root may fail to start due to the security context mismatch. You can set an explicit Security Context that allows pods to run as root for those Tenants:
securityContext: runAsUser: 0 runAsGroup: 0 runAsNonRoot: false fsGroup: 0
You can use the following command to edit the tenant and apply the changes:
kubectl edit tenants <TENANT-NAME> -n <TENANT-NAMESPACE> # Modify the securityContext as needed
See Pod Security Standards for more information on Kubernetes Security Contexts.
Upgrade to Operator 4.2.3
Download the MinIO Kubernetes Plugin 4.2.3 and use it to upgrade the Operator. Open https://github.com/minio/operator/releases/tag/v4.2.3 in a browser and download the binary that corresponds to your local host OS.
For example, Linux hosts running an Intel or AMD processor can run the following commands:
wget https://github.com/minio/operator/releases/download/v4.2.3/kubectl-minio_4.2.3_linux_amd64 -o kubectl-minio_4.2.3 chmod +x kubectl-minio_4.2.3 ./kubectl-minio_4.2.3 init
Validate all Tenants and Operator pods
Check the Operator and MinIO Tenant namespaces to ensure all pods and services started successfully.
For example:
kubectl get all -n minio-operator kubectl get pods -l "v1.min.io/tenant" --all-namespaces
Upgrade to 5.0.15
Follow the Upgrade MinIO Operator 4.5.8 and Later to 5.0.15 procedure to upgrade to the latest stable Operator version.
Upgrade MinIO Operator 3.0.0 through 3.0.29 to 4.2.2
Prerequisites
This procedure assumes that:
You have an existing MinIO Operator deployment running 3.X.X
Your Kubernetes cluster runs 1.19.0 or later
Your local host has
kubectl
installed and configured with access to the Kubernetes cluster
Procedure
This procedure covers the necessary steps to upgrade a MinIO Operator deployment running any release from 3.0.0 through 3.2.9 to 4.2.2. You can then perform Upgrade MinIO Operator 4.0.0 through 4.2.2 to 4.2.3, followed by Upgrade MinIO Operator 4.5.8 and Later to 5.0.15.
There is no direct upgrade path from a 3.X.X series installation to 5.0.15.
(Optional) Update each MinIO Tenant to the latest stable MinIO Version.
Upgrading MinIO regularly ensures your Tenants have the latest features and performance improvements.
Test upgrades in a lower environment such as a Dev or QA Tenant, before applying to your production Tenants.
See Upgrade a MinIO Tenant for a procedure on upgrading MinIO Tenants.
Validate the Tenant
tenant.spec.zones
valuesUse the following command to validate the specification for each managed MinIO Tenant:
kubectl get tenants <TENANT-NAME> -n <TENANT-NAMESPACE> -o yaml
Ensure each
tenant.spec.zones
element has aname
field set to the name for that zone. Each zone must have a unique name for that Tenant, such aszone-0
andzone-1
for the first and second zones respectively.Ensure each
tenant.spec.zones
has an explicitsecurityContext
describing the permission set with which pods run in the cluster.
The following example tenant YAML fragment sets the specified fields:
image: "minio/minio:$(LATEST-VERSION)" ... zones: - servers: 4 name: "zone-0" volumesPerServer: 4 volumeClaimTemplate: metadata: name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Ti securityContext: runAsUser: 0 runAsGroup: 0 runAsNonRoot: false fsGroup: 0 - servers: 4 name: "zone-1" volumesPerServer: 4 volumeClaimTemplate: metadata: name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Ti securityContext: runAsUser: 0 runAsGroup: 0 runAsNonRoot: false fsGroup: 0
You can use the following command to edit the tenant and apply the changes:
kubectl edit tenants <TENANT-NAME> -n <TENANT-NAMESPACE>
Upgrade to Operator 4.2.2
Download the MinIO Kubernetes Plugin 4.2.2 and use it to upgrade the Operator. Open https://github.com/minio/operator/releases/tag/v4.2.2 in a browser and download the binary that corresponds to your local host OS. For example, Linux hosts running an Intel or AMD processor can run the following commands:
wget https://github.com/minio/operator/releases/download/v4.2.3/kubectl-minio_4.2.2_linux_amd64 -o kubectl-minio_4.2.2 chmod +x kubectl-minio_4.2.2 ./kubectl-minio_4.2.2 init
Validate all Tenants and Operator pods
Check the Operator and MinIO Tenant namespaces to ensure all pods and services started successfully.
For example:
kubectl get all -n minio-operator kubectl get pods -l "v1.min.io/tenant" --all-namespaces
Upgrade to 4.2.3
Follow the Upgrade MinIO Operator 4.0.0 through 4.2.2 to 4.2.3 procedure to upgrade to Operator 4.2.3. You can then upgrade to 5.0.15.