Cleanly stopping an RKE2 node for planned maintenance
Draining and stopping a node the right way for a patch/reboot is mostly ordinary Kubernetes practice; the one RKE2-specific trap is reaching for the wrong bundled script to actually stop it.
The sequence
# 1. Move workloads off first
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
# 2. Stop RKE2 cleanly
systemctl stop rke2-server # control-plane / server node
systemctl stop rke2-agent # worker / agent node
# ... patch, reboot, whatever the maintenance is ...
# 3. RKE2 is enabled in systemd, so it starts itself on boot.
# Once the node's Ready again:
kubectl uncordon <node>
kubectl drain cordons the node for you (no separate kubectl cordon needed first), evicts pods respecting PodDisruptionBudgets, and --ignore-daemonsets skips the daemonset pods that would otherwise block it forever, since a daemonset pod is supposed to run on every node. --delete-emptydir-data is what lets it proceed past pods using emptyDir volumes, whose data doesn't survive a reschedule anyway.
A PDB with no room to evict will hang the drain. kubectl get pdb -A before draining anything with a minAvailable/maxUnavailable that leaves zero slack — a single-replica deployment behind a PDB requiring 1 available is the classic way to watch kubectl drain sit there.
The one thing that's actually RKE2-specific: don't use rke2-killall.sh for this
RKE2 ships an rke2-killall.sh alongside the binaries. It sounds like exactly what you'd want to stop a node — it is not. Reading the script itself, after stopping the services it also force-kills every containerd-shim process tree, unmounts and deletes the kubelet pod and CNI mount points, deletes the CNI network interfaces (cni0, flannel.*, Calico/Cilium interfaces), removes the static pod manifests for etcd/kube-apiserver/kube-scheduler/etc., and strips Kubernetes/CNI rules out of iptables. That's a full teardown for an uninstall or a hard reset — not a stop-start-cleanly step. A plain systemctl stop rke2-server/rke2-agent is the actual clean stop; RKE2's own uninstall docs only ever call it out for removing RKE2 entirely, never for a reboot.
Control-plane nodes: mind etcd quorum
If the node being rebooted runs rke2-server with the embedded etcd datastore, only take down one at a time. Per RKE2's own HA install docs, quorum for n servers is (n/2)+1 — for the standard 3-server cluster that's 2, meaning exactly one server can be unavailable before the cluster loses write quorum. Draining and rebooting a second server before the first has fully rejoined isn't a maintenance window anymore, it's an outage.
RKE2's manual upgrade guide documents the same one-at-a-time rule for version upgrades specifically: servers first, one at a time, agents after — the same sequencing applies whether you're changing the RKE2 version or just rebooting for OS patches.
Created 2026-09-17T18:44:40+02:00 · Edit