Краткое руководство. Развертывание кластера контейнеров SQL Server в Azure

Применимо к:SQL Server — Linux

В этом кратком руководстве показано, как настроить экземпляр SQL Server с высоким уровнем доступности в контейнере с постоянным хранилищем на Служба Azure Kubernetes (AKS) или Red Hat OpenShift. Если экземпляр SQL Server завершается ошибкой, оркестратор автоматически создает его в новом модуле pod. Служба кластера также обеспечивает устойчивость к сбою узла.

В этом кратком руководстве используются следующие средства командной строки для управления кластером.

Служба кластера Программа командной строки
Служба Azure Kubernetes (AKS) kubectl (CLI Kubernetes)
Azure Red Hat OpenShift oc (OpenShift CLI)

Необходимые компоненты

Создание пароля SA

  1. Создайте пароль SA в кластере Kubernetes. Kubernetes может управлять конфиденциальными сведениями о конфигурации, например паролями, в качестве секретов.

  2. Чтобы создать в Kubernetes секрет с именем mssql, который содержит значение MyC0m9l&xP@ssw0rd для MSSQL_SA_PASSWORD, выполните указанную ниже команду. Не забудьте придумать собственный сложный пароль:

    Важно!

    Переменная среды SA_PASSWORD является нерекомендуемой. Вместо этого используйте MSSQL_SA_PASSWORD.

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

Создать хранилище

Для базы данных в кластере Kubernetes необходимо использовать постоянное хранилище. В кластере Kubernetes можно настроить постоянный том и утверждение постоянного тома с помощью следующих шагов:

  1. Создайте манифест, чтобы определить класс хранения и утверждение постоянного тома. В манифесте описана подготовка хранилища, параметры и политика обработки заявок на хранение. Кластер Kubernetes использует этот манифест для создания постоянного хранилища.

  2. В указанном ниже примере на языке YAML определяется класс хранения и утверждение постоянного тома. Подготовка класса хранилища — azure-disk, так как этот кластер Kubernetes находится в Azure. Тип учетной записи хранения — Standard_LRS. Утверждение постоянного тома называется mssql-data. Метаданные утверждения постоянного тома содержат заметку, которая относит его к классу хранения.

    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
    

    Сохраните файл (например, pvc.yaml).

  3. Создайте утверждение постоянного тома в Kubernetes, где <path to pvc.yaml file> является расположением, в котором вы сохранили файл:

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

    Постоянный том создается автоматически как учетная запись хранения Azure и связывается с утверждением постоянного тома.

    storageclass "azure-disk" created
    persistentvolumeclaim "mssql-data" created
    
  4. Проверьте утверждение постоянного тома, где <persistentVolumeClaim> является именем утверждения постоянного тома:

    kubectl describe pvc <persistentVolumeClaim>
    

    На предыдущем шаге утверждение постоянного тома называется mssql-data. Чтобы просмотреть метаданные об утверждении постоянного тома, выполните следующую команду:

    kubectl describe pvc mssql-data
    

    Возвращаемые метаданные содержат значение с именем Volume. Это значение сопоставляется с именем большого двоичного объекта.

    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>
    

    Значение тома соответствует части имени большого двоичного объекта на следующем снимке экрана портала Azure:

    Screenshot of the Azure portal blob name.

  5. Проверьте постоянный том.

    kubectl describe pv
    

    kubectl возвращает метаданные постоянного тома, который создается автоматически и связывается с утверждением постоянного тома.

Создание развертывания

Контейнер, в котором размещен экземпляр SQL Server, описан как объект развертывания Kubernetes. При развертывании создается набор реплик. Набор реплик создает pod.

Вы создаете манифест для описания контейнера на основе образа Docker SQL Server mssql-server-linux.

  • Манифест ссылается на утверждение постоянного тома mssql-server и секрет mssql, который вы уже применили к кластеру Kubernetes.
  • Манифест также описывает службу. Эта служба является подсистемой балансировки нагрузки. Она гарантирует, что IP-адрес будет сохранен после восстановления экземпляра SQL Server.
  • В манифесте описываются запросы и ограничения для ресурсов. Они учитывают минимальные требования к системе.
  1. Создайте манифест (YAML-файл) для описания развертывания. В следующем примере описывается развертывание, включая контейнер, основанный на образе контейнера SQL Server.

    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
    

    Скопируйте приведенный выше код в новый файл с именем sqldeployment.yaml. Измените следующие значения:

    • value: "Developer"MSSQL_PID. Задает контейнер для запуска выпуска SQL Server Developer. Выпуск Developer Edition не лицензирован для рабочих данных. Если развертывание предназначено для использования в рабочей среде, задайте соответствующий выпускEnterprise (Standard или Express). Дополнительные сведения см. в статье о лицензировании SQL Server.

    • persistentVolumeClaim: для этого значения требуется запись, которая claimName: сопоставляется с именем, используемым для утверждения постоянного тома. В этом учебнике используется mssql-data.

    • name: MSSQL_SA_PASSWORD: настраивает образ контейнера для задания пароля SA, как определено в этом разделе.

      valueFrom:
        secretKeyRef:
          name: mssql
          key: MSSQL_SA_PASSWORD
      

      Когда Kubernetes развертывает контейнер, он обращается к секрету с именем mssql, чтобы получить значение пароля.

    • securityContext: определяет параметры управления привилегиями и доступом для pod или контейнера. В этом случае он указан на уровне pod, поэтому все контейнеры соответствуют этому контексту безопасности. В контексте безопасности мы определяем fsGroup со значением 10001, которое является идентификатором группы (GID) для группы mssql. Это значение означает, что все процессы контейнера также являются частью дополнительного идентификатора GID 10001 (mssql). Владелец тома /var/opt/mssql и все файлы, созданные в этом томе, будут иметь GID 10001 (группа mssql).

    Предупреждение

    При использовании типа службы LoadBalancer экземпляр SQL Server будет доступен удаленно (через Интернет) через порт 1433.

    Сохраните файл. Например, sqldeployment.yaml.

  2. Создайте развертывание, где <path to sqldeployment.yaml file> является расположением, в котором сохранен файл:

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

    Развертывание и служба будут созданы. Экземпляр SQL Server находится в контейнере, подключенном к постоянному хранилищу.

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

    Развертывание и служба будут созданы. Экземпляр SQL Server находится в контейнере, подключенном к постоянному хранилищу.

    Для просмотра состояния модуля Pod введите kubectl get pod.

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

    Модуль pod имеет состояние Running. Это состояние указывает, что контейнер готов. После создания развертывания может пройти несколько минут, прежде чем будет виден модуль. Задержка происходит из-за того, что кластер извлекает образ mssql-server-linux из Реестр артефактов Microsoft. После первого извлечения образа последующие развертывания могут выполняться быстрее, если развертывание выполняется на узле, где уже есть кэшированный образ.

  3. Убедитесь в том, что службы запущены. Выполните следующую команду:

    kubectl get services
    

    Эта команда возвращает службы, которые выполняются, а также внутренние и внешние IP-адреса этих служб. Запишите внешний IP-адрес для службы mssql-deployment. Используйте этот IP-адрес для подключения к SQL Server.

    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
    

    Чтобы получить дополнительные сведения о состоянии объектов в кластере Kubernetes, выполните указанную ниже команду. Не забудьте заменить <MyResourceGroup> и <MyKubernetesClustername> вашей группой ресурсов и именем кластера Kubernetes:

    az aks browse --resource-group <MyResourceGroup> --name <MyKubernetesClustername>
    
  4. Вы также можете проверить, что контейнер работает как некорневой контейнер, выполнив следующую команду, где <nameOfSqlPod> является именем модуля pod SQL Server:

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

    Имя пользователя отображается так, как mssql при выполнении whoami. mssql не является корневым пользователем.

    whoami
    

Подключение к экземпляру SQL Server

Вы можете подключиться к приложению за пределами виртуальной сети Azure, используя учетную запись sa и внешний IP-адрес службы. Используйте пароль, настроенный в качестве секрета OpenShift.

Затем можно использовать следующие приложения для подключения к экземпляру SQL Server.

Подключение с помощью sqlcmd

Чтобы подключиться через sqlcmd, используйте следующую команду:

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

Измените следующие значения:

  • <External IP Address> — на IP-адрес службы mssql-deployment.
  • MyC0m9l&xP@ssw0rd на ваш сложный пароль

Проверка сбоя и восстановление

Чтобы проверить сбой и восстановление, можно удалить модуль pod с помощью следующих шагов:

  1. Выведите список модулей Pod, где работает SQL Server.

    kubectl get pods
    

    Запишите имя модуля, на котором работает SQL Server.

  2. Удалите модуль.

    kubectl delete pod mssql-deployment-0
    

    mssql-deployment-0 — это значение, возвращенное на предыдущем шаге для имени модуля pod.

Kubernetes автоматически повторно создает модуль pod для восстановления экземпляра SQL Server и подключения к постоянному хранилищу. Используйте kubectl get pods для проверки развертывания нового Pod. Используйте kubectl get services для проверки того, что IP-адрес контейнера не изменился.

Очистка ресурсов

Если вы не планируете проходить указанные ниже учебники, очистите ненужные ресурсы. az group delete Используйте команду, чтобы удалить группу ресурсов, службу контейнеров и все связанные ресурсы. Замените <MyResourceGroup> именем группы ресурсов, содержащей кластер.

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