Node Preprocessing
Before installing the global cluster, all nodes (control plane nodes and worker nodes) must complete preprocessing.
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. If your environment runs on Immutable Infrastructure (Alauda OS on Huawei DCS, VMware vSphere, or Huawei Cloud Stack), node provisioning is image-based and this preprocessing does not apply; see Installing the global Cluster on Immutable Infrastructure instead.
TOC
Supported OS and Kernel Versionsx86ARMExecute the Quick Configuration ScriptNode ChecksAppendixHardened Node Security ConfigurationKeep the Mechanism Enabled Instead of Turning It Back OnOrder of OperationsIf a Node Already Ran the Fullinit.shHost FirewallPolicy SetsRemove Conflicting PackagesConfigure Search DomainSupported 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 (xandy) must strictly match the validated versions. Modifyingxoryis 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. Modifyingx.y.zis not officially supported. When the list names an operating system release without a kernel value, use the official kernel shipped with that release.
- 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.v2401or later.
x86
- RHEL 7.8:
3.10.0-1127.el7.x86_64 - RHEL 8.0 to 8.6:
4.18.0-80.el8.x86_64and4.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 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:
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=neverparameter. - ✅ CentOS 7.x system machine's grub boot configuration must have the
cgroup.memory=nokmemparameter. - ✅ Check whether the kernel modules
ip_vs,ip_vs_rr,ip_vs_wrr, andip_vs_share 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_ipv4and (for IPv6)nf_conntrack_ipv6are enabled. - ⚠️ If the
globalcluster plans to useKube-OVNCNI, the kernel modulesgeneveandopenvswitchmust be enabled. - ✅ SELinux, AppArmor, and the host firewall must be disabled, unless your security policy requires one of them to stay enabled. In that case the node must be configured as described in Hardened Node Security Configuration before you install the platform.
init.shdisables all three. To keep one of them enabled, pass the matching--skip-argument toinit.shinstead of turning the mechanism back on afterwards.- Keeping a mechanism enabled is a non-default configuration. The platform does not manage the traditional operating system, so an enabled security mechanism 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.
- ✅ The machine's grub boot configuration must have the
-
Users and Permissions
- ✅ The node's SSH user has
rootprivileges and can usesudowithout the password. - ✅ The
UseDNSparameter in/etc/ssh/sshd_configmust be set tono. - ✅ Set the
UsePAMparameter in/etc/ssh/sshd_configtonobefore adding the node, then restartsshd. PAM session policies (such as a forced password change,pam_access,faillock, orpam_limits) can otherwise block the SSH-based node join. After the node reaches theReadystate, you can restoreUsePAM yes. On SELinux-enforcing systems that use password authentication,UsePAM nocan itself break SSH login; use key-based authentication in that case. - ✅
systemctl show --property=DefaultTasksMaxmust returninfinity; a low limit (such as the512default on RHEL 7 / CentOS 7) makes busy containers fail to create threads. If it is notinfinity, setDefaultTasksMax=infinityin/etc/systemd/system.confand runsystemctl daemon-reexec.
- ✅ The node's SSH user has
-
Node Network
- ✅
hostnamemust 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-..
- ✅
localhostin/etc/hostsmust resolve to127.0.0.1. - ✅ The
/etc/resolv.conffile must exist and containnameserverconfigurations, but must not contain addresses starting with 172 (disable systemd-resolved). - ⚠️ The
/etc/resolv.conffile 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 routemust return a default route or a route pointing to0.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
- Control plane nodes:
- ✅ If the cluster uses Kube-OVN or Calico, ensure that the following ports are not occupied:
- Kube-OVN:
6641,6642 - Calico:
179
- Kube-OVN:
- ⚠️ Ensure that the IP addresses in the network segment
172.17.x.x~172.18.x.xrequired 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, andscporsftp. - ⚠️ If you plan to use local storage TopoLVM or Rook, you need to install
lvm2. - ✅ The
/etc/systemd/system/kubelet.servicefile is not allowed to exist. - ✅
/tmpmount parameters must not containnoexec. - ✅ Remove packages that conflict with
globalcluster 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
- ✅ Must have the following installed:
-
Cross-Node Checks
- ✅ There must be no network firewall restrictions between nodes in the
globalcluster. - ✅ The
hostnameof 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.
- ✅ There must be no network firewall restrictions between nodes in the
Appendix
Hardened Node Security Configuration
Use this section only when a mandatory security policy, such as a STIG baseline, requires SELinux, AppArmor, or a host firewall to stay enabled on cluster nodes. Keeping all three disabled is the default and recommended node configuration, and it is what init.sh produces when you run it without arguments. Enabling any of them 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.
Keep the Mechanism 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 mechanism your policy requires:
Combine the arguments you need. For example, to keep SELinux and firewalld enabled on a RHEL node:
This is the recommended path. The node keeps the state it was installed with, so no file system relabel and no extra reboot are required, and init.sh still performs every other node preparation step.
SELinux must end up in enforcing mode. permissive logs denials without blocking them, so it does not satisfy a policy that requires SELinux enforcement. It is still the safe intermediate step when you recover a node on which SELinux was already disabled, as described below.
Order of Operations
Configure the node before the platform installation, not after. A policy or firewall problem then surfaces while the installer runs, instead of after the cluster carries workloads.
- Run
init.shwith the--skip-arguments for the mechanisms you want to keep enabled. - Configure the host firewall rules if a host firewall is enabled.
- Verify the resulting state on the node, for example with
getenforce,aa-status, and the status command of your firewall implementation. - Install the platform.
If a Node Already Ran the Full init.sh
Use this path only when the mechanisms were already disabled and you have to turn them back on. It is more work than skipping the steps in the first place.
SELinux. A full init.sh run sets SELINUX=disabled and reboots the node. While SELinux is disabled the kernel does not maintain security labels, so files written to disk in that state carry no label. Editing /etc/selinux/config alone is not enough, and booting straight into enforcing on a file system that has only just been relabelled can leave the node unreachable: if the relabel is interrupted, or an early-boot file such as /etc/shadow or the sshd host keys ends up mislabelled, the node fails to boot or refuses SSH logins. Relabel under permissive first, and switch to enforcing only after the node comes back cleanly:
- Set
SELINUX=permissivein/etc/selinux/config. - Run
touch /.autorelabelto request a full file system relabel on the next boot. - Reboot the node and wait for the relabel to finish. The node reboots again once the relabel completes, and comes up in
permissivemode. - Review the denials logged during and after the relabel, for example with
ausearch -m avc -ts boot, and resolve them before you continue. - Set
SELINUX=enforcingin/etc/selinux/configand reboot the node. - Run
getenforceand confirm that it returnsEnforcing.
AppArmor. A full init.sh run stops and disables apparmor.service, and it can also add apparmor=0 to the kernel command line. Starting the service alone is therefore not always sufficient:
- Check the kernel command line for
apparmor=0. If it is present, remove it from the boot loader configuration and reboot the node. - Enable and start the service, for example with
systemctl enable --now apparmor. - Run
aa-statusand confirm that the distribution default profiles are loaded and in enforce mode.
Host Firewall
The platform does not require a specific host firewall implementation. RHEL, CentOS, 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.
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.
Policy Sets
Distribution default policy sets are the supported path: the operating system vendor's targeted policy for SELinux, and the distribution default profiles for AppArmor.
Policy sets hardened beyond the distribution defaults, such as the STIG profile provided by Ubuntu Security Guide, and custom SELinux modules or booleans, are outside the validated range. Assess and validate them yourself before you apply them to cluster nodes.
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.
- 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.
Check:
Uninstall:
Configure Search Domain
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
searchline should be less thandomainCountLimit - 3(defaultdomainCountLimitis 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
- 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).
- If the
searchline in the/etc/resolv.conffile does not meet the above limitations, it may cause DNS query failures or performance degradation. - Before modifying the
/etc/resolv.conffile, it is recommended to back up the file.