Cómo hacer pruebas de aceptación a un clúster Kubernetes antes de producción

Un clúster OpenShift u OKD recién instalado le recibe con una consola llena de verde. Cada operador informa de que está disponible, cada nodo está listo, y es tentador darlo por terminado. El verde le dice que los componentes arrancaron. No le dice que un volumen se puede restaurar, que el tráfico sobrevive a la pérdida de un nodo, ni que un tenant no puede leer los secretos de otro. Eso tiene que probarlo, a propósito, antes de que ahí corra nada que le importe.

El estado no es el comportamiento

Las comprobaciones de salud del clúster están hechas para informar de si un componente se está ejecutando. Producción depende de cómo se comporta la plataforma cuando algo falla: un nodo muere, un disco se llena, una actualización progresiva vacía un nodo que lleva una base de datos. La única forma de saberlo es provocar esas condiciones de manera controlada y observar. El plan de pruebas de abajo cubre las capas que más importan. Adáptelo, pero escriba el suyo, ejecute cada paso a mano la primera vez y conserve las evidencias.

Storage: crear, escribir, ampliar, snapshot, restaurar, comparar

Las cargas de trabajo con estado se sostienen o caen por el storage. Para cada storage class que pretenda ofrecer:

oc apply -f test-pvc.yaml
oc rsh  sh -c 'dd if=/dev/urandom of=/data/blob bs=1M count=256 && sha256sum /data/blob'
oc patch pvc test-pvc -p '{"spec":{"resources":{"requests":{"storage":"20Gi"}}}}'
oc apply -f test-snapshot.yaml
oc apply -f restore-pvc-from-snapshot.yaml
oc rsh  sha256sum /data/blob

Los checksums deben coincidir. Confirme que la ampliación es visible dentro del pod con df, no solo en el claim. Para storage compartido de lectura y escritura múltiple, monte el mismo claim desde pods en dos nodos distintos y confirme que cada uno ve las escrituras del otro. Después compruebe qué ocurre cuando se borra un claim: los datos de producción deben estar en una storage class cuya reclaim policy conserve el volumen, para que un borrado por error no los destruya.

Fallo: mate un nodo y cronometre la recuperación

Elija el nodo que lleva el tráfico de ingress en vivo y apáguelo desde su controlador de gestión, no con un apagado educado. Desde fuera del clúster, ejecute un bucle que ponga marca de tiempo a cada petición:

while true; do
  printf '%s ' "$(date +%T.%N)"
  curl -s -o /dev/null -w '%{http_code}\n' --max-time 2 https://test-app.example.com/
  sleep 0.2
done

La salida muestra exactamente cuánto tiempo estuvo indisponible el servicio, que es el número que sentirían sus usuarios. Después observe qué hace el orquestador: cuánto tarda en marcar el nodo como no listo, si los pods se reprograman, si los pods con estado vuelven con sus datos. Vuelva a encender el nodo y confirme que se reincorpora limpiamente. Aquí importa cómo se entera la red del fallo. Si la dirección del servicio se anuncia desde cada nodo por BGP y el lado de red ejecuta detección rápida de fallos como BFD, el tráfico puede alejarse de un nodo muerto en segundos, mucho antes de que el propio Kubernetes haya decidido que el nodo ha desaparecido.

Mantenimiento: demuestre que los disruption budgets mantienen el quórum

El mantenimiento progresivo de nodos y las actualizaciones de plataforma vacían los nodos uno tras otro. Una base de datos en clúster necesita una mayoría de miembros activos en todo momento, y un PodDisruptionBudget es la forma de decírselo a la plataforma:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: galera-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: galera

Después pruébelo. Con un clúster de tres miembros y uno ya caído (su nodo vaciado, de modo que solo corren dos miembros), intente vaciar el nodo de un segundo miembro:

oc adm cordon 
oc adm drain  --ignore-daemonsets --delete-emptydir-data
oc get pdb

El drain debería esperar en lugar de desalojar, porque desalojar rompería el quórum. Si desaloja, el budget está mal o no existe, y acaba de descubrirlo en una prueba en vez de durante una actualización. Reparta los miembros entre nodos con topology spread constraints o anti-afinidad, para que el fallo de un nodo nunca pueda llevarse dos miembros.

Builds y el registro

Confirme que el clúster puede construir y ejecutar sus propias imágenes, porque un registro interno que no acepta un push solo se descubrirá el día de un despliegue:

oc new-build --name=smoke --binary --strategy=docker
oc start-build smoke --from-dir=. --follow
oc new-app smoke

Acceso: pruebe lo que un tenant no puede hacer

La tenencia se define por lo que se le niega a un usuario. Cree un usuario de prueba acotado por tenant y compruebe los límites explícitamente:

oc auth can-i get secrets -n tenant-b --as=tenant-a-user
oc auth can-i create pods -n tenant-a --as=tenant-a-user
oc auth can-i list nodes --as=tenant-a-user

El primero y el tercero deben decir no; el segundo, sí. Compruebe que las cuotas impiden que un tenant consuma el clúster, que el ingress de cada tenant sirve solo sus propios dominios con un certificado válido, y que el tráfico que sale del clúster hacia sus otros sistemas proviene de la identidad de egress que espera su firewall.

Conserve las evidencias

Registre cada prueba con su comando, su salida y su resultado. Cuando algo cambie más adelante, una actualización de plataforma o una nueva storage class, vuelva a ejecutar la sección correspondiente y compare. Un clúster que pasó sus pruebas una vez y no volvió a probarse se convierte poco a poco en un clúster sin probar.

Cómo lo hacemos nosotros

Construimos OpenShift y OKD sobre servidores dedicados HPE, con storage de bloque persistente y compartido dentro del clúster, direcciones de servicio públicas anunciadas desde los nodos por BGP, e ingress y certificados por tenant. Antes de que un clúster lleve una carga de trabajo de un cliente pasa por más de treinta comprobaciones manuales de este tipo, desde restauraciones de storage byte a byte hasta fallos forzados y acotación de accesos. En una prueba de aceptación apagamos el nodo que llevaba el tráfico en vivo, y la red reencaminó en unos tres segundos, mucho antes de que el orquestador declarara el nodo desaparecido. Las bases de datos en clúster de la plataforma se construyen según el estándar de arriba: disruption budgets que mantienen el quórum, storage que se conserva, miembros repartidos entre nodos.

Si está a punto de poner producción en un clúster nuevo y solo lo ha visto en verde, estaremos encantados de ayudarle a probarlo bien primero.

Hable con un ingeniero

Related

Relacionado: Kubernetes privado en bare metal, OpenShift y OKD · Servidores bare metal en HPE y Dell · Private cloud en KVM con OLVM