Поделиться через

Краткое руководство. Развертывание кластера контейнеров 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

Учетная запись системного администратора (sa) должна быть защищена с помощью надежного пароля. Пароль должен соответствовать политике паролей по умолчанию SQL Server. По умолчанию пароль должен быть не короче восьми символов и содержать три вида символов из следующих: прописные буквы, строчные буквы, десятичные цифры, специальные символы. Пароли могут иметь длину до 128 символов. Рекомендуется использовать максимально длинные и сложные пароли.

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

  2. Чтобы создать в Kubernetes секрет с именем mssql, который содержит значение <password> для MSSQL_SA_PASSWORD, выполните указанную ниже команду. Замените <password> сложный пароль.

    Внимание

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

    kubectl create secret generic mssql --from-literal=MSSQL_SA_PASSWORD="<password>"

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

Для базы данных в кластере 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.

  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 "<password>"

Замените <External IP address> IP-адресом службы mssql-deployment и <password> сложным паролем.

Внимание

Пароль должен соответствовать политике паролей по умолчанию SQL Server. По умолчанию пароль должен быть не короче восьми символов и содержать три вида символов из следующих: прописные буквы, строчные буквы, десятичные цифры, специальные символы. Пароли могут иметь длину до 128 символов. Рекомендуется использовать максимально длинные и сложные пароли.

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

Чтобы проверить сбой и восстановление, можно удалить модуль 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

Связанный контент