Actualizar y copias de seguridad¶

Cómo desplegar una versión nueva sin sorpresas, cuándo usar dos réplicas y qué copiar para poder restaurar kubelatch. También cubre la clave de cifrado y cómo desinstalar.

Actualizar kubelatch¶

Los comandos usan $MGMT_KUBECONFIG, la ruta al kubeconfig del cluster de gestión (ver Instalar).

Un cambio de imagen o de config.env (el ConfigMap lleva un hash en el nombre) provoca un rollout al aplicar. Un cambio en un Secret no: reinicia tú con kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch rollout restart deploy/kubelatch.

1. Cambia la imagen en images: de deploy/k8s/base/kustomization.yaml, o la configuración que toque.
2. Avisa a los equipos si es horario de trabajo: el rollout corta los exec y port-forward abiertos.

3. Aplica con el mismo overlay que usaste al instalar:

   kubectl --kubeconfig "$MGMT_KUBECONFIG" apply -k deploy/k8s/overlays/cert-manager
   kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch rollout status deploy/kubelatch
   

4. Comprueba la versión en el log (listening con version=…) o con /kubelatch version:

   kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch exec deploy/kubelatch -- /kubelatch version
   

Qué pasa durante un rollout¶

Con maxSurge: 1 y maxUnavailable: 0, el pod nuevo está Ready (migraciones aplicadas, Postgres accesible) antes de que el viejo reciba SIGTERM. Las peticiones nuevas nunca encuentran a nadie escuchando.

Pero un rollout corta las conexiones largas en curso. Al recibir SIGTERM, kubelatch:

1. Deja de aceptar conexiones.
2. Da 3 s a las peticiones normales para terminar.
3. Cierra todo exec, attach, port-forward, watch y logs -f abierto, y completa sus filas de auditoría con «kubelatch reiniciando».

terminationGracePeriodSeconds: 60 deja margen para todo ello. kubectl reintenta solo los watch; un exec o un port-forward hay que relanzarlo.

Migraciones¶

Las migraciones se aplican al arrancar, con un lock de Postgres: con dos réplicas, una migra y la otra espera. Son solo hacia delante. Para volver a una versión anterior del binario, restaura la base de datos de la copia previa a la actualización.

Dos réplicas¶

kubectl --kubeconfig "$MGMT_KUBECONFIG" apply -k deploy/k8s/overlays/ha

El overlay ha pone dos réplicas y un PodDisruptionBudget con minAvailable: 1: un drenado de nodo deja siempre un pod sirviendo. El overlay parte de la base; si usas cert-manager o Ingress, combina sus recursos en tu propio kustomization.

Todo el estado está en Postgres, así que cualquier réplica atiende a cualquier cliente. El reconciliador, la tarea de retención y la sincronización con GitHub se turnan con advisory locks de Postgres.

Lo que no se comparte son los limitadores por IP en memoria (login, intercambio de CI y fallos de autenticación del proxy). Cada réplica cuenta por separado, así que el límite efectivo es el doble. El bloqueo de cuenta tras 5 fallos sí es global: está en la base de datos.

Copias de seguridad¶

Necesitas dos cosas, y por separado:

1. Haz un pg_dump diario, o usa los snapshots de tu servicio gestionado.
2. Guarda la clave en el gestor de secretos, aparte de las copias.
3. Prueba una restauración antes de necesitarla: restaura en otro Postgres y arranca un kubelatch apuntando a él con la misma clave.

Ajustes de Postgres¶

• idle_in_transaction_session_timeout: el reconciliador mantiene una transacción abierta durante toda una pasada (hasta 2 minutos de llamadas al cluster, más la escritura). Si tu Postgres tiene ese timeout, debe superar los 3 minutos. Si no, las pasadas largas fallan con «terminating connection» y el cluster queda en «Error» hasta la siguiente.
• Roles: hoy un único rol hace las migraciones y el tráfico. Los triggers que protegen la auditoría te protegen de fallos de kubelatch, no de quien tenga ese rol. Separar un rol de migraciones (dueño de las tablas) y otro de runtime es una mejora pendiente. Mientras tanto, no reutilices el rol de kubelatch para nada más.
• Tamaño: ver Auditoría y retención.

Si se pierde o se cambia la clave de cifrado¶

KUBELATCH_ENCRYPTION_KEY firma las sesiones y cifra los tokens de las ServiceAccounts de cada cluster. kubelatch solo admite una clave a la vez: no hay rotación con dos claves. Cambiarla (o perderla) tiene estos efectos:

• Todo el mundo vuelve a iniciar sesión: las cookies anteriores no valen.
• Ningún cluster puede usarse hasta volver a pegar sus tokens. En «Clusters» aparecen en «Error» con «vuelve a pegar los tokens del cluster», «Namespaces» y conceder un permiso responden 409 pidiendo volver a pegar el JSON, y «Reconciliar» responde 502 con el mismo motivo que muestra el estado. kubectl recibe un 503 con «kubelatch no puede consultar su base de datos»; el log dice proxy: load cluster.
• No cambian: contraseñas (argon2id), credenciales klt_ (SHA-256), permisos y auditoría.

Si solo la perdiste del gestor de secretos, recupérala del Secret que carga el pod y no hace falta rotar:

kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch get secret kubelatch-secrets -o jsonpath='{.data.KUBELATCH_ENCRYPTION_KEY}' | base64 -d

Para cambiarla a propósito, o si ya no está en ninguna parte:

1. Genera una clave nueva: head -c32 /dev/urandom | base64.

2. Actualiza KUBELATCH_ENCRYPTION_KEY en el Secret kubelatch-secrets, guárdala en el gestor de secretos y reinicia con rollout restart: el cambio de un Secret no redespliega solo. Espera a que termine antes de seguir: durante el rollout conviven pods con la clave vieja y la nueva, y unos tokens pegados a mitad podrían no descifrarse en el otro pod.

   kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch rollout restart deploy/kubelatch
   kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch rollout status deploy/kubelatch
   

3. Para cada cluster, en «Clusters» → «Volver a pegar tokens»: ejecuta el one-liner con el kubeconfig de ese cluster y pega el JSON. No hace falta volver a aplicar el bootstrap. Ver Registrar un cluster.

4. Comprueba que cada cluster vuelve a «Listo».

Desinstalar¶

1. Borra cada cluster desde «Clusters», que limpia su RBAC, y quita después su bootstrap (Borrar un cluster). Si kubelatch ya no llega a él, límpialo todo en el propio cluster:

   kubectl --kubeconfig <kubeconfig-del-cluster> delete -l app.kubernetes.io/managed-by=kubelatch clusterroles,clusterrolebindings,rolebindings -A
   kubectl --kubeconfig <kubeconfig-del-cluster> delete namespace kubelatch-system
   

   En los dos casos, si aplicaste la política de endurecimiento, bórrala también: no lleva las etiquetas de kubelatch.

   kubectl --kubeconfig <kubeconfig-del-cluster> delete validatingadmissionpolicybinding,validatingadmissionpolicy kubelatch-bindings
   

2. Borra kubelatch del cluster de gestión (con -k apuntando al overlay que usaste, si no fue la base):

   kubectl --kubeconfig "$MGMT_KUBECONFIG" delete -k deploy/k8s/base
   

3. Borra la base de datos de Postgres, después de exportar la auditoría si la necesitas.