Teilen über


Schnellstart: Bereitstellen eines SQL Server-Containerclusters in Azure

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