Implementación de contenedores de SQL Server para Linux en Kubernetes con StatefulSets

Artículo
05/10/2023

Se aplica a: SQL Server - Linux

Este artículo contiene procedimientos recomendados e instrucciones para ejecutar contenedores de SQL Server en Kubernetes con StatefulSets. Se recomienda implementar un contenedor de SQL Server (instancia) por pod en Kubernetes. Por lo tanto, tiene una instancia de SQL Server implementada por pod en el clúster de Kubernetes.

De forma similar, la recomendación del script de implementación es implementar una instancia de SQL Server estableciendo el valor replicas en 1. Si escribe un número mayor que 1 como valor de replicas, obtiene muchas instancias de SQL Server con nombres relacionados conjuntamente. Por ejemplo, en el siguiente script, si asignó el número 2 como valor para replicas, implementaría dos pods de SQL Server, con los nombres mssql-0 y mssql-1, respectivamente.

Otra razón por la que se recomienda una instancia de SQL Server por script de implementación es permitir que los cambios en los valores de configuración, la edición, las marcas de seguimiento y otras opciones se realicen de forma independiente para cada instancia de SQL Server implementada.

En el ejemplo siguiente, el nombre de la carga de trabajo StatefulSet debe coincidir con el valor .spec.template.metadata.labels, que en este caso es mssql. Para obtener más información, consulte StatefulSets.

Importante

La variable de entorno SA_PASSWORD está en desuso. En su lugar, use MSSQL_SA_PASSWORD.

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: mssql # name of the StatefulSet workload, the SQL Server instance name is derived from this. We suggest to keep this name same as the .spec.template.metadata.labels, .spec.selector.matchLabels and .spec.serviceName to avoid confusion.
spec:
 serviceName: "mssql" # serviceName is the name of the service that governs this StatefulSet. This service must exist before the StatefulSet, and is responsible for the network identity of the set.
 replicas: 1 # only one pod, with one SQL Server instance deployed.
 selector:
  matchLabels:
   app: mssql  # this has to be the same as .spec.template.metadata.labels
 template:
  metadata:
   labels:
    app: mssql # this has to be the same as .spec.selector.matchLabels, as documented [here](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/):
  spec:
   securityContext:
     fsGroup: 10001
   containers:
   - name: mssql # container name within the pod.
     image: mcr.microsoft.com/mssql/server:2022-latest
     ports:
     - containerPort: 1433
       name: tcpsql
     env:
     - name: ACCEPT_EULA
       value: "Y"
     - name: MSSQL_ENABLE_HADR
       value: "1"
     - name: MSSQL_AGENT_ENABLED
       value: "1"
     - name: MSSQL_SA_PASSWORD
       valueFrom:
         secretKeyRef:
          name: mssql
          key: MSSQL_SA_PASSWORD
     volumeMounts:
     - name: mssql
       mountPath: "/var/opt/mssql"
 volumeClaimTemplates:
   - metadata:
      name: mssql
     spec:
      accessModes:
      - ReadWriteOnce
      resources:
       requests:
        storage: 8Gi

Si todavía decide implementar más de una réplica de la instancia de SQL Server mediante la misma implementación, ese escenario se trata en la sección siguiente. Sin embargo, se trata de instancias de SQL Server independientes diferentes y no réplicas (a diferencia de las réplicas del grupo de disponibilidad en SQL Server).

Elección del tipo de carga de trabajo

Elegir el tipo de implementación de carga de trabajo adecuado no afecta al rendimiento, pero StatefulSet proporciona requisitos de permanencia de identidad.

Cargas de trabajo StatefulSet

SQL Server es una aplicación de base de datos y, por tanto, principalmente debe implementarse como un tipo de carga de trabajo de StatefulSet. La implementación de cargas de trabajo como StatefulSet ayuda a proporcionar características como identificaciones de red única, almacenamiento persistente y estable, etc. Para más información sobre este tipo de carga de trabajo, consulte la documentación de Kubernetes.

Al implementar más de una réplica de contenedores de SQL Server con el mismo script de YAML de implementación que una carga de trabajo de StatefulSet, un parámetro importante que se debe tener en cuenta son las directivas de administración de pods, es decir, .spec.podManagementPolicy.

Hay dos valores posibles para esta configuración:

OrderedReady: este es el valor predeterminado y el comportamiento es como se describe en las garantías de implementación y escalado.

Paralelo: esta es la directiva alternativa que crea e inicia los pods (en este caso, pods de SQL Server) en paralelo, sin esperar a que se creen otros pods. De forma similar, todos los pods se eliminan en paralelo durante la finalización. Puede usar esta opción al implementar instancias de SQL Server independientes entre sí y cuando no tenga previsto seguir un orden para iniciar o eliminar las instancias de SQL Server.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mssql
spec:
  serviceName: "mssql"
  replicas: 2 # two independent SQL Server instances to be deployed
  podManagementPolicy: Parallel
  selector:
    matchLabels:
      app: mssql
  template:
    metadata:
      labels:
        app: mssql
    spec:
      securityContext:
        fsGroup: 10001
      containers:
        - name: mssql
          image: mcr.microsoft.com/mssql/server:2022-latest
          ports:
            - containerPort: 1433
              name: tcpsql
          env:
            - name: ACCEPT_EULA
              value: "Y"
            - name: MSSQL_ENABLE_HADR
              value: "1"
            - name: MSSQL_AGENT_ENABLED
              value: "1"
            - name: MSSQL_SA_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mssql
                  key: MSSQL_SA_PASSWORD
          volumeMounts:
            - name: mssql
              mountPath: "/var/opt/mssql"
  volumeClaimTemplates:
    - metadata:
        name: mssql
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 8Gi

Dado que los pods de SQL Server implementados en Kubernetes son independientes entre sí, Parallel es el valor que se usa normalmente para podManagementPolicy.

La muestra siguiente es la salida de ejemplo para kubectl get all, justo después de crear los pods mediante una directiva paralela:

NAME          READY   STATUS              RESTARTS   AGE
pod/mssql-0   0/1     ContainerCreating   0          4s
pod/mssql-1   0/1     ContainerCreating   0          4s

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   201.0.0.1    <none>        443/TCP   61d

NAME                     READY   AGE
statefulset.apps/mssql   1/1     4s

Cargas de trabajo de implementación

Puede usar el tipo deployment para SQL Server, en escenarios en los que desea implementar contenedores SQL Server como aplicaciones de base de datos sin estado, por ejemplo, cuando la persistencia de datos no es crítica. Algunos de estos ejemplos son para fines de prueba, control de calidad o CI/CD.

Aislamiento a través de espacios de nombres

Los espacios de nombres proporcionan un mecanismo para aislar grupos de recursos dentro de un único clúster de Kubernetes. Para obtener más información sobre los espacios de nombres y cuándo usarlos, consulte Espacios de nombres.

Desde la perspectiva de SQL Server, si pretende ejecutar pods de SQL Server en un clúster de Kubernetes que también hospeda otros recursos, debe ejecutar dichos pods en su propio espacio de nombres, para facilitar la gestión y la administración. Por ejemplo, suponga que tiene varios departamentos que comparten el mismo clúster de Kubernetes y quiere implementar una instancia de SQL Server para el equipo de ventas y otra para el equipo de marketing. Creará dos espacios de nombres denominados sales y marketing, como se muestra en el ejemplo siguiente:

kubectl create namespace sales
kubectl create namespace marketing

Para comprobar que se crean los espacios de nombres, ejecute kubectl get namespaces; verá una lista similar a la siguiente salida.

NAME              STATUS   AGE
default           Active   39d
kube-node-lease   Active   39d
kube-public       Active   39d
kube-system       Active   39d
marketing         Active   7s
sales             Active   26m

Ahora puede implementar contenedores de SQL Server en cada uno de estos espacios de nombres mediante el ejemplo de YAML que se muestra en el ejemplo siguiente. Observe los metadatos de namespace agregados al YAML de implementación, por lo que todos los contenedores y servicios de esta implementación se implementan en el espacio de nombres sales.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azure-disk
provisioner: kubernetes.io/azure-disk
parameters:
  storageAccountType: Standard_LRS
  kind: Managed
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mssql-sales
  namespace: sales
  labels:
    app: mssql-sales
spec:
  serviceName: "mssql-sales"
  replicas: 1
  selector:
    matchLabels:
      app: mssql-sales
  template:
    metadata:
      labels:
        app: mssql-sales
    spec:
      securityContext:
        fsGroup: 10001
      containers:
        - name: mssql-sales
          image: mcr.microsoft.com/mssql/server:2022-latest
          ports:
            - containerPort: 1433
              name: tcpsql
          env:
            - name: ACCEPT_EULA
              value: "Y"
            - name: MSSQL_ENABLE_HADR
              value: "1"
            - name: MSSQL_AGENT_ENABLED
              value: "1"
            - name: MSSQL_SA_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mssql
                  key: MSSQL_SA_PASSWORD
          volumeMounts:
            - name: mssql
              mountPath: "/var/opt/mssql"
  volumeClaimTemplates:
    - metadata:
        name: mssql
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 8Gi
---
apiVersion: v1
kind: Service
metadata:
  name: mssql-sales-0
  namespace: sales
spec:
  type: LoadBalancer
  selector:
    statefulset.kubernetes.io/pod-name: mssql-sales-0
  ports:
    - protocol: TCP
      port: 1433
      targetPort: 1433
      name: tcpsql

Para ver los recursos, puede ejecutar el comando kubectl get all con el espacio de nombres especificado para ver estos recursos:

kubectl get all -n sales

NAME                READY   STATUS    RESTARTS   AGE
pod/mssql-sales-0   1/1     Running   0          17m

NAME                    TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
service/mssql-sales-0   LoadBalancer   10.0.251.120   20.23.79.52   1433:32052/TCP   17m

NAME                           READY   AGE
statefulset.apps/mssql-sales   1/1     17m

Los espacios de nombres también se pueden usar para limitar los recursos y pods creados dentro de un espacio de nombres, mediante el intervalo de límite o las directivas de cuota de recursos, para administrar la creación general de recursos dentro de un espacio de nombres.

Configuración de la Calidad de servicio de pod

Al implementar varios pods en un único clúster de Kubernetes, debe compartir los recursos correctamente para garantizar la ejecución eficiente del clúster de Kubernetes. Puede configurar pods para que se les asigne una Calidad de servicio (QoS) determinada.

Kubernetes usa clases de QoS para tomar decisiones sobre la programación y la expulsión de pods. Para obtener más información sobre las distintas clases de QoS, consulte Configuración de la calidad de servicio para pods.

Desde la perspectiva de SQL Server, se recomienda implementar pods de SQL Server mediante QoS como Guaranteed para cargas de trabajo basadas en producción. Teniendo en cuenta que un pod de SQL Server solo tiene una instancia de contenedor de SQL Server que se ejecuta para lograr Calidad de servicio garantizada para ese pod, tiene que especificar las solicitudes de CPU y memoria para el contenedor que deben ser iguales a los límites de memoria y CPU. Esto garantiza que los nodos proporcionan y confirman los recursos necesarios especificados durante la implementación, y tienen un rendimiento predecible para los pods de SQL Server.

Esta es una muestra de YAML de implementación que implementa un contenedor de SQL Server en el espacio de nombres predeterminado y,como las solicitudes de recursos no se especificaron, pero sí los límites según las directrices del ejemplo Calidad de servicio garantizada, vemos que el pod que se creó en el ejemplo siguiente tiene Calidad de servicio establecido en Guaranteed. Cuando no se especifican las solicitudes de recursos, Kubernetes considera los límites de recursos iguales a las solicitudes de recursos.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
     name: azure-disk
provisioner: kubernetes.io/azure-disk
parameters:
  storageaccounttype: Standard_LRS
  kind: Managed
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: mssql
 labels:
  app: mssql
spec:
 serviceName: "mssql"
 replicas: 1
 selector:
  matchLabels:
   app: mssql
 template:
  metadata:
   labels:
    app: mssql
  spec:
   securityContext:
     fsGroup: 10001
   containers:
   - name: mssql
     command:
       - /bin/bash
       - -c
       - cp /var/opt/config/mssql.conf /var/opt/mssql/mssql.conf && /opt/mssql/bin/sqlservr
     image: mcr.microsoft.com/mssql/server:2022-latest
     resources:
      limits:
       memory: 2Gi
       cpu: '2'
     ports:
     - containerPort: 1433
     env:
     - name: ACCEPT_EULA
       value: "Y"
     - name: MSSQL_ENABLE_HADR
       value: "1"
     - name: MSSQL_SA_PASSWORD
       valueFrom:
         secretKeyRef:
          name: mssql
          key: MSSQL_SA_PASSWORD
     volumeMounts:
     - name: mssql
       mountPath: "/var/opt/mssql"
     - name: userdata
       mountPath: "/var/opt/mssql/userdata"
     - name: userlog
       mountPath: "/var/opt/mssql/userlog"
     - name: tempdb
       mountPath: "/var/opt/mssql/tempdb"
     - name: mssql-config-volume
       mountPath: "/var/opt/config"
   volumes:
     - name: mssql-config-volume
       configMap:
        name: mssql
 volumeClaimTemplates:
   - metadata:
      name: mssql
     spec:
      accessModes:
      - ReadWriteOnce
      resources:
       requests:
        storage: 8Gi
   - metadata:
      name: userdata
     spec:
      accessModes:
      - ReadWriteOnce
      resources:
       requests:
        storage: 8Gi
   - metadata:
      name: userlog
     spec:
      accessModes:
      - ReadWriteOnce
      resources:
       requests:
        storage: 8Gi
   - metadata:
      name: tempdb
     spec:
      accessModes:
      - ReadWriteOnce
      resources:
       requests:
        storage: 8Gi

Puede ejecutar el comando kubectl describe pod mssql-0 para ver QoS como Guaranteed, con una salida similar al siguiente fragmento de código.

...
QoS Class:                 Guaranteed
Node-Selectors:            <none>
Tolerations:               node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                           node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                           node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
...

En el caso de las cargas de trabajo que no son de producción, donde el rendimiento y la disponibilidad no son una prioridad alta, puede considerar la posibilidad de establecer QoS en Burstable o BestEffort.

Ejemplo de QoS ampliable

Para definir un ejemplo de YAML Burstable, especifique las solicitudes de recursos, no los límites de recursos; o bien, especifique los límites, que es mayor que las solicitudes. El código siguiente muestra solo la diferencia con respecto al ejemplo anterior, con el fin de definir una carga de trabajo ampliable.

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: mssql
 labels:
  app: mssql
spec:
 serviceName: "mssql"
 replicas: 1
 selector:
  matchLabels:
   app: mssql
 template:
  metadata:
   labels:
    app: mssql
  spec:
   securityContext:
     fsGroup: 10001
   containers:
   - name: mssql
     command:
       - /bin/bash
       - -c
       - cp /var/opt/config/mssql.conf /var/opt/mssql/mssql.conf && /opt/mssql/bin/sqlservr
     image: mcr.microsoft.com/mssql/server:2022-latest
     resources:
      requests:
       memory: 2Gi
       cpu: '2'

Puede ejecutar el comando kubectl describe pod mssql-0 para ver QoS como Burstable, con una salida similar al siguiente fragmento de código.

...
QoS Class:                 Burstable
Node-Selectors:            <none>
Tolerations:               node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                           node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                           node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
...

Ejemplo de QoS de mejor esfuerzo

Para definir un ejemplo de YAML BestEffort, quite las solicitudes de recursos y los límites de recursos. Terminará con el QoS de mejor esfuerzo, tal como se define en Creación de un pod al que se le asigna una clase QoS de BestEffort. Como antes, el código siguiente muestra solo la diferencia con respecto al ejemplo Guaranteed, con el fin de definir una carga de trabajo de mejor esfuerzo. Estas son las opciones menos recomendadas para pods de SQL Server, ya que probablemente serán las primeras que se terminarán en el caso de contención de recursos. Incluso para escenarios de prueba y control de calidad, se recomienda usar la opción Ampliable para SQL Server.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mssql
  labels:
    app: mssql
spec:
  serviceName: "mssql"
  replicas: 1
  selector:
    matchLabels:
      app: mssql
  template:
    metadata:
      labels:
        app: mssql
    spec:
      securityContext:
        fsGroup: 10001
      containers:
        - name: mssql
          command:
            - /bin/bash
            - -c
            - cp /var/opt/config/mssql.conf /var/opt/mssql/mssql.conf && /opt/mssql/bin/sqlservr
          image: mcr.microsoft.com/mssql/server:2022-latest
          ports:
            - containerPort: 1433

Puede ejecutar el comando kubectl describe pod mssql-0 para ver QoS como BestEffort, con una salida similar al siguiente fragmento de código.

...
QoS Class:                 BestEffort
Node-Selectors:            <none>
Tolerations:               node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                           node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                           node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
...

Compartir a través de

Implementación de contenedores de SQL Server para Linux en Kubernetes con StatefulSets

Elección del tipo de carga de trabajo

Cargas de trabajo StatefulSet

Cargas de trabajo de implementación

Aislamiento a través de espacios de nombres

Configuración de la Calidad de servicio de pod

Ejemplo de QoS ampliable

Ejemplo de QoS de mejor esfuerzo

Comentarios

Recursos adicionales

Compartir a través de

Implementación de contenedores de SQL Server para Linux en Kubernetes con StatefulSets

Elección del tipo de carga de trabajo

Cargas de trabajo StatefulSet

Cargas de trabajo de implementación

Aislamiento a través de espacios de nombres

Configuración de la Calidad de servicio de pod

Ejemplo de QoS ampliable

Ejemplo de QoS de mejor esfuerzo

Contenido relacionado

Comentarios

Recursos adicionales