Upgrade on Kubernetes using a Helm chart

Note

Before upgrading from MSR 3.0.0 to a later patch version, you must verify that you are running cert-manager 1.7.2 or later:

helm history cert-manager

To upgrade cert-manager to version 1.12.3:

helm upgrade cert-manager jetstack/cert-manager \
  --version 1.12.3 \
  --set installCRDs=true

Tip

Third-party components are not upgraded alongside MSR, which means they can become vulnerable to security breaches and exploits. To mitigate this risk, Mirantis strongly recommends upgrading cert-manager and Postgres Operator before proceeding with the MSR upgrade.

Run the following command to upgrade cert-manager and Postgres Operator:

helm upgrade cert-manager cert-manager \
     --repo https://charts.jetstack.io \
     --version <version> \
     --set installCRDs=true

helm upgrade postgres-operator postgres-operator \
     --repo https://opensource.zalando.com/postgres-operator/charts/postgres-operator/ \
     --version <version> \
     --set configKubernetes.spilo_runasuser=101 \
     --set configKubernetes.spilo_runasgroup=103 \
     --set configKubernetes.spilo_fsgroup=103

Important

Mirantis has transitioned to an OCI-based Helm registry for registry.mirantis.com. As a result, Helm repository management is no longer required. Commands that rely on Helm repository operations, such as helm repo update and helm upgrade, will fail with HTTP 4xx errors.

For both new installations and upgrades, use the OCI-based registry URL directly. To check for available upgrades, run helm upgrade --dry-run without specifying a version.

For more details, see the Helm documentation.

To upgrade to a new MSR version:

  1. Run the helm upgrade command:

    helm upgrade msr oci://registry.mirantis.com/msr/helm/msr --version <helm-chart-version> --set-file license=path/to/file/license.lic
    
  2. Verify the installation of all MSR components.

    1. Verify that each Pod is in the Running state:

      kubectl get pods
      
    2. Troubleshoot any failing Pods by running the following command on each failed Pod:

      kubectl describe <pod-name>
      
    3. Optional. Review the Pod logs for more detailed results:

      kubectl logs <pod-name>