Node Preprocessing

Before installing the global cluster, all nodes (control plane nodes and worker nodes) must complete preprocessing.

INFO

This page applies to nodes running a traditional operating system such as RHEL, CentOS, or Ubuntu, which provisions over SSH. Several of the checks below — for example the SSH user and the /etc/ssh/sshd_config settings — exist to keep the SSH-based node join working.

Supported OS and Kernel Versions

The following table lists the supported operating systems, their validated versions, and the corresponding tested kernel versions.

The platform enforces strict version matching policies for official support:

  • OS Version (x.y.z): Patch versions (z) can vary, but major and minor versions (x and y) must strictly match the validated versions. Modifying x or y is not officially supported.
  • Kernel Version (x.y.z-build): The build suffix (build) can vary, but the core kernel version (x.y.z) must strictly match the tested versions. Modifying x.y.z is not officially supported. When the list names an operating system release without a kernel value, use the official kernel shipped with that release.
INFO
  • Only the kernel version shipped with the official operating system is supported. If the OS, kernel version, or CPU architecture does not meet the requirements, please contact technical support.
  • Kylin V10, V10-SP1, and V10-SP2 have known kernel issues that may cause NodePort network access failures, it is recommended to upgrade to Kylin V10 SP3.
  • When using Kylin V10 SP3, it is recommended to use kernel build 4.19.90-89.11.v2401 or later.

x86

Red Hat Enterprise Linux (RHEL)
CentOS
Ubuntu
Kylin Linux Advanced Server
  • RHEL 7.8: 3.10.0-1127.el7.x86_64
  • RHEL 8.0 to 8.6: 4.18.0-80.el8.x86_64 and 4.18.0-372.9.1.el8.x86_64
  • RHEL 8.10: 4.18.0-553
  • RHEL 9.6: 5.14.0-570.12.1

Note: RHEL 7.8 does not support Calico Vxlan IPv6.

ARM

Kylin Linux Advanced Server
  • Kylin V10 SP3 2403: 4.19.90-89.11.v2401.ky10.aarch64
  • Kylin V11 2503: official kernel shipped with the release

Note: ARM architecture only supports Kunpeng 920. For other models, please contact technical support.

Execute the Quick Configuration Script

The installation package provides a script for quickly configuring nodes.

Unzip the installation package to obtain the init.sh script file in the res directory. Copy the script file to the nodes and ensure that you have root privileges.

Execute the script:

bash init.sh
WARNING

init.sh cannot guarantee that all of the following checks are properly handled. You still need to continue with the steps below.

Node Checks

The following lists all the checks that must be completed on the nodes. Depending on the node's role, the required checks will vary. For example, some checks apply only to control plane nodes.

Checks are divided into two categories:

  • ✅ Indicates a check that must pass.
  • ⚠️ Indicates a check that must be met in specific scenarios. Please determine whether the corresponding conditions are met according to the instructions. If they are, you must resolve them.

The following is the list of checks:

  • OS and Kernel

    • ✅ The machine's grub boot configuration must have the transparent_hugepage=never parameter.
    • ✅ CentOS 7.x system machine's grub boot configuration must have the cgroup.memory=nokmem parameter.
    • ✅ Check whether the kernel modules ip_vs, ip_vs_rr, ip_vs_wrr, and ip_vs_sh are enabled.
    • ⚠️ When the kernel version is lower than 4.19.0 (or RHEL is lower than 4.18.0), check whether the kernel modules nf_conntrack_ipv4 and (for IPv6) nf_conntrack_ipv6 are enabled.
    • ⚠️ If the global cluster plans to use Kube-OVN CNI, the kernel modules geneve and openvswitch must be enabled.
    • ✅ SELinux and AppArmor must be disabled. They cannot be kept enabled on a node that runs a traditional operating system; see Why SELinux and AppArmor Must Be Disabled.
    • ✅ The host firewall must be disabled, unless your security policy requires it to stay enabled. In that case the node must be configured as described in Hardened Node Security Configuration before you install the platform.
      • init.sh disables the host firewall. To keep it enabled, pass the matching --skip- argument to init.sh instead of turning it back on afterwards.
      • Keeping the host firewall enabled is a non-default configuration. The platform does not manage the traditional operating system, so an enabled host firewall can cause unexpected failures on the node or in the cluster. You are responsible for operating and troubleshooting the nodes in this configuration.
      • When the host firewall is enabled, you configure and maintain the port rules on every node. For the ports that the platform requires, see Communication Matrix.
    • ✅ Disable swap .
  • Users and Permissions

    • ✅ The node's SSH user has root privileges and can use sudo without the password.
    • ✅ The UseDNS parameter in /etc/ssh/sshd_config must be set to no.
    • ✅ Set the UsePAM parameter in /etc/ssh/sshd_config to no before adding the node, then restart sshd. PAM session policies (such as a forced password change, pam_access, faillock, or pam_limits) can otherwise block the SSH-based node join. After the node reaches the Ready state, you can restore UsePAM yes. On SELinux-enforcing systems that use password authentication, UsePAM no can itself break SSH login; use key-based authentication in that case.
    • systemctl show --property=DefaultTasksMax must return infinity; a low limit (such as the 512 default on RHEL 7 / CentOS 7) makes busy containers fail to create threads. If it is not infinity, set DefaultTasksMax=infinity in /etc/systemd/system.conf and run systemctl daemon-reexec.
  • Node Network

    • hostname must comply with the following rules:
      • No more than 36 characters.
      • Starts and ends with a letter or number.
      • Contains only lowercase letters, numbers, -, and ., but cannot contain .-, .., or -..
    • localhost in /etc/hosts must resolve to 127.0.0.1.
    • ✅ The /etc/resolv.conf file must exist and contain nameserver configurations, but must not contain addresses starting with 172 (disable systemd-resolved).
    • ⚠️ The /etc/resolv.conf file should not configure search domains (if you must configure them, see Configure Search Domain).
    • ✅ The machine's IP address cannot be a loopback, multicast, link-local, all-0, or broadcast address.
    • ✅ Executing ip route must return a default route or a route pointing to 0.0.0.0.
    • ✅ The nodes must not occupy the following ports:
      • Control plane nodes: 2379, 2380, 6443, 10249 ~ 10256
      • Node where the installer is located: 8080, 12080, 12443, 16443, 2379, 2380, 6443, 10249 ~ 10256
      • Worker nodes: 10249 ~ 10256
    • ✅ If the cluster uses Kube-OVN or Calico, ensure that the following ports are not occupied:
      • Kube-OVN: 6641, 6642
      • Calico: 179
    • ⚠️ Ensure that the IP addresses in the network segment 172.17.x.x ~ 172.18.x.x required by nerdctl are not occupied. If the IPs in this network segment are occupied and cannot be changed, please contact technical support.
  • Software and Directory Requirements:

    • ✅ Must have the following installed: ip, ss, tar, swapoff, modprobe, sysctl, md5sum, and scp or sftp.
    • ⚠️ If you plan to use local storage TopoLVM or Rook, you need to install lvm2.
    • ✅ The /etc/systemd/system/kubelet.service file is not allowed to exist.
    • /tmp mount parameters must not contain noexec.
    • ✅ Remove packages that conflict with global cluster components (see Remove Conflicting Packages).
    • ✅ The following files must be deleted if they exist:
      • /var/lib/docker
      • /var/lib/nerdctl
      • /opt/nerdctl/
      • /var/lib/containerd
      • /var/log/pods
      • /var/lib/kubelet/pki
  • Cross-Node Checks

    • ✅ There must be no network firewall restrictions between nodes in the global cluster.
    • ✅ The hostname of each node in the cluster must be unique.
    • ✅ The time zones of all nodes must be unified, and the time synchronization error must be ≤ 10 seconds.

Appendix

Why SELinux and AppArmor Must Be Disabled

On a node that runs a traditional operating system, SELinux and AppArmor must be disabled. This is a platform requirement for this release, not a hardening recommendation. init.sh disables both, and the node join procedure disables them again when a node joins a cluster.

SELinux. Platform components mount host paths into containers. The image registry installer bind-mounts the host /proc/mounts file into its container, and the registry and object storage components keep their data under host directories such as /cpaas and /etc/kubernetes, which carry the operating system's default file labels. On a traditional operating system the container runtime is configured without SELinux labeling, so these mounts are evaluated against the host policy, and they are denied when SELinux runs in enforcing mode. The container runtime then fails to create the container before its process starts, the image registry component never finishes installing, and the platform installation or upgrade stops.

permissive mode is not an alternative: it changes what is logged, not the requirement. A node that is switched back to enforcing after the installation is outside the supported configuration.

AppArmor. Node preparation disables AppArmor, and the platform is not validated with AppArmor profiles enforced on cluster nodes. Running a node with AppArmor enabled is outside the supported configuration for this release.

A hardened operating system profile, such as the STIG profile provided by Ubuntu Security Guide, enables these mechanisms. Applying such a profile to a cluster node is outside the supported configuration for the same reason.

If your security policy requires these mechanisms to stay enabled. Use Alauda OS, the immutable operating system delivered with the platform. On Alauda OS, SELinux and the host firewall are enabled by default, and the platform maintains the policy and the port rules for you. See the Immutable Infrastructure documentation.

Support for running Red Hat Enterprise Linux 9.6 with SELinux in enforcing mode is planned for a future release. Contact technical support for its status.

Hardened Node Security Configuration

Use this section only when a mandatory security policy, such as a STIG baseline, requires a host firewall to stay enabled on cluster nodes. Keeping the host firewall disabled is the default and recommended node configuration, and it is what init.sh produces when you run it without arguments. Enabling it is a non-default configuration that you own, and it has not been validated on every operating system in the support list for this version, so validate it in a non-production environment before you apply it to production nodes.

SELinux and AppArmor are a different case: they must stay disabled. See Why SELinux and AppArmor Must Be Disabled.

Keep the Host Firewall Enabled Instead of Turning It Back On

init.sh can skip individual steps. Pass the matching --skip- argument so that the script never disables the host firewall your policy requires:

ImplementationArgument
firewalld--skip-disable_firewalld
ufw--skip-disable_ufw

For example, to keep firewalld enabled on a RHEL node:

bash init.sh --skip-disable_firewalld

This is the recommended path. The node keeps the state it was installed with, and init.sh still performs every other node preparation step.

Order of Operations

Configure the node before the platform installation, not after. A firewall problem then surfaces while the installer runs, instead of after the cluster carries workloads.

  1. Run init.sh with the --skip- argument for the host firewall implementation you use.
  2. Configure the host firewall rules.
  3. Verify the resulting state on the node with the status command of your firewall implementation, for example firewall-cmd --list-all or ufw status verbose.
  4. Install the platform.

If a Node Already Ran the Full init.sh

Use this path only when the host firewall was already disabled and you have to turn it back on. It is more work than skipping the step in the first place.

  1. Enable and start the service, for example with systemctl enable --now firewalld, or with ufw enable on Ubuntu.
  2. Configure the port rules as described below.
  3. Confirm the resulting rule set with firewall-cmd --list-all or ufw status verbose.

Host Firewall

The platform does not require a specific host firewall implementation. RHEL and Kylin Linux Advanced Server nodes typically use firewalld, and Ubuntu nodes typically use ufw. Whichever implementation you use, allow the same set of ports. For the port list, see Communication Matrix.

DANGER

The communication matrix lists the ports that the nodes listen on. Pod-to-Pod and Pod-to-Service traffic uses arbitrary ports and is not covered by that list, so a firewall that allows only the listed ports breaks cluster networking. When the host firewall is enabled, also treat the Pod CIDR, the Service CIDR, and the network interfaces created by the CNI plugin as trusted sources, so that cluster-internal traffic is not filtered by port. The interface names depend on the CNI plugin and on the environment, so read them from the node instead of assuming a fixed name.

The node that runs the installer also uses 8080, 12080, 12443, and 16443. Allow these ports on that node before you start the installation.

Remove Conflicting Packages

Before installation, applications may already be running in the docker/nerdctl/containerd environment on the nodes, or software conflicting with the global cluster may have been installed. Therefore, it is necessary to check and uninstall conflicting packages.

DANGER
  • To avoid application interruption or data loss, be sure to confirm whether there are conflicting software packages. When a conflict is found, please develop an application switching plan and back up your data before uninstalling.
  • After uninstalling conflicting packages, you still need to check whether there are other potentially conflicting binary files in directories such as /usr/local/bin/ (such as software related to docker, nerdctl, containerd, runc, podman, container network, container runtime, or Kubernetes).

The following commands can be used for reference.

CentOS / RedHat
Ubuntu
Kylin

Check:

for x in \
    docker docker-client docker-common docker-latest \
    podman-docker podman \
    runc \
    containernetworking-plugins \
    apptainer \
    kubernetes kubernetes-master kubernetes-node kubernetes-client \
    ; do
    rpm -qa | grep -F "$x"
done

Uninstall:

for x in \
    docker docker-client docker-common docker-latest \
    podman-docker podman \
    runc \
    containernetworking-plugins \
    apptainer \
    kubernetes kubernetes-master kubernetes-node kubernetes-client \
    ; do
    yum remove "$x"
done

In Linux OS, the /etc/resolv.conf file is used to configure DNS client domain name resolution settings. The search line specifies the domain search path for DNS queries.

Configuration Requirements

  • Number of Domains: The number of domains in the search line should be less than domainCountLimit - 3 (default domainCountLimit is 32).
  • Length of Single Domain: Each domain name must not exceed 253 characters.
  • Total Character Length: The total character count of all domain names and spaces must not exceed MaxDNSSearchListChar (default is 2048).

Example

search domain1.com domain2.com domain3.com
  • The total number of domains is 3.
  • The length of a single domain, such as domain1.com, is 11.
  • The total character length is 35, i.e., 11 + 11 + 11 + 2 (two spaces).
WARNING
  • If the search line in the /etc/resolv.conf file does not meet the above limitations, it may cause DNS query failures or performance degradation.
  • Before modifying the /etc/resolv.conf file, it is recommended to back up the file.