Bereitstellen von SQL Server-Linux-Containern in Kubernetes mit StatefulSets
Gilt für:
SQL Server – Linux
Dieser Artikel enthält bewährte Methoden und Leitfäden zum Ausführen von SQL Server-Containern in Kubernetes mit StatefulSets. Es wird empfohlen, pro Pod einen SQL Server-Container (Instanz) in Kubernetes bereitzustellen. So verfügen Sie über eine SQL Server-Instanz, die pro Pod im Kubernetes-Cluster bereitgestellt wird.
Entsprechend lautet die Empfehlung des Bereitstellungsskripts, eine SQL Server-Instanz bereitzustellen, indem Sie den Wert von replicas auf 1 festlegen. Wenn Sie eine größere Zahl als 1 als Wert von replicas eingeben, erhalten Sie entsprechend viele SQL Server-Instanzen mit ähnlichen Namen. Wenn Sie beispielsweise im folgenden Skript die Zahl 2 als Wert für replicas zugewiesen haben, stellen Sie zwei SQL Server-Pods mit den Namen mssql-0 bzw. mssql-1 bereit.
Ein weiterer Grund, warum eine SQL Server-Instanz pro Bereitstellungsskript empfohlen wird, besteht darin, dass es dadurch möglich ist, Änderungen an Konfigurationswerten, Editionen, Ablaufverfolgungsflags und anderen Einstellungen unabhängig für jede bereitgestellte SQL Server-Instanz vorzunehmen.
Im folgenden Beispiel sollte der Name der StatefulSet-Workload mit dem Wert von .spec.template.metadata.labels übereinstimmen, der in diesem Fall mssql lautet. Weitere Informationen finden Sie unter StatefulSets.
Wichtig
Die Umgebungsvariable SA_PASSWORD ist veraltet. Verwenden Sie stattdessen 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
Ein Szenario, in dem Sie mehrere Replikate der SQL Server-Instanz mithilfe derselben Bereitstellung bereitstellen, wird im nächsten Abschnitt behandelt. Dies sind jedoch separate unabhängige SQL Server-Instanzen und keine Replikate (im Gegensatz zu Verfügbarkeitsgruppenreplikaten in SQL Server).
Auswählen des Workloadtyps
Die Auswahl des richtigen Workloadbereitstellungstyps wirkt sich nicht auf die Leistung aus, aber das StatefulSet stellt Anforderungen an die Identitätsbindung.
StatefulSet-Workloads
SQL Server ist eine Datenbankanwendung und sollte daher typischerweise als StatefulSet-Workloadtyp bereitgestellt werden. Durch die Bereitstellung von Workloads als StatefulSet können Sie Features wie eindeutige Netzwerkkennungen, persistenten und stabilen Speicher und vieles mehr bereitstellen. Weitere Informationen zu diesem Workloadtyp finden Sie in der Kubernetes-Dokumentation.
Bei der Bereitstellung von mehreren Replikaten von SQL Server-Containern mit demselben YAML-Bereitstellungsskript wie für eine StatefulSet-Workload müssen Podverwaltungsrichtlinien berücksichtigt werden, d. h. .spec.podManagementPolicy.
Für diese Einstellung sind zwei Werte möglich:
OrderedReady: Dies ist der Standardwert, und das Verhalten entspricht dem in den Bereitstellungs- und Skalierungsgarantien beschriebenen Verhalten.
Parallel: Dies ist eine alternative Richtlinie, mit der die Pods (in diesem Fall SQL Server-Pods) parallel erstellt und gestartet werden, ohne darauf zu warten, dass andere Pods erstellt werden. Auf dieselbe Weise werden die Pods beim Beenden auch entfernt. Sie können diese Option verwenden, wenn Sie unabhängige SQL Server-Instanzen bereitstellen und wenn Sie nicht beabsichtigen, eine bestimmte Reihenfolge zum Starten oder Löschen der SQL Server-Instanzen zu befolgen.
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
Da die in Kubernetes bereitgestellten SQL Server-Pods unabhängig voneinander sind, wird normalerweise der Wert Parallel für podManagementPolicy verwendet.
Das folgende Beispiel ist die Beispielausgabe für kubectl get all direkt nach dem Erstellen der Pods mithilfe einer parallelen Richtlinie:
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
Bereitstellungsworkloads
Sie können den Bereitstellungstyp für SQL Server in Szenarien verwenden, in denen Sie SQL Server-Container als zustandslose Datenbankanwendungen bereitstellen möchten, z. B. wenn die Datenpersistenz nicht wichtig ist. Einige Beispiele hierfür dienen zu Test-/QA- oder CI/CD-Zwecken.
Isolation über Namespaces
Namespaces bieten einen Mechanismus für das Isolieren von Ressourcengruppen in einem einzelnen Kubernetes-Cluster. Weitere Informationen zu Namespaces und deren Verwendung finden Sie unter Namespaces.
Wenn Sie planen, SQL Server-Pods in einem Kubernetes-Cluster auszuführen, der auch andere Ressourcen hostet, sollten Sie die SQL Server-Pods aus Sicht von SQL Server in einem eigenen Namespace ausführen, um die Verwaltung zu vereinfachen. Stellen Sie sich beispielsweise vor, dass mehrere Abteilungen denselben Kubernetes-Cluster nutzen und Sie eine SQL Server-Instanz für das Vertriebsteam und eine andere für das Marketingteam bereitstellen möchten. Sie erstellen in diesem Fall zwei Namespaces mit den Namen sales und marketing, wie im folgenden Beispiel gezeigt:
kubectl create namespace sales
kubectl create namespace marketing
Um zu überprüfen, ob die Namespaces erstellt wurden, führen Sie kubectl get namespaces aus. Damit zeigen Sie eine Liste ähnlich der folgenden Ausgabe an.
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
Nun können Sie SQL Server-Container in jedem dieser Namespaces mithilfe des YAML-Codes bereitstellen, der im folgenden Beispiel gezeigt wird. Beachten Sie die namespace-Metadaten, die der YAML-Bereitstellung hinzugefügt wurden und die bewirken, dass alle Container und Dienste dieser Bereitstellung im Namespace sales bereitgestellt werden.
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
Um die Ressourcen anzuzeigen, können Sie den Befehl kubectl get all unter Angabe des Namespace ausführen, um die folgenden Ressourcen anzuzeigen:
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
Namespaces können auch verwendet werden, um die Ressourcen und Pods einzugrenzen, die in einem Namespace erstellt werden. Dazu verwenden Sie den Grenzwertbereich und/oder Richtlinien für das Ressourcenkontingent, um die gesamte Ressourcenerstellung innerhalb eines Namespace zu verwalten.
Konfigurieren der Servicequalität für Pods
Wenn Sie mehrere Pods in einem einzelnen Kubernetes-Cluster bereitstellen, müssen Sie Ressourcen so freigeben, dass eine effiziente Ausführung des Kubernetes-Clusters sichergestellt ist. Sie können Pods so konfigurieren, dass ihnen eine bestimmte Servicequalität (Quality of Service, QoS) zugewiesen wird.
Kubernetes verwendet QoS-Klassen, um Entscheidungen zur Planung und Entfernung von Pods zu treffen. Weitere Informationen zu den verschiedenen QoS-Klassen finden Sie unter Konfigurieren der Servicequalität für Pods.
Aus SQL Server-Perspektive wird empfohlen, SQL Server-Pods mit der Servicequalität Guaranteed für produktionsbasierte Workloads bereitzustellen. Da ein SQL Server-Pod nur über eine SQL Server-Containerinstanz verfügt, die ausgeführt wird, um eine garantierte Servicequalität für diesen Pod zu erreichen, müssen Sie die CPU- und Arbeitsspeicheranforderungen für den Container angeben. Diese sollten den Grenzwerten für Arbeitsspeicher und CPU entsprechen. Dadurch wird sichergestellt, dass die Knoten die erforderlichen Ressourcen bereitstellen und committen, die während der Bereitstellung angegeben werden, und eine vorhersagbare Leistung für die SQL Server-Pods aufweisen.
Das folgende Beispiel für YAML-Bereitstellungscode stellt einen SQL Server-Container im Standardnamespace bereit. Da zwar keine Ressourcenanforderungen, aber Grenzwerte gemäß den Richtlinien im Beispiel für garantierte Dienstqualität angegeben wurden, können Sie sehen, dass für den Pod, der im folgenden Beispiel erstellt wurde, die Servicequalität auf Guaranteed festgelegt wurde. Wenn Sie die Ressourcenanforderungen nicht angeben, verwendet Kubernetes als Ressourcengrenzwerte die Ressourcenanforderungen.
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
Sie können den Befehl kubectl describe pod mssql-0 ausführen, um die Servicequalität Guaranteed anzuzeigen. Die Ausgabe ähnelt dem folgenden Codeschnipsel.
...
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
...
Für Nicht-Produktionsworkloads, bei denen Leistung und Verfügbarkeit keine hohe Priorität haben, können Sie erwägen, die Servicequalität auf Burstable oder BestEffort festzulegen.
Beispiel für burstfähiges Servicequalität
Um ein Burstable YAML-Beispiel zu definieren, geben Sie die Ressourcenanforderungen und nicht die Ressourcengrenzwerte an. Sie können auch Grenzwerte angeben, die höher als die Anforderungen sind. Im folgenden Code werden nur die Unterschiede zum vorherigen Beispiel angezeigt, die erforderlich sind, um eine burstfähige Workload zu definieren.
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'
Sie können den Befehl kubectl describe pod mssql-0 ausführen, um die Servicequalität Burstable anzuzeigen. Die Ausgabe ähnelt dem folgenden Codeschnipsel.
...
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
...
Beispiel für Servicequalität „BestEffort“
Um ein BestEffort-YAML-Beispiel zu definieren, entfernen Sie die Ressourcenanforderungen und Ressourcengrenzwerte. Damit erhalten Sie eine Servicequalität der BestEffort-Klasse wie unter Create a Pod that gets assigned a QoS class of BestEffort (Erstellen eines Pods mit der QoS-Klasse „BestEffort“) definiert. Auch im hier folgenden Code werden nur die Unterschiede zum Guaranteed-Beispiel angezeigt, die erforderlich sind, um eine BestEffort-Workload zu definieren. Diese Optionen werden für SQL Server-Pods nur eingeschränkt empfohlen, da sie wahrscheinlich die ersten wären, die im Fall eines Ressourcenkonflikts beendet werden. Auch für Test- und QA-Szenarien wird die Verwendung der burstfähigen Option für SQL Server empfohlen.
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
Sie können den Befehl kubectl describe pod mssql-0 ausführen, um die Servicequalität BestEffort anzuzeigen. Die Ausgabe ähnelt dem folgenden Codeschnipsel.
...
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
...
Zugehöriger Inhalt
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für