Mover los datos de k3s a otro disco

k3s deja estado en el disco del sistema. Si se llena / o quieres un disco más rápido, el procedimiento corto es: parar → mv → symlink → arrancar.

El destino (/datadrive aquí) tiene que existir y estar montado antes. Root o sudo.

1
2
3

sudo systemctl stop k3s
sudo systemctl stop k3s-agent   # solo si este nodo es agent
sudo /usr/local/bin/k3s-killall.sh

1
2
3

sudo mv /run/k3s/ /datadrive/k3s/
sudo mv /var/lib/kubelet/pods/ /datadrive/k3s-pods/
sudo mv /var/lib/rancher/ /datadrive/k3s-rancher/

1
2
3

sudo ln -s /datadrive/k3s/ /run/k3s
sudo ln -s /datadrive/k3s-pods/ /var/lib/kubelet/pods
sudo ln -s /datadrive/k3s-rancher/ /var/lib/rancher

1
2

sudo systemctl start k3s
sudo systemctl start k3s-agent   # solo en agents

1
2

kubectl get nodes
kubectl get pods -A

Qué se mueve

Ahí vive el estado de trabajo: containerd, manifests, pods. Un mv a medias o un start con las rutas vacías rompe el cluster.

Trampas

/run es tmpfs. Tras un reboot el symlink /run/k3s desaparece. Recréalo en un unit After=local-fs.target o no muevas /run/k3s y deja el runtime en RAM.

k3s-agent no existe en un server-only. systemctl stop k3s-agent falla; no es un error de la migración.

Crea el padre de los destinos (mkdir -p /datadrive) y confirma el mount (findmnt /datadrive) antes del mv. Un mv a un path que no está montado deja los datos en el disco viejo con otro nombre.

containerd y kubelet a veces no quieren symlink. Si el node no vuelve Ready, cambia a bind mount en /etc/fstab:

1

/datadrive/k3s-rancher  /var/lib/rancher  none  bind  0  0

Alternativa más limpia: --data-dir

El path “oficial” de k3s es --data-dir (/var/lib/rancher/k3s por defecto). En un nodo nuevo, instala con el data-dir ya en el disco grande. En uno existente, el mv + symlink (o bind) de /var/lib/rancher es el atajo; no reescribas el unit a ciegas a mitad de un cluster.

Guía que documenta este mv + symlink: How to Move K3s Data to a New Location.