Implementación de contenedores de SQL Server para Linux en Kubernetes con StatefulSets
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:2019-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:2019-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:2019-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:2019-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:2019-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:2019-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
...
Contenido relacionado
- Inicio rápido: Implementación de un clúster de contenedor de SQL Server en Azure
- Inicio rápido: Implementación de un contenedor de SQL Server en Linux en Azure Kubernetes Service (AKS) mediante gráficos de Helm
- Implementación de un grupo de disponibilidad con DH2i para contenedores de SQL Server en AKS
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente las Cuestiones de GitHub como mecanismo de retroalimentación para el contenido y lo sustituiremos por un nuevo sistema de retroalimentación. Para más información, consulta: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de