Preflight checks

What are preflight checks? Copied

Preflight checks are automated validation tests that run before installing or upgrading ITRS Analytics. They examine your Kubernetes cluster environment to identify potential issues that could affect deployment success, system stability, or performance.

• Storage configuration and performance
• Cluster resource availability
• Backup and snapshot support
• Service mesh compatibility
• Network and security settings

Each check evaluates specific conditions and reports results as pass, warning, or error. Some checks are informational and allow you to proceed with caution, while others are strict (blocking) and must be resolved before installation can continue.

When to use preflight checks Copied

Preflight checks run automatically in the following scenarios:

• Before deploying ITRS Analytics for the first time
• When updating to a new version of ITRS Analytics
• After modifying critical settings in the KOTS Admin Console
• When investigating deployment or performance issues

You can also manually trigger preflight checks from the KOTS Admin Console whenever you need to validate your environment.

How preflight checks work in ITRS Analytics Copied

When you initiate an installation or upgrade through the KOTS Admin Console, preflight checks execute automatically in the background. Here’s what happens:

1. Each check runs against your Kubernetes cluster, testing specific requirements.
2. Results are displayed in the Admin Console with clear pass/warning/error indicators.
3. Failed checks include detailed error messages and recommended actions.
4. Depending on the severity, you can either proceed (for warnings) or must resolve issues (for blocking errors).

Some preflight checks, like the Disk I/O performance test, can be configured or disabled through Advanced Settings > Preflight and Support Bundle Settings in the Admin Console. This flexibility allows you to balance thoroughness with deployment speed based on your needs.

Why preflight checks are important Copied

Preflight checks help you avoid problems by catching issues early.

• Identify insufficient resources or incompatible configurations before they cause installation to fail.
• Detect storage latency, throughput, or stability issues that could degrade system performance.
• Verify backup and snapshot capabilities are properly configured to safeguard your data.
• Catch problems in minutes rather than discovering them hours into a deployment.
• Offer specific recommendations for resolving identified issues.

By addressing preflight check findings before proceeding, you ensure a smoother deployment experience and a more stable, reliable ITRS Analytics environment.

Preflight check types Copied

The following sections describe the specific preflight checks that ITRS Analytics performs and how to interpret and address their results.

Preflight checks for Trident-based storage Copied

This ensures that the assigned storage class meets best practices and avoids potential issues that could impact stability and performance.

• Check the storage class associated with each workload. If the provisioner is csi.trident.netapp.io, validate the parameters for the presence of any of the identified issues.

• The backendType is set to ontap-nas-economy. According to Trident documentation, ontap-nas-economy is not recommended for production.

• The provisioningType is set to thin. When configured as thin, there is no strict guarantee that the requested storage will always be available.

• The snapshots parameter must be set to false. If set to true, this setting can lead to rapid disk utilization increases, potentially reaching 100% due to snapshot storage.

• Recommended actions:

  • If any of these issues are detected, update the storage class parameters accordingly.
  • Consult Trident documentation for best practices on configuring backend storage.
  • Monitor storage utilization closely, especially when enabling snapshots.

Preflight checks for Disk I/O performance Copied

The preflight Disk I/O performance check is designed to validate the performance of all configured storage classes using the fio (Flexible I/O Tester) benchmarking tool. The objective is to identify latency, throughput, or stability issues before they impact application workloads.

Note

This preflight check test uses fio to measure disk sync latency and IOPS (Input/Output Operations Per Second) by creating short-lived PVCs for each configured storage class. Enabling the Disk I/O Performance test can considerably extend the overall runtime of the preflight checks.

For each storage class, the test suite runs four predefined fio profiles, designed to simulate a broad range of I/O workloads:

• Random reads
• Random writes
• Single-path access patterns
• Multi-path access patterns

Each fio profile is configured to run for 60 seconds, resulting in a minimum test duration of 4 minutes per storage class (for example, 4 tests × 60 seconds x number of storage classes). The total runtime of the preflight check scales linearly with the number of configured storage classes in the environment.

Each storage class is evaluated against the following key Disk I/O performance metrics, along with their associated thresholds and severity levels.

Expand table

Non-strict preflight mode Copied

Preflight checks for both Warning and Error levels are currently configured in a non-strict mode. This means they will not block the installation process, allowing for greater flexibility during deployment.

Managing settings for preflight and support bundle Copied

The Disk I/O performance check is enabled by default for both preflight checks and support bundles. The configuration options for both features are available in the KOTS Admin Console under Advanced Settings > Preflight and Support Bundle Settings.

Preflight checks Copied

During system reconfiguration, the check is automatically skipped if an existing installation is detected, unless it has been explicitly enabled through configuration.

To disable this, clear the selection for the Run Disk I/O Performance Test checkbox.

Support bundle Copied

This check is managed independently using the Include Disk I/O Test for Support Bundle option. When enabled, it adds the disk performance test to the support bundle, helping capture disk latency and throughput.

It operates independently of the preflight check configuration and remains enabled by default unless explicitly disabled. To modify this setting, simply select or clear the corresponding checkbox.

Preflight checks for CSI VolumeSnapshot support in StorageClass Copied

Ensure that a given StorageClass in a Kubernetes cluster supports CSI VolumeSnapshots, which are essential for consistent backups. This check must be performed prior to initiating any backup operations to ensure support and backup consistency.

Note

ITRS Analytics support backup and restore is disabled by default. You can modify the Enable IAX backup and restore setting located under Advanced Settings > Backup and Restore in the KOTS Admin Console. For more information, see Backup and restore documentation.

Strict preflight check for CSI VolumeSnapshot support Copied

Beginning with ITRS Analytics version 2.12.6, the preflight check for CSI VolumeSnapshotClass support has been made strict (blocking) to ensure consistent and reliable backup and restore functionality. To prevent potential data loss and restore failures, this preflight check blocks installation if no supported VolumeSnapshotClass is detected.

If a compatible VolumeSnapshotClass is not found, the installation will be blocked unless you resolve the issue or explicitly disable backups in the KOTS Admin Console under Advanced Settings > Backup and Restore.

Conceptual flow and example Copied

1. Retrieve the provisioner or driver for the selected StorageClass (for example, ebs-sc).

   kubectl get storageclasses.storage.k8s.io ebs-sc -o jsonpath='{.provisioner}' 
   

2. Check for matching VolumeSnapshotClass.

   kubectl get volumesnapshotclass -o json | jq '.items[] | select(.driver == "<provisioner>") | .metadata.name'
   

If no VolumeSnapshotClass is found that matches the provisioner of the specified StorageClass, this displays the following error:

Error

The following StorageClasses do not support CSI VolumeSnapshots: <SC Name (provisioner: <provisioner>)>. Without CSI VolumeSnapshot support, consistent backups cannot be guaranteed and are not supported. To proceed with the installation, you must resolve this issue or disable the backup option in Advanced Settings under Backup and Restore.

Preflight check to verify available pod capacity Copied

This preflight check verifies that your Kubernetes cluster has enough available pod slots to successfully deploy ITRS Analytics.

The check ensures that the cluster can accommodate all required IAX components without exceeding its pod capacity or running into scheduling issues. Insufficient pod availability may lead to failed or incomplete deployments.

How it works Copied

• The preflight calculates the number of pods required based on the selected cluster size configuration.

• It then compares this value against the current available pod capacity in the Kubernetes cluster.

• If the available capacity is insufficient, the deployment will not proceed until resources are freed or the cluster capacity is increased.

Note

This is a strict preflight check. Deployment is blocked if the cluster lacks enough pod slots. The check prevents resource contention and ensures a stable, fully functional ITRS Analytics deployment.

Recommended action Copied

If the check fails:

1. Verify your cluster’s node and pod limits.
2. Scale up your cluster or free up unused resources.
3. Re-run the deployment after ensuring sufficient capacity.

Preflight check to validate Linkerd compatibility with native sidecars Copied

Beginning with ITRS Analytics 2.16.0, workloads that use native sidecars require a supported version of Linkerd.

The Linkerd native sidecars support preflight check ensures that clusters running Linkerd are compatible with ITRS Analytics workloads using native sidecars. Running the preflight check ensures that clusters with a pre-installed Linkerd meet these requirements before deployment. This prevents deployment issues caused by incompatible service mesh versions.

How it validates compatibility Copied

1. Detects Linkerd installation:

   • Searches for the linkerd-config ConfigMap in the default linkerd namespace.
   • If not found, searches across all namespaces.

2. Validates Linkerd version:

   • If Linkerd is present, its version is parsed and the proxy.nativeSidecar flag is checked. Full support requires both version 2.15.0 or later and the flag to be enabled.
   • The version is then compared against the minimum required version (2.15.0).

3. Reports compatibility:

   • If Linkerd is not installed but internal TLS is enabled, or the version is below 2.15.0, the check reports that native sidecar support is unavailable.
   • If Linkerd is version 2.15.0 or later and the proxy.nativeSidecar flag is enabled, native sidecar support is considered compatible.

In summary, here’s how it works:

Expand table