Краткое руководство. Развертывание кластера контейнеров 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) |
Необходимые компоненты
Учетная запись Azure с активной подпиской. Создайте учетную запись бесплатно .
Кластер Kubernetes. Дополнительные сведения о создании и подключении к кластеру Kubernetes в AKS
kubectl
см. в статье "Развертывание кластера Служба Azure Kubernetes (AKS).Примечание.
Для защиты от сбоя узла кластер Kubernetes требует наличия нескольких узлов.
Azure CLI. Сведения об установке последней версии см. в статье Установка Azure CLI.
Создание пароля SA
Создайте пароль SA в кластере Kubernetes. Kubernetes может управлять конфиденциальными сведениями о конфигурации, например паролями, в качестве секретов.
Чтобы создать в 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 можно настроить постоянный том и утверждение постоянного тома с помощью следующих шагов:
Создайте манифест, чтобы определить класс хранения и утверждение постоянного тома. В манифесте описана подготовка хранилища, параметры и политика обработки заявок на хранение. Кластер Kubernetes использует этот манифест для создания постоянного хранилища.
В указанном ниже примере на языке 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
).Создайте утверждение постоянного тома в Kubernetes, где
<path to pvc.yaml file>
является расположением, в котором вы сохранили файл:kubectl apply -f <path to pvc.yaml file>
Постоянный том создается автоматически как учетная запись хранения Azure и связывается с утверждением постоянного тома.
storageclass "azure-disk" created persistentvolumeclaim "mssql-data" created
Проверьте утверждение постоянного тома, где
<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:
Проверьте постоянный том.
kubectl describe pv
kubectl
возвращает метаданные постоянного тома, который создается автоматически и связывается с утверждением постоянного тома.
Создание развертывания
Контейнер, в котором размещен экземпляр SQL Server, описан как объект развертывания Kubernetes. При развертывании создается набор реплик. Набор реплик создает pod.
Вы создаете манифест для описания контейнера на основе образа Docker SQL Server mssql-server-linux.
- Манифест ссылается на утверждение постоянного тома
mssql-server
и секретmssql
, который вы уже применили к кластеру Kubernetes. - Манифест также описывает службу. Эта служба является подсистемой балансировки нагрузки. Она гарантирует, что IP-адрес будет сохранен после восстановления экземпляра SQL Server.
- В манифесте описываются запросы и ограничения для ресурсов. Они учитывают минимальные требования к системе.
Создайте манифест (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
. Это значение означает, что все процессы контейнера также являются частью дополнительного идентификатора GID10001
(mssql
). Владелец тома/var/opt/mssql
и все файлы, созданные в этом томе, будут иметь GID10001
(группаmssql
).
Предупреждение
При использовании типа службы
LoadBalancer
экземпляр SQL Server будет доступен удаленно (через Интернет) через порт 1433.Сохраните файл. Например,
sqldeployment.yaml
.Создайте развертывание, где
<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. После первого извлечения образа последующие развертывания могут выполняться быстрее, если развертывание выполняется на узле, где уже есть кэшированный образ.Убедитесь в том, что службы запущены. Выполните следующую команду:
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>
Вы также можете проверить, что контейнер работает как некорневой контейнер, выполнив следующую команду, где
<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 с помощью следующих шагов:
Выведите список модулей Pod, где работает SQL Server.
kubectl get pods
Запишите имя модуля, на котором работает SQL Server.
Удалите модуль.
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