Устранение неполадок кластеров больших данных SQL Server Kubernetes

Область применения: SQL Server 2019 (15.x)

В этой статье описывается несколько полезных команд Kubernetes, которые можно использовать для мониторинга и устранения неполадок кластеров больших данных SQL Server 2019. Здесь показано, как просмотреть подробные сведения о модуле pod или других артефактах Kubernetes, расположенных в кластере больших данных. В этой статье также рассматриваются распространенные задачи, такие как копирование файлов в контейнер или из контейнера под управлением одной из служб кластера больших данных SQL Server.

Получение состояния модулей pod

С помощью команды kubectl get pods можно получить статус pod в кластере для всех пространств имен или пространства имен, предназначенного для кластера больших данных. В следующих разделах показаны примеры обоих.

Отображение состояния всех pod в кластере Kubernetes

Выполните следующую команду, чтобы получить все поды и их состояния, включая поды, которые являются частью пространства имен, где созданы поды кластера больших данных SQL Server.

kubectl get pods --all-namespaces

Показать состояние всех pod в кластере больших данных SQL Server

-n Используйте параметр, чтобы указать определенное пространство имен. Обратите внимание, что модули pod кластера больших данных SQL Server создаются в новом пространстве имен, созданном во время загрузки кластера на основе имени кластера, указанного в файле конфигурации развертывания. Имя mssql-clusterпо умолчанию используется здесь.

kubectl get pods -n mssql-cluster

Вы увидите выходные данные, аналогичные следующему списку для работающего кластера больших данных:

PS C:\> kubectl get pods -n mssql-cluster
NAME              READY   STATUS    RESTARTS   AGE
appproxy-f2qqt    2/2     Running   0          110m
compute-0-0       3/3     Running   0          110m
control-zlncl     4/4     Running   0          118m
data-0-0          3/3     Running   0          110m
data-0-1          3/3     Running   0          110m
gateway-0         2/2     Running   0          109m
logsdb-0          1/1     Running   0          112m
logsui-jtdnv      1/1     Running   0          112m
master-0          7/7     Running   0          110m
metricsdb-0       1/1     Running   0          112m
metricsdc-shv2f   1/1     Running   0          112m
metricsui-9bcj7   1/1     Running   0          112m
mgmtproxy-x6gcs   2/2     Running   0          112m
nmnode-0-0        1/1     Running   0          110m
storage-0-0       7/7     Running   0          110m
storage-0-1       7/7     Running   0          110m

Получите сведения о Pod

Выполните следующую команду, чтобы получить подробное описание конкретного pod в формате JSON. Он содержит сведения, такие как текущий узел Kubernetes, на котором размещен модуль pod, контейнеры, работающие в модуле pod, и образ, используемый для загрузки контейнеров. В нем также показаны другие сведения, такие как метки, состояние и сохраняемые тома утверждения, связанные с модулем pod.

kubectl describe pod  <pod_name> -n <namespace_name>

В следующем примере показаны сведения о master-0 pod в кластере больших данных с именем mssql-cluster:

kubectl describe pod  master-0 -n mssql-cluster

Если произошли какие-либо ошибки, иногда можно увидеть ошибку в последних событиях модуля pod.

Получение журналов Pod

Журналы для контейнеров, работающих в модуле pod, можно получить. Следующая команда извлекает журналы для всех контейнеров, работающих в модуле с именем master-0, и выводит их в файл с именем master-0-pod-logs.txt.

kubectl logs master-0 --all-containers=true -n mssql-cluster > master-0-pod-logs.txt

Получить состояние служб

Выполните следующую команду, чтобы получить сведения о службах кластера больших данных. Эти сведения включают их тип и IP-адреса, связанные с соответствующими службами и портами. Обратите внимание, что службы кластера больших данных SQL Server создаются в новом пространстве имен, созданном во время загрузки кластера на основе имени кластера, указанного в файле конфигурации развертывания.

kubectl get svc -n <namespace_name>

В следующем примере показано состояние служб в кластере больших данных с именем mssql-cluster:

kubectl get svc -n mssql-cluster

Следующие службы поддерживают внешние подключения к кластеру больших данных:

¹ Начиная с SQL Server 2019 (15.x) CU 5, при развертывании нового кластера с базовой проверкой подлинности все конечные точки, включая шлюз, используют AZDATA_USERNAME и AZDATA_PASSWORD. Конечные точки в кластерах, которые обновлены до CU 5, продолжают использовать root в качестве имени пользователя для подключения к конечной точке шлюза. Это изменение не применяется к развертываниям с помощью проверки подлинности Active Directory. См. учетные данные для доступа к службам через конечную точку шлюза в заметках о выпуске.

Получение сведений о службе

Выполните эту команду, чтобы получить подробное описание службы в выходных данных формата JSON. Он будет включать такие сведения, как метки, селектор, IP-адрес, внешний IP-адрес (если служба имеет тип LoadBalancer), порт и т. д.

kubectl describe service <service_name> -n <namespace_name>

В следующем примере извлекаются сведения о внешней службе master-svc-external :

kubectl describe service master-svc-external -n mssql-cluster

Copy files

Если необходимо скопировать файлы из контейнера на локальный компьютер, используйте kubectl cp команду со следующим синтаксисом:

kubectl cp <pod_name>:<source_file_path> -c <container_name> -n <namespace_name> <target_local_file_path>

Аналогичным образом можно скопировать kubectl cp файлы с локального компьютера в определенный контейнер.

kubectl cp <source_local_file_path> <pod_name>:<target_container_path> -c <container_name>  -n <namespace_name>

Копирование файлов из контейнера

В следующем примере файлы журналов SQL Server копируются из контейнера ~/temp/sqlserverlogs в путь на локальном компьютере (в этом примере локальный компьютер является клиентом Linux):

kubectl cp master-0:/var/opt/mssql/log -c mssql-server -n mssql-cluster ~/tmp/sqlserverlogs

Копирование файлов в контейнер

В следующем примере файл AdventureWorks2022 копируется с локального компьютера в контейнер мастер-экземпляра SQL Server (mssql-server) в поде master-0. Файл копируется в каталог /tmp в контейнере.

kubectl cp ~/Downloads/AdventureWorks2022.bak master-0:/tmp -c mssql-server -n mssql-cluster

Принудительное удаление модуля pod

Принудительное удаление модуля pod не рекомендуется. Но для тестирования доступности, устойчивости или сохраняемости данных можно удалить pod, чтобы имитировать сбой пода с помощью команды kubectl delete pods.

kubectl delete pods <pod_name> -n <namespace_name> --grace-period=0 --force

В следующем примере удаляется модуль pod пула носителей: storage-0-0

kubectl delete pods storage-0-0 -n mssql-cluster --grace-period=0 --force

Получение IP-адреса pod

Для устранения неполадок может потребоваться получить IP-адрес узла, на котором сейчас запущен модуль pod. Чтобы получить IP-адрес, используйте kubectl get pods команду со следующим синтаксисом:

kubectl get pods <pod_name> -o yaml -n <namespace_name> | grep hostIP

В следующем примере отображается IP-адрес узла, на котором запущен под master-0.

kubectl get pods master-0 -o yaml -n mssql-cluster | grep hostIP

Kubernetes dashboard

Вы можете запустить панель мониторинга Kubernetes для получения дополнительных сведений о кластере. В следующих разделах объясняется, как запустить панель мониторинга для Kubernetes в AKS и начальную загрузку Kubernetes с помощью kubeadm.

Запуск панели мониторинга при запуске кластера в AKS

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

az aks browse --resource-group <azure_resource_group> --name <aks_cluster_name>

При запуске информационной панели в браузере вы можете получать предупреждения о разрешениях из-за включения RBAC по умолчанию в кластерах AKS, а учетная запись службы, которую использует информационная панель, не имеет достаточных разрешений для доступа ко всем ресурсам (например, запрещено использовать pods: пользователь "system:serviceaccount:kube-system:kubernetes-dashboard" не может перечислять pods в пространстве имен "по умолчанию"). Выполните следующую команду, чтобы предоставить необходимые разрешения kubernetes-dashboard, а затем перезапустить панель мониторинга:

kubectl create clusterrolebinding kubernetes-dashboard -n kube-system --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard

Запуск панели мониторинга при загрузке кластера Kubernetes с помощью kubeadm

Подробные инструкции по развертыванию и настройке панели мониторинга в кластере Kubernetes см. в документации по Kubernetes. Чтобы запустить панель мониторинга Kubernetes, выполните следующую команду:

kubectl proxy

Next steps

Дополнительные сведения о кластерах больших данных см. в разделе "Что такое кластеры больших данных SQL Server".