SQL Server persistente en Kubernetes con StatefulSet

Pregunta

¿Qué necesitamos para ejecutar una instancia de SQL Server sobre Kubernetes sin tratarla como un workload completamente efímero? Un Deployment normal asume que cualquier pod es reemplazable y que el almacenamiento va y viene con él. Una base de datos rompe las dos suposiciones: necesita una identidad estable y necesita que sus datos sobrevivan al pod.

Hipótesis

Un StatefulSet combinado con almacenamiento persistente permite separar dos cosas que en un Deployment están mezcladas: la identidad del pod y la persistencia de los datos. El StatefulSet da a cada pod un nombre estable y ordinal; los PersistentVolumeClaims mantienen los volúmenes aunque el pod se recree.

Arquitectura

El flujo de la prueba es lineal:

Client
  → Headless Service (identidad) / ClusterIP Service (acceso)
    → StatefulSet
      → contenedor SQL Server 2022
        → PersistentVolumeClaims (data, log, tempdb, backup)
          → Longhorn

El Headless Service da un nombre DNS estable por pod, necesario para que la identidad ordinal del StatefulSet sea direccionable. El ClusterIP Service expone el punto de acceso para los clientes dentro del clúster. Longhorn actúa como aprovisionador de los volúmenes que respaldan cada PVC.

Persistencia

La instancia no usa un único volumen. Se separan cuatro por rol, cada uno con su propio PVC:

• data — archivos de datos de las bases (.mdf, .ndf).
• log — el registro de transacciones (.ldf), con un patrón de escritura distinto al de los datos.
• tempdb — objetos temporales; se beneficia de estar aislado y puede tolerar una durabilidad menor.
• backup — destino de las copias, que conviene mantener fuera del volumen de datos.

Esta separación es conceptual antes que de rendimiento: permite razonar sobre cada tipo de E/S, dimensionarlo y respaldarlo por separado.

MSSQL_ENABLE_HADR se habilita a nivel de instancia para dejar la puerta abierta a grupos de disponibilidad, pero activar la característica no es lo mismo que tener un Always On configurado: no hay réplica secundaria, sincronización ni conmutación en esta prueba. Del mismo modo, tener varios pods en el StatefulSet no implica alta disponibilidad de la base de datos; sin replicación a nivel de SQL Server, cada pod es una instancia independiente.

Validación

La prueba se considera correcta cuando se cumple, en orden:

1. el pod del StatefulSet llega a estado Running;
2. cada PersistentVolumeClaim queda en estado Bound;
3. hay conectividad hacia el ClusterIP Service desde dentro del clúster;
4. SELECT @@VERSION responde e identifica SQL Server 2022;
5. se puede crear una base de datos de prueba, escribir una tabla y volver a leerla;
6. tras borrar el pod, el StatefulSet lo recrea con el mismo nombre y la base de prueba sigue presente.

SELECT @@VERSION;
 
CREATE DATABASE lab_persistencia;
GO
 
USE lab_persistencia;
CREATE TABLE prueba (id INT IDENTITY PRIMARY KEY, nota NVARCHAR(100));
INSERT INTO prueba (nota) VALUES (N'escrito antes de reiniciar el pod');
SELECT * FROM prueba;

Los valores concretos del entorno quedan fuera del alcance de esta nota.

Aprendizaje

Kubernetes puede sostener workloads stateful: mantiene la identidad del pod a través de reinicios y conserva el almacenamiento mediante PVCs respaldados por Longhorn. Pero la persistencia del almacenamiento no equivale, por sí sola, a alta disponibilidad de SQL Server. La disponibilidad de la base de datos es un problema del motor —grupos de disponibilidad, réplicas, quórum— y requiere diseñarse aparte. Este PoC valida el sustrato, no la HA.