Teilen über

Schnellstart: Bereitstellen eines SQL Server-Containerclusters in Azure

  • Artikel

Gilt für: SQL Server – Linux

In diesem Schnellstart wird veranschaulicht, wie Sie eine hoch verfügbare SQL Server-Instanz in einem Container mit persistentem Speicher in Azure Kubernetes Service (AKS) oder Red Hat OpenShift konfigurieren. Wenn bei der SQL Server-Instanz ein Fehler aufritt, erstellt der Orchestrator sie automatisch in einem neuen Pod neu. Der Clusterdienst bietet auch Resilienz für Knotenausfälle.

In dieser Schnellstartanleitung werden die folgenden Befehlszeilentools verwendet, um den Cluster zu verwalten.

Clusterdienst Befehlszeilentool
Azure Kubernetes Service (AKS) kubectl (Kubernetes CLI)
Azure Red Hat OpenShift oc (OpenShift CLI)

Voraussetzungen

Erstellen eines Systemadministratorkennworts

  1. Erstellen Sie ein Systemadministratorkennwort im Kubernetes-Cluster. Kubernetes kann vertrauliche Konfigurationsinformationen wie Kennwörter als Geheimnisse verwalten.

  2. Führen Sie den folgenden Befehl aus, um in Kubernetes ein Geheimnis namens mssql zu erstellen, das den Wert MyC0m9l&xP@ssw0rd für MSSQL_SA_PASSWORD enthält. Wählen Sie Ihr eigenes komplexes Kennwort aus:

    Wichtig

    Die Umgebungsvariable SA_PASSWORD ist veraltet. Verwenden Sie stattdessen MSSQL_SA_PASSWORD.

    kubectl create secret generic mssql --from-literal=MSSQL_SA_PASSWORD="MyC0m9l&xP@ssw0rd"

Erstellen des Speichers

Für eine Datenbank in einem Kubernetes-Cluster müssen Sie beständigen Speicher verwenden. Über die folgenden Schritte können Sie ein persistentes Volume und einen Anspruch auf ein persistentes Volume im Kubernetes-Cluster konfigurieren:

  1. Erstellen Sie ein Manifest, um die Speicherklasse und den Anspruch auf ein persistentes Volume zu definieren. Mit dem Manifest werden der Speicheranbieter, die Parameter und die reclaim policy (Rückforderungsrichtlinie) festgelegt. Der Kubernetes-Cluster verwendet dieses Manifest, um den persistenten Speicher zu erstellen.

  2. Im folgenden YAML-Beispiel werden eine Speicherklasse und ein Anspruch auf persistente Volumes definiert. Der Speicherklassenanbieter lautet azure-disk, weil sich dieser Kubernetes-Cluster in Azure befindet. Der Speicherkontotyp lautet Standard_LRS. Der Anspruch auf persistente Volumes heißt mssql-data. Die Metadaten des Anspruchs auf persistente Volumes enthalten eine Anmerkung, durch die sie auf die Speicherklasse zurückgeführt werden können.

    kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
     name: azure-disk
provisioner: kubernetes.io/azure-disk
parameters:
  storageaccounttype: Standard_LRS
  kind: Managed
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mssql-data
  annotations:
    volume.beta.kubernetes.io/storage-class: azure-disk
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

    Speichern Sie die Datei (z. B. pvc.yaml).

  3. Erstellen Sie den Anspruch auf ein persistentes Volume in Kubernetes, wobei <path to pvc.yaml file> den Speicherort angibt, an dem Sie die Datei gespeichert haben:

    kubectl apply -f <path to pvc.yaml file>

    Das persistente Volume wird automatisch als Azure-Speicherkonto erstellt und an den Anspruch auf ein persistentes Volume gebunden.

    storageclass "azure-disk" created
persistentvolumeclaim "mssql-data" created

  4. Überprüfen Sie den Anspruch auf das persistente Volume, wobei <persistentVolumeClaim> dem Namen des Anspruchs auf das persistente Volume entspricht:

    kubectl describe pvc <persistentVolumeClaim>

    Im vorherigen Schritt wurde der Anspruch auf persistente Volumes mssql-data genannt. Führen Sie den folgenden Befehl aus, um die Metadaten über den Anspruch auf permanente Volumes anzuzeigen:

    kubectl describe pvc mssql-data

    Die zurückgegebenen Metadaten enthalten einen Wert namens Volume. Dieser Wert wird dem Namen des Blobs zugeordnet.

    Name:          mssql-data
Namespace:     default
StorageClass:  azure-disk
Status:        Bound
Volume:        pvc-d169b88e-f26d-11e7-bc3e-0a58ac1f09a4
Labels:        ‹none>
Annotations:   kubectl.kubernetes.io/last-applied-configuration-{"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{"volume.beta.   kubernetes.io/storage-class":"azure-disk"},"name":"mssq1-data...
               pv.kubernetes.io/bind-completed-yes
               pv.kubernetes.io/bound-by-controller=yes
               volume.beta.kubernetes.io/storage-class=azure-disk
               volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/azure-disk
Capacity:      8Gi
Access Modes:  RWO
Events:        <none>

    Der Wert für Volume entspricht einem Teil des Namens des Blobs in der folgenden Abbildung aus dem Azure-Portal:

    Screenshot: Name des Blobs für das Azure-Portal.

  5. Überprüfen Sie das persistente Volume.

    kubectl describe pv

    kubectl gibt Metadaten zum persistenten Volume zurück, die automatisch generiert und an den Anspruch für das persistente Volume gebunden wurden.

Erstellen der Bereitstellung

In diesem Beispiel wird der Container, der die SQL Server-Instanz hostet, als Kubernetes-Bereitstellungsobjekt beschrieben. Die Bereitstellung erstellt eine Replikatgruppe. Die Replikatgruppe erstellt einen Pod.

Sie erstellen ein Manifest zum Beschreiben des Containers basierend auf dem Docker-Image der SQL Server-Instanz mssql-server-linux.

  • Das Manifest referenziert den mssql-server-Anspruch auf das persistente Volume und das mssql-Geheimnis, das Sie bereits auf den Kubernetes-Cluster angewendet haben.
  • Das Manifest beschreibt außerdem einen Dienst. Bei diesem Dienst handelt es sich um einen Lastenausgleich. Der Lastenausgleich garantiert, dass die IP-Adresse beibehalten wird, nachdem die SQL Server-Instanz wiederhergestellt wurde.
  • Das Manifest beschreibt Ressourcenanforderungen und Grenzwerte. Diese basieren auf den Mindestsystemanforderungen.

  1. Erstellen Sie ein Manifest (eine YAML-Datei), um die Bereitstellung zu beschreiben. Im folgenden Beispiel wird eine Bereitstellung beschrieben, die einen Container enthält, der auf dem SQL Server-Containerimage basiert.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: mssql-deployment
spec:
  replicas: 1
  selector:
     matchLabels:
       app: mssql
  template:
    metadata:
      labels:
        app: mssql
    spec:
      terminationGracePeriodSeconds: 30
      hostname: mssqlinst
      securityContext:
        fsGroup: 10001
      containers:
      - name: mssql
        image: mcr.microsoft.com/mssql/server:2022-latest
        resources:
          requests:
            memory: "2G"
            cpu: "2000m"
          limits:
            memory: "2G"
            cpu: "2000m"
        ports:
        - containerPort: 1433
        env:
        - name: MSSQL_PID
          value: "Developer"
        - name: ACCEPT_EULA
          value: "Y"
        - name: MSSQL_SA_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mssql
              key: MSSQL_SA_PASSWORD
        volumeMounts:
        - name: mssqldb
          mountPath: /var/opt/mssql
      volumes:
      - name: mssqldb
        persistentVolumeClaim:
          claimName: mssql-data
---
apiVersion: v1
kind: Service
metadata:
  name: mssql-deployment
spec:
  selector:
    app: mssql
  ports:
    - protocol: TCP
      port: 1433
      targetPort: 1433
  type: LoadBalancer

    Kopieren Sie den obigen Code in eine neue Datei namens sqldeployment.yaml. Ändern Sie die folgenden Werte:

    • MSSQL_PID value: "Developer": Hiermit wird festgelegt, dass der Container die SQL Server Developer-Edition ausführt. Die Developer-Edition ist nicht für Produktionsdaten lizenziert. Wenn die Bereitstellung für die Produktion vorgesehen ist, legen Sie die entsprechende Edition fest (Enterprise, Standard oder Express). Weitere Informationen finden Sie unter Lizenzierung von SQL Server.

    • persistentVolumeClaim: Dieser Wert erfordert einen Eintrag für claimName:, der den verwendeten Namen dem Anspruch für das persistente Volume zuordnet. In diesem Tutorial wird mssql-data verwendet.

    • name: MSSQL_SA_PASSWORD: Konfiguriert das Containerimage, um das Systemadministratorkennwort wie in diesem Abschnitt beschrieben festzulegen.

      valueFrom:
  secretKeyRef:
    name: mssql
    key: MSSQL_SA_PASSWORD

      Wenn Kubernetes den Container bereitstellt, verweist auf das Geheimnis namens mssql, um den Wert für das Kennwort abzurufen.

    • securityContext: Definiert Einstellungen für Berechtigungen und die Zugriffssteuerung für einen Pod oder Container. In diesem Fall werden diese auf Podebene angegeben, damit alle Container diesem Sicherheitskontext entsprechen. Im Sicherheitskontext definieren wir fsGroup mit dem Wert 10001, der der Gruppen-ID (GID) für die mssql-Gruppe entspricht. Dieser Wert bedeutet, dass alle Prozesse des Containers auch Bestandteil der ergänzenden GID 10001 (mssql) sind. Der Besitzer des Volumes /var/opt/mssql und aller Dateien, die in diesem Volume erstellt werden, ist die GID 10001 (die mssql-Gruppe).

    Warnung

    Mithilfe des LoadBalancer-Diensttyps wird der Remotezugriff auf die SQL Server-Instanz (über das Internet) an Port 1433 ermöglicht.

    Speichern Sie die Datei . Beispiel: sqldeployment.yaml.

  2. Erstellen Sie die Bereitstellung, wobei <path to sqldeployment.yaml file> dem Speicherort entspricht, an dem Sie die Datei gespeichert haben:

    kubectl apply -f <path to sqldeployment.yaml file>

    Die Bereitstellung und der Dienst werden erstellt. Die SQL Server-Instanz befindet sich in einem Container, der mit dem persistenten Speicher verbunden ist.

    deployment "mssql-deployment" created
service "mssql-deployment" created

    Die Bereitstellung und der Dienst werden erstellt. Die SQL Server-Instanz befindet sich in einem Container, der mit dem persistenten Speicher verbunden ist.

    Geben Sie kubectl get pod ein, um den Status des Pods anzuzeigen.

    NAME                                READY    STATUS    RESTARTS   AGE
mssql-deployment-3813464711-h312s   1/1      Running   0          17m

    Der Pod weist den Status Running auf. Dieser Status gibt an, dass der Container bereit ist. Nachdem die Bereitstellung erstellt wurde, kann es einige Minuten dauern, bis der Pod sichtbar ist. Die Verzögerung liegt daran, dass der Cluster das Image mssql-server-linux per Pull aus der Microsoft-Artefaktregistrierung abruft. Nachdem das Image zum ersten Mal per Pull abgerufen wurde, können nachfolgende Bereitstellungen schneller sein, wenn die Bereitstellung einen Knoten nutzt, auf dem bereits ein Image zwischengespeichert wurde.

  3. Überprüfen Sie, ob die Dienste ausgeführt werden. Führen Sie den folgenden Befehl aus:

    kubectl get services

    Dieser Befehl gibt alle Dienste, die ausgeführt werden, und die internen sowie externen IP-Adressen der Dienste zurück. Beachten Sie die externe IP-Adresse für den mssql-deployment-Dienst. Verwenden Sie diese IP-Adresse, um eine Verbindung mit SQL Server herzustellen.

    NAME               TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
kubernetes         ClusterIP      10.0.0.1      <none>          443/TCP          52m
mssql-deployment   LoadBalancer   10.0.113.96   52.168.26.254   1433:30619/TCP   2m

    Führen Sie den folgenden Befehl aus, um weitere Informationen zum Status der Objekte im Kubernetes-Cluster zu erhalten. Denken Sie daran, <MyResourceGroup> und <MyKubernetesClustername> durch Ihre Ressourcengruppe und den Namen des Kubernetes-Clusters zu ersetzen:

    az aks browse --resource-group <MyResourceGroup> --name <MyKubernetesClustername>

  4. Über den folgenden Befehl können Sie auch sicherstellen, dass der Container als Nicht-Root-Benutzer ausgeführt wird, wobei <nameOfSqlPod> dem Namen Ihres SQL Server-Pods entspricht:

    kubectl.exe exec <nameOfSqlPod> -it -- /bin/bash

    Sie sehen den Benutzernamen als mssql, wenn Sie whoami ausführen. mssql ist kein Root-Benutzer.

    whoami

Herstellen einer Verbindung mit der SQL Server-Instanz

Sie können von außerhalb des virtuellen Azure-Netzwerks eine Verbindung mit einer Anwendung herstellen, indem Sie das sa-Konto und die externe IP-Adresse für den Dienst verwenden. Verwenden Sie das Kennwort, das Sie als OpenShift-Geheimnis konfiguriert haben.

Sie können die folgenden Anwendungen verwenden, um eine Verbindung mit der SQL Server-Instanz herzustellen.

Herstellen einer Verbindung mit sqlcmd

Führen Sie den folgenden Befehl aus, um eine Verbindung mit sqlcmd herzustellen:

sqlcmd -S <External IP Address> -U sa -P "MyC0m9l&xP@ssw0rd"

Ersetzen Sie die folgenden Werte:

  • Ersetzen Sie <External IP Address> durch die IP-Adresse für den mssql-deployment-Dienst
  • MyC0m9l&xP@ssw0rd durch Ihr komplexes Kennwort

Überprüfen von Fehlern und der Wiederherstellung

Um die Fehler und die Wiederherstellung zu überprüfen, können Sie den Pod löschen, indem Sie folgendermaßen vorgehen:

  1. Listen Sie den Pod auf, der SQL Server ausführt.

    kubectl get pods

    Notieren Sie sich den Namen des Pods, der SQL Server ausführt.

  2. Löschen Sie den Pod.

    kubectl delete pod mssql-deployment-0

    mssql-deployment-0 ist der Wert, der im vorherigen Schritt als Name des Pods zurückgegeben wurde.

Kubernetes erstellt den Pod automatisch neu, um eine SQL Server-Instanz wiederherzustellen, und stellt eine Verbindung mit dem beständigen Speicher her. Verwenden Sie kubectl get pods, um zu überprüfen, dass ein neuer Pod bereitgestellt wurde. Verwenden Sie kubectl get services, um zu überprüfen, ob die IP-Adresse für den neuen Container gleich ist.

Bereinigen von Ressourcen

Wenn Sie nicht planen, die folgenden Tutorials zu durchlaufen, bereinigen Sie Ihre unnötigen Ressourcen. Führen Sie den Befehl az group delete aus, um die Ressourcengruppe, den Containerdienst und alle dazugehörigen Ressourcen zu entfernen. Ersetzen Sie <MyResourceGroup> durch den Namen der Ressourcengruppe, die Ihren Cluster enthält.

az group delete --name <MyResourceGroup> --yes --no-wait

Zugehöriger Inhalt