Skip to main content
Version: 3.0

Health Check Matrix

Applicable to both Classic and Federated modes

The health check process is designed to run on your backup cluster to ensure a smooth and reliable installation or upgrade of Portworx Backup. The checks are categorized based on the operations being performed; Install or Upgrade. The following matrix helps to know more on the checks that Portworx Backup performs before install or upgrade to ensure that the prerequisites are met:

CheckPurposePre-InstallPre-Upgrade
Kubernetes version checkValidate Kubernetes version and log a warning if unsupported.✔️✔️
Namespace quota check for PVCsEnsure namespace (where Portworx Backup will be deployed) resource quota meets PVC storage requirements; fail if insufficient.✔️
Storageclass checkVerify if the specified storage class exists and it is not empty; fail installation if not found.✔️✔️
Check for existing PVCsAbort installation if stale PVCs exist and prompt cleanup. (It only aborts if the stale PVCs have the same name as the Portworx Backup PVCs. It will not abort if any other pre-existing PVCs are present in the namespace)✔️
Port information check in Helm notesChecks if the required ports are open or not and points to Network prerequisites✔️✔️
Perform health check before upgradeBlock upgrades if any critical pods are unhealthy.✔️
Delete the pxcentral-post-install-hook job before upgradeAutomatically delete the job and proceed with the upgrade. If the job is in error state, health check dumps the logs and proceeds further with the upgrade.✔️
Provide the list of warnings in an easy-to-access wayStore warnings in a ConfigMap report for the user to view them later.✔️✔️
Generate a pre-install/pre-upgrade report to show warnings and validationsSummarize validation results and warnings in a user-accessible report.✔️✔️
Provide a force install/upgrade flag (skipValidations flag)Add an override mechanism for debugging with explicit warnings.✔️✔️
Block the upgrade for unsupported pathsRestrict upgrades from versions older than n-2 to prevent failures.✔️
Block the install for file system-based provisionersValidate provisioner type and fail installation for file system-based provisioners.✔️
Block install or upgrade if the images are incorrectValidate image details in both non-airgapped and/or air-gapped clusters; block installation or upgrade for invalid repos, registries, images or tags.✔️✔️
Validate Stork Workload Identity (WLI) configuration on application clusters (Federated mode)Verify that Azure Workload Identity (WLI) is correctly configured for Stork on each application cluster via the StorageCluster (STC) CR. Confirms that the Portworx Operator has applied the required Managed Identity configuration to the Stork service account and the Azure WLI label to the Portworx namespace. Block installation if the WLI configuration is missing or incomplete.✔️
Block air-gapped installation (Federated mode)Fail installation if a custom registry (air-gapped) environment is detected. Air-gapped installation is not supported in Federated mode.✔️
Validate backup location type (Federated mode)Verify that only Azure Blob Storage backup locations are configured. Block installation if NFS or other unsupported backup location types are detected, as only Azure Blob Storage is supported in Federated mode.✔️
Block in-place upgrade from Classic mode to Federated mode (Federated mode)Prevent upgrade from an existing Classic mode deployment to Federated mode. Federated mode must be installed as a new deployment and cannot be converted from an existing Classic deployment.✔️

Retrieving health check results after a failed install or upgrade

If a Helm install or upgrade fails, the health check stores a summary of warnings and failures in a ConfigMap. To view the report, run:

kubectl get cm px-central-report -n <pxb-namespace> -o go-template='{{ index .data "report-<release_version>" }}'

Replace <release_version> with your Portworx Backup release version (for example, 3.0.0).

Use the output to map failures to the checks listed in the table above and take the corresponding corrective action before retrying the install or upgrade.