En corto
En un solo servidor, el que tenga los datos más recientes:
| |
En cada uno de los otros servidores, con su /etc/rancher/k3s/config.yaml apuntando al que reseteaste (server: https://node1:6443):
| |
Los agentes no necesitan nada; se reconectan solos.
Cuándo hace falta
etcd necesita mayoría: con tres servidores, dos vivos; con cinco, tres. Si pierdes la mayoría (dos nodos muertos, una partición de red, un cambio de IPs a la vez, un intento de quitar nodos a mano), el que queda no puede escribir y la API se congela:
| |
En journalctl -u k3s verás etcd cluster join failed, failed to get raft status o waiting for etcd quorum. --cluster-reset es la salida que documenta k3s para exactamente esto.
Qué hace --cluster-reset
Reescribe la lista de miembros de etcd para que el nodo actual sea el único, conservando todos sus datos (los objetos de Kubernetes, secretos, todo). No toca los pods ni los agentes. Lo único que se pierde son escrituras que no alcanzaron a replicarse a este nodo antes de la caída, que en la práctica son pocas o ninguna si eliges el que estaba más al día.
Con --cluster-reset-restore-path hace lo mismo pero sustituye los datos por los de un snapshot; todo lo posterior al snapshot desaparece.
Paso a paso
Elige el nodo. Si varios servidores siguen vivos pero sin quórum, quédate con el que tenga el snapshot o el
dbmás reciente:ls -la /var/lib/rancher/k3s/server/db/yk3s etcd-snapshot ls.Guarda una copia por si acaso, incluido el token:
1 2cp -a /var/lib/rancher/k3s/server/db /root/k3s-db-$(date +%F) cp /var/lib/rancher/k3s/server/token /root/k3s-tokenResetea y arranca (el bloque del En corto). El comando tarda unos segundos; no lo interrumpas.
Comprueba que la API responde y que el nodo es el único miembro de etcd:
1 2kubectl get nodes -o wide kubectl get nodes -l node-role.kubernetes.io/etcd=trueLos otros servidores saldrán
NotReadyhasta que se unan; los agentes vuelven aReadysolos.Revisa la configuración de los demás servidores antes de arrancarlos. El primer nodo del clúster suele tener
cluster-init: truey ningúnserver:; si reseteaste otro nodo, ese primero arrancaría un clúster nuevo por su cuenta. Asegúrate de que todos los que se van a unir tienen:1 2 3# /etc/rancher/k3s/config.yaml server: https://node1:6443 # el nodo reseteado (o el VIP, si apunta a él) token: <el mismo token>Únelos uno a uno: stop, borrar
server/db, start. Cada uno entra como learner y tarda uno o dos minutos en ser miembro pleno; espera a que aparezcaReadyantes del siguiente.Snapshot nuevo cuando todo esté verde:
k3s etcd-snapshot save --name post-reset.
Restaurar desde un snapshot
Si el db del superviviente está corrupto o quieres volver a un punto anterior:
| |
Y después, el mismo rejoin de los demás servidores. Por defecto k3s guarda un snapshot cada 12 horas (0 */12 * * *) y conserva 5, en /var/lib/rancher/k3s/server/db/snapshots; --etcd-s3 los manda a S3.
Trampas
- Nunca en dos nodos.
--cluster-reseten dos servidores da dos clústeres con el mismo nombre y agentes confundidos entre ambos. Uno resetea, el resto se une. - El token manda. El snapshot lleva los certificados y las llaves de cifrado protegidos con el token del clúster. Restaurar en un nodo nuevo sin el mismo token (
--token) no arranca. Guarda/var/lib/rancher/k3s/server/tokenfuera del clúster. - SQLite no tiene esto. Un servidor único sin etcd no necesita ni acepta
--cluster-reset; su backup es copiar/var/lib/rancher/k3s/server/db/. cluster-inithuérfano en un nodo que se va a reunir es la forma más fácil de acabar con dos clústeres. Revisa el punto 5.- Balanceador o VIP delante de los servidores: si apunta a un nodo muerto, los agentes tampoco vuelven; revísalo antes de culpar a etcd.
Referencia: etcd-snapshot y Backup and Restore en la documentación de k3s.