En Kubernetes, podemos aprovechar los controladores para ayudar a gestionar el estado de nuestras aplicaciones, manteniéndolas en el estado deseado. En esta publicación del blog, exploraremos cómo usar un controlador de implementación para gestionar el estado de la aplicación de SQL Server en Kubernetes.

Comencemos desplegando SQL Server en Kubernetes. Podemos hacerlo utilizando un archivo YAML de implementación para describir nuestra implementación:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: mssql-deployment
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mssql
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: mssql
        image: 'mcr.microsoft.com/mssql/server:2017-CU11-ubuntu'
        ports:
        - containerPort: 1433
        env:
        - name: ACCEPT_EULA
          value: "Y"
        - name: SA_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mssql
              key: SA_PASSWORD
        volumeMounts:
        - name: mssqldb
          mountPath: /var/opt/mssql
      volumes:
      - name: mssqldb
        persistentVolumeClaim:
          claimName: pvc-sql-data
---
apiVersion: v1
kind: Service
metadata:
  name: mssql-deployment
spec:
  selector:
    app: mssql
  ports:
    - protocol: TCP
      port: 31433
      targetPort: 1433
  type: NodePort

Hay algunas cosas a tener en cuenta en nuestro archivo YAML. Primero, estamos utilizando un controlador de implementación para implementar un conjunto de réplicas del número deseado de réplicas utilizando la imagen de contenedor definida. En este caso, tendremos 1 réplica utilizando la imagen de SQL Server 2017 CU11. Un conjunto de réplicas garantiza que un conjunto definido de Pods se estén ejecutando en cualquier momento dado. También estamos utilizando un PersistentVolumeClaim para almacenar el directorio de datos del contenedor externamente, asegurando que nuestras bases de datos estén disponibles incluso si el Pod se vuelve a implementar.

Con la implementación aplicada, nuestra implementación de SQL Server programará un Pod, iniciará el contenedor y lo expondrá como un servicio NodePort. Nuestro SQL Server ahora está en funcionamiento en la imagen de contenedor 2017 CU11.

Ahora podemos usar las implementaciones para mover fácilmente entre versiones de imágenes de contenedor. Por ejemplo, actualicemos la imagen de contenedor de 2017 CU11 a 2017 CU12:

kubectl --record deployment set image mssql-deployment mssql=mcr.microsoft.com/mssql/server:2017-CU12-ubuntu

Con este comando, estamos registrando la actualización de la imagen de contenedor y estableciendo la imagen de contenedor para el contenedor mssql en nuestra plantilla de Pod en 2017-CU12-ubuntu. La estrategia de actualización definida en el archivo deployment-sql.yaml apagará el/los Pod(s) existente(s) en el conjunto de réplicas antes de iniciar el/los nuevo(s) Pod(s) con la nueva imagen de contenedor en el nuevo conjunto de réplicas. Esto asegura que solo un Pod tenga acceso a los archivos de datos en cualquier momento dado.

Si necesitamos revertir de CU12 a CU11, podemos hacerlo fácilmente en Kubernetes:

kubectl rollout undo deployment mssql-deployment --to-revision=1

Esto revertirá la implementación a la imagen de contenedor anterior. Kubernetes se encargará de reducir la escala del nuevo conjunto de réplicas y aumentar la escala del conjunto de réplicas original.

En resumen, las implementaciones de Kubernetes nos ofrecen una forma fácil de gestionar el estado de la aplicación de SQL Server, permitiéndonos mover entre versiones de imágenes de contenedor y revertir si es necesario. Este método proporciona una forma rápida y controlada de actualizar SQL Server en un entorno de Kubernetes.

No dude en ponerse en contacto conmigo si tiene alguna pregunta sobre SQL Server en Kubernetes u otros problemas relacionados en: aen@centinosystems.com