#Plan an In-Place OS Upgrade for ACP Nodes

#Step 1: Confirm the target operating system and kernel

Confirm that the target operating system version, kernel version, kernel source, and CPU architecture are within the supported range. For the current support matrix and known restrictions, see Supported OS and Kernel Versions.

Apply these rules before the maintenance window:

• The operating system major and minor versions must match the supported matrix.
• The core kernel version must match the supported matrix. Only the build suffix can differ.
• The kernel must be the official kernel shipped by the operating system vendor.
• Ubuntu HWE kernels and third-party or custom-compiled kernels are not supported.
• If the target version is not in the supported matrix, contact technical support for compatibility confirmation before the upgrade.

#Step 2: Check for conflicting packages

During an in-place operating system upgrade, the operating system package manager might install or overwrite container runtime, Kubernetes, or container network binaries. Before the upgrade, check and resolve packages that conflict with components. For the package lists and commands, see Remove Conflicting Packages.

If conflicting packages are found, prepare an application migration plan and back up the affected data before uninstalling them.

#Step 3: Record the current runtime and node component versions

Record the versions before the operating system upgrade. Use the records for comparison after the node is upgraded.

containerd --version
runc --version
crictl --version
kubelet --version

Also record critical node configuration files that your operating system upgrade process might update, such as /etc/resolv.conf, /etc/fstab, systemd configuration files, and container runtime configuration files.

#Step 4: Verify cluster capacity and drain the node

Confirm that the remaining nodes have enough capacity to run the Pods evicted from the target node. Then drain the node before the operating system upgrade.

You can use the console to evict Pods from the node. For the console operation, see Manage Nodes.

If you use kubectl, confirm the command options with your operations team before running it. For example:

kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

Pods managed by DaemonSets are not evicted by the drain operation. Workloads that use local storage might lose local data after eviction. Confirm the workload impact before you proceed.

#Step 1: Confirm the operating system and kernel

Verify that the node is running the expected operating system and kernel versions.

cat /etc/os-release
uname -r

Compare the output with the supported matrix and your approved maintenance plan.

#Step 2: Verify base node configuration

Verify that the operating system upgrade did not revert required node settings.

echo "=== Base node configuration check ==="

# SELinux must be disabled on systems that use SELinux.
getenforce 2>/dev/null || echo "SELinux command not available"

# AppArmor must be disabled on systems that use AppArmor.
systemctl status apparmor 2>/dev/null || echo "AppArmor service not installed"

# Swap must be disabled.
swapon --show
free -h | grep Swap

# Firewall services must be disabled according to your cluster network plan.
systemctl status firewalld 2>/dev/null || echo "firewalld not installed"
systemctl status ufw 2>/dev/null || echo "ufw not installed"

# /tmp must not be mounted with noexec.
mount | grep " /tmp "

# DefaultTasksMax must be infinity or a sufficiently large value.
systemctl show --property=DefaultTasksMax

If swap is enabled after the operating system upgrade, disable it and remove the swap entry from /etc/fstab according to your operating system policy.

If SELinux or AppArmor is enabled after the operating system upgrade, disable it according to your operating system policy and the node requirements.

#Step 3: Verify runtime and node component versions

Compare the runtime and node component versions with the pre-upgrade records.

containerd --version
runc --version
crictl --version
kubelet --version

Then verify that containerd is running:

systemctl status containerd

If any binary was overwritten by an operating system package, stop the maintenance and contact technical support before you continue with other nodes.

#Step 4: Verify time synchronization and DNS

Verify that time synchronization and DNS configuration were not changed by the operating system upgrade.

date
timedatectl
cat /etc/resolv.conf

The time skew between nodes must be no more than 10 seconds. If the skew is larger than 10 seconds, synchronize time before restarting workloads on the node.

#Step 5: Restart kubelet and verify node recovery

Restart kubelet after the operating system upgrade is complete and the base node checks pass.

systemctl daemon-reload
systemctl restart kubelet
systemctl status kubelet

Wait for the node to return to the Ready state.

kubectl get node <node-name> --watch

When the node is healthy, resume scheduling.

kubectl uncordon <node-name>

You can also resume scheduling from the console. For the console operation, see Manage Nodes.

#Step 6: Validate workload recovery

Verify the node status and workload placement after scheduling is resumed.

kubectl get nodes
kubectl get pods -A -o wide | grep <node-name>

Then validate the business services that were affected by the node drain. Proceed to the next node only after the current node and related services are healthy.