##
We are going to make the following changes to the Object Store docs as
part of a larger QC/Content pass:
### Left Navigation
We want to modify the left navigation flow to be a natural progression
from a basic setup to more advanced.
For example:
- Core Concepts
- Deployment Architecture
- Availability and Resiliency
- Erasure Coding and Object Healing
- Object Scanner
- Site Replication and Failover
- Thresholds and Limits
- Installation
- Deployment Checklist
- Deploy MinIO on Kubernetes
- Deploy MinIO on Red Hat Linux
- Deploy MinIO on Ubuntu Linux
- Deploy MinIO for Development (MacOS, Windows, Container)
- Security and Encryption (Conceptual Overview)
- Network Encryption (TLS) (Conceptual overview)
- Enable Network Encryption using Single Domain
- Enable Network Encryption using Multiple Domains
- Enable Network Encryption using certmanager (Kubernetes only)
- Data Encryption (SSE) (Conceptual overview)
- Enable SSE using AIStor Key Management Server
- Enable SSE using KES (Summary page + linkouts)
- External Identity Management (Conceptual Overview)
- Enable External Identity management using OpenID
- Enable External Identity management using AD/LDAP
- Backup and Recovery
- Create a Multi-Site Replication Configuration
- Recovery after Hardware Failure
- Recover after drive failure
- Recover after node failure
- Recover after site failure
- Monitoring and Alerts
- Metrics and Alerting (v3 reference)
- Monitoring and Alerting using Prometheus
- Monitoring and Alerting using InfluxDB
- Monitoring and Alerting using Grafana
- Metrics V2 Reference
- Publish Server and Audit Logs to External Services
- MinIO Healthcheck API
The Administration, Developer, and Reference sections will remain as-is
for now.
http://192.241.195.202:9000/staging/singleplat/mindocs/index.html
# Goals
Maintaining multiple platforms is getting to be too much, and based on
analytics the actual number of users taking advantage of it is minimal.
Furthermore, the majority of traffic is to installation pages.
Therefore we're going to try to collapse back into a single MinIO Object
Storage product, and use simple navigation and on-page selectors to
handle Baremetal vs Kubernetes.
This may also help to eventually stage us to migrate to Hugo + Markdown
---------
Co-authored-by: Daryl White <53910321+djwfyi@users.noreply.github.com>
Co-authored-by: Rushan <rushenn@minio.io>
Co-authored-by: rushenn <rushenn123@gmail.com>
7.2 KiB
Upgrade a MinIO Tenant
minio
Table of Contents
The following procedures upgrade a single MinIO Tenant, using either Kustomize or Helm. MinIO recommends you test upgrades in a lower environment such as a Dev or QA Tenant, before upgrading production Tenants.
Important
For Tenants using a MinIO Image older than RELEASE.2024-03-30T09-41-56Z running with
AD/LDAP <minio-ldap-config-settings> enabled,
you must read through the release notes for RELEASE.2024-04-18T19-09-19Z before starting
this procedure. You must take the extra steps documented in the linked
release as part of the upgrade procedure.
Upgrade a Tenant using Kustomize
The following procedure upgrades a MinIO Tenant using Kustomize and
the kubectl CLI. If you deployed the Tenant using Helm <deploy-tenant-helm>, use the minio-upgrade-tenant-helm
procedure instead.
To upgrade a Tenant with Kustomize:
If the tenant was deployed with Operator Console, there are additional steps to create a base configuration file before upgrading.
If the tenant was deployed with Kustomize, the base configuration is
your existing kustomization files from the original tenant
deployment.
Choose a tab below depending on how the tenant was deployed:
Operator Console-Deployed Tenant
- Create the base configuration file:
In a convenient directory, save the current Tenant configuration to a file using
kubectl get:kubectl get tenant/my-tenant -n my-tenant-ns -o yaml > my-tenant-base.yamlReplace
my-tenantandmy-tenant-nswith the name and namespace of the Tenant to upgrade.Edit the file to remove the following lines:
creationTimestamp:resourceVersion:uid:selfLink:(if present)
For example, remove the highlighted lines:
metadata: creationTimestamp: "2024-05-29T21:22:20Z" generation: 1 name: my-tenant namespace: my-tenant-ns resourceVersion: "4699" uid: d5b8e468-3bed-4aa3-8ddb-dfe1ee0362daIn the same directory, create a
kustomization.yamlfile with contents resembling the following:apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - my-tenant-base.yaml patches: - path: upgrade-minio-tenant.yamlIf you used a different filename for the
kubectl getoutput in the previous step, replacemy-tenant-base.yamlwith the name of that file.
Existing Kustomized-deployed Tenant
- You can upgrade the tenant using the
kustomizationfiles from the original deployment as the base configuration. If you no longer have these files, follow the instructions in the Operator Console-Deployed Tenant tab.
- Create a
upgrade-minio-tenant.yamlfile with contents resembling the following:
apiVersion: minio.min.io/v2
kind: Tenant
metadata:
name: my-tenant
namespace: my-tenant-ns
spec:
image: minio/minio:|minio-tag|
This file instructs Kustomize to upgrade the tenant using the
specified image. The name of this file,
upgrade-minio-tenant.yaml, must match the
patches.path filename specified in the
kustomization.yaml file created in the previous step.
Replace my-tenant and my-tenant-ns with the
name and namespace of the Tenant to upgrade. Specify the MinIO version
to upgrade to in image:.
Alternatively, you can update the base configuration directly,
according to your local procedures. Refer to the Kustomize Documentation <tasks/manage-kubernetes-objects/kustomization>
for more information.
- From the same directory as the above files, apply the updated
configuration to the Tenant with
kubectl apply:
kubectl apply -k ./The output resembles the following:
tenant.minio.min.io/my-tenant configured
Upgrade the Tenant using the MinIO Helm Chart
This procedure upgrades an existing MinIO Tenant using Helm Charts.
If you deployed the Tenant using Kustomize, use the minio-upgrade-tenant-kustomize procedure instead.
Verify the existing MinIO Tenant installation.
Use
kubectl get all -n TENANT_NAMESPACEto verify the health and status of all Tenant pods and services.Use the
helm listcommand to view the installed charts in the namespace:helm list -n TENANT_NAMESPACEThe result should resemble the following:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION CHART_NAME TENANT_NAMESPACE 1 2023-11-01 15:49:58.810412732 -0400 EDT deployed tenant-5.0.x v5.0.xUpdate the Operator Repository
Use
helm repo update minio-operatorto update the MinIO Operator repo. If you set a different alias for the MinIO Operator repository, specify that to the command. You can usehelm repo listto review your installed repositories.Use
helm searchto check the latest available chart version after updating the Operator Repo:helm search repo minio-operatorThe response should resemble the following:
NAME CHART VERSION APP VERSION DESCRIPTION minio-operator/minio-operator 4.3.7 v4.3.7 A Helm chart for MinIO Operator minio-operator/operator |operator-version-stable| v|operator-version-stable| A Helm chart for MinIO Operator minio-operator/tenant |operator-version-stable| v|operator-version-stable| A Helm chart for MinIO OperatorThe
minio-operator/minio-operatoris a legacy chart and should not be installed under normal circumstances.Run
helm upgradeHelm uses the latest chart to upgrade the Tenant:
helm upgrade -n minio-tenant \ CHART_NAME minio-operator/tenantThe command results should return success with a bump in the
REVISIONvalue.Validate the Tenant Upgrade
Check that all services and pods are online and functioning normally.