Skip to content

Preflight Checks

A set of automated preflight checks is executed during cluster provisioning to ensure that nodes and the environment meet minimum requirements and are free from configuration conflicts.

Preflight validations are performed at two stages:

  1. Platform-level environment validation
  2. Node-level validation during Conjurer installation (MKS)

Platform-Level Preflight Checks

The following checks validate node readiness and environmental compatibility:

# Description
1 Verify that the node is running a supported OS and version
2 Verify minimum CPU resources
3 Verify minimum memory resources
4 Verify outbound internet connectivity
5 Verify connectivity to the Controller
6 Verify DNS lookup resolution for the Controller
7 Verify time synchronization with NTP
8 Verify minimum and compatible storage availability
9 Detect presence of firewall
10 Detect existing Kubernetes installation
11 Validate hostname format (underscore not supported)
12 Check if port 53 is already in use
13 Detect wildcard entries in DNS search domains

Node-Level Preflight Checks During Conjurer Installation (MKS)

When creating an MKS cluster, the Conjurer installation command is executed on the selected nodes:

  • In the UI workflow, the command is executed on the node.
  • When using rctl, installation is triggered automatically through the rctl apply command.

As part of this process, additional validations are performed to ensure that the node does not contain residual Kubernetes artifacts or conflicting configurations.

Validations Performed

# Pre-Check
1 Verify presence of kubeadmjoin file and previous join history
2 Verify Salt Minion and Chisel configuration files do not contain a different Minion/Edge ID
3 Check for installed Kubernetes-related binaries
4 Check common installation locations for Kubernetes components
5 Check for running Kubernetes services
6 Check for Kubernetes configuration files
7 Check for running or exited Kubernetes-related processes or containers
8 Check for existing CNI artifacts and network interfaces

These validations prevent installation failures caused by:

  • Previously installed Kubernetes components
  • Residual CNI configurations
  • Existing container runtime artifacts
  • Port conflicts (for example, ports 53 or 6443 already in use)
  • Prior incomplete cluster join attempts

Idempotent Behavior

The preflight validation process is idempotent.

If Conjurer installation fails due to reasons unrelated to configuration conflicts (for example, a transient network issue), retrying the installation does not cause the validations to block execution unnecessarily.

Only genuine conflicts or residual artifacts result in warnings or fatal errors.

Example 1: Successful Preflight Execution

In a successful scenario:

  • All checks pass
  • No fatal errors are detected
  • Node installation proceeds

Example output:

[+] Checking for Fatal errors
[+] No Fatal Errors... Continuing
[+] Initiating cluster node install
[+] Successfully performed all operations

Example 2: Failed Preflight Execution

If conflicts are detected, installation is halted with explicit error messages.

Common fatal scenarios include:

  • Previously installed Kubernetes packages (kubectl, kubeadm, kubelet, etc.)
  • Existing Kubernetes configuration directories (/etc/kubernetes, /var/lib/kubelet, etc.)
  • Detected container runtime binaries
  • Existing CNI network interfaces (for example, calico, vxlan)
  • Port conflicts (for example, port 53 or 6443 already in use)

Example output:

[+] Detected following fatal errors during the above checks
!ERROR: Detected a previously installed version of Kubernetes on this node.
!ERROR: Detected containerd binary on this node.
!ERROR: Port 53 is already in use.

Note: Conflicting components must be removed before retrying installation.