Solucionar problemas do Kubernetes em Clusters de Big Data do SQL Server
Aplica-se a:
SQL Server 2019 (15.x)
Importante
O complemento Clusters de Big Data do Microsoft SQL Server 2019 será desativado. O suporte para Clusters de Big Data do SQL Server 2019 será encerrado em 28 de fevereiro de 2025. Todos os usuários existentes do SQL Server 2019 com Software Assurance terão suporte total na plataforma e o software continuará a ser mantido por meio de atualizações cumulativas do SQL Server até esse momento. Para obter mais informações, confira a postagem no blog de anúncio e as opções de Big Data na plataforma do Microsoft SQL Server.
Este artigo descreve vários comandos úteis do Kubernetes que você pode usar para monitorar e solucionar problemas de Clusters de Big Data do SQL Server 2019. Ele mostra como exibir detalhes de um pod ou outros artefatos do Kubernetes que estão localizados no cluster de Big Data. Este artigo também aborda tarefas comuns, como copiar arquivos bidirecionalmente em um contêiner que executa um dos serviços de cluster de Big Data do SQL Server.
Dica
Para monitorar o status de componentes de Clusters de Big Data, você pode usar comandos azdata bdc status ou notebooks de solução de problemas internos fornecidos com o Azure Data Studio.
Dica
Execute os comandos kubectl a seguir em um computador cliente Windows (cmd ou PS) ou Linux (Bash). Eles exigem a autenticação anterior no cluster e um contexto de cluster para execução. Por exemplo, para um cluster do AKS criado anteriormente, você pode executar az aks get-credentials --name <aks_cluster_name> --resource-group <azure_resource_group_name> para baixar o arquivo de configuração de cluster do Kubernetes e definir o contexto do cluster.
Obter o status de pods
Use o comando kubectl get pods para obter o status de pods no cluster para todos os namespaces ou o namespace do cluster de Big Data. As seções a seguir mostram exemplos de ambos.
Mostrar o status de todos os pods no cluster do Kubernetes
Execute o comando a seguir para obter todos os pods e os status, incluindo os pods que fazem parte do namespace no qual os pods de clusters de Big Data do SQL Server são criados:
kubectl get pods --all-namespaces
Mostrar o status de todos os pods no cluster de Big Data do SQL Server
Use o parâmetro -n para especificar um namespace específico. Observe que os pods de clusters de Big Data do SQL Server são criados em um namespace criado no momento de inicialização do cluster com base no nome do cluster especificado no arquivo de configuração de implantação. O nome padrão, mssql-cluster, é usado aqui.
kubectl get pods -n mssql-cluster
Você deverá ver uma saída semelhante à seguinte lista para um cluster de Big Data em execução:
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
Observação
Durante a implantação, os pods com um STATUS igual a ContainerCreating ainda estão sendo recebidos. Se a implantação travar por qualquer motivo, isso poderá dar uma ideia da possível causa do problema. Examine também a coluna PRONTO. Isso informa quantos contêineres foram iniciados no pod. Observe que as implantações podem levar 30 minutos ou mais, dependendo da configuração e da rede. Grande parte desse tempo é gasto no download das imagens de contêiner para componentes diferentes.
Obter detalhes do pod
Execute o comando a seguir para obter uma descrição detalhada de um pod específico na saída de formato JSON. Ele inclui detalhes, como o nó atual do Kubernetes no qual o pod é colocado, os contêineres em execução no pod e a imagem usada para inicializar os contêineres. Ele também mostra outros detalhes, como rótulos, status e declarações de volumes persistentes associados ao pod.
kubectl describe pod <pod_name> -n <namespace_name>
O seguinte exemplo mostra os detalhes do pod master-0 em um cluster de Big Data chamado mssql-cluster:
kubectl describe pod master-0 -n mssql-cluster
Caso ocorram erros, às vezes, você poderá ver o erro nos eventos recentes do pod.
Obter os logs do pod
Você poderá recuperar os logs para contêineres em execução em um pod. O seguinte comando recupera os logs de todos os contêineres em execução no pod chamado master-0 e os gera em um arquivo chamado master-0-pod-logs.txt:
kubectl logs master-0 --all-containers=true -n mssql-cluster > master-0-pod-logs.txt
Obter o status de serviços
Execute o comando a seguir para obter detalhes dos serviços de clusters de Big Data. Esses detalhes incluem o tipo e os IPs associados aos respectivos serviços e às respectivas portas. Observe que os serviços de clusters de Big Data do SQL Server são criados em um namespace criado no momento de inicialização do cluster com base no nome do cluster especificado no arquivo de configuração de implantação.
kubectl get svc -n <namespace_name>
O seguinte exemplo mostra o status dos serviços em um cluster de Big Data chamado mssql-cluster:
kubectl get svc -n mssql-cluster
Os seguintes serviços dão suporte a conexões externas com o cluster de Big Data:
| Serviço | Descrição |
|---|---|
| master-svc-external | Fornece acesso à instância mestra. (EXTERNAL-IP,31433 e o usuário SA) |
| controller-svc-external | Dá suporte a ferramentas e clientes que gerenciam o cluster. |
| gateway-svc-external | Fornece acesso ao gateway do HDFS/Spark. (EXTERNAL-IP e o usuário <AZDATA_USERNAME>)1 |
| appproxy-svc-external | Dá suporte a cenários de implantação de aplicativos. |
1 A partir do SQL Server 2019 (15.x) CU 5, quando você implanta um novo cluster com a autenticação básica, todos os pontos de extremidade, incluindo o gateway, usam AZDATA_USERNAME e AZDATA_PASSWORD. Os pontos de extremidade em clusters que são atualizados para CU 5 continuam usando root como o nome de usuário para se conectar ao ponto de extremidade do gateway. Essa alteração não se aplica às implantações que usam a autenticação do Active Directory. Confira Credenciais para acessar serviços por meio do ponto de extremidade do gateway nas notas sobre a versão.
Dica
Essa é uma maneira de exibir os serviços com kubectl, mas também é possível usar o comando azdata bdc endpoint list para exibir esses pontos de extremidade. Para obter mais informações, confira Obter pontos de extremidade de cluster de Big Data.
Obter detalhes do serviço
Execute este comando para obter uma descrição detalhada de um serviço na saída de formato JSON. Ele incluirá detalhes como rótulos, seletores, IP, IP externo (se o serviço for do tipo LoadBalancer), porta etc.
kubectl describe service <service_name> -n <namespace_name>
O seguinte exemplo recupera detalhes do serviço master-svc-external:
kubectl describe service master-svc-external -n mssql-cluster
Copiar arquivos
Caso precise copiar arquivos do contêiner para o computador local, use o comando kubectl cp com a seguinte sintaxe:
kubectl cp <pod_name>:<source_file_path> -c <container_name> -n <namespace_name> <target_local_file_path>
Da mesma forma, use kubectl cp para copiar arquivos do computador local para um contêiner específico.
kubectl cp <source_local_file_path> <pod_name>:<target_container_path> -c <container_name> -n <namespace_name>
Copiar arquivos de um contêiner
O seguinte exemplo copia os arquivos de log de SQL Server do contêiner para o caminho ~/temp/sqlserverlogs no computador local (neste exemplo, o computador local é um cliente Linux):
kubectl cp master-0:/var/opt/mssql/log -c mssql-server -n mssql-cluster ~/tmp/sqlserverlogs
Copiar arquivos para o contêiner
O exemplo a seguir copia o arquivo AdventureWorks2022 do computador local para o contêiner da instância mestra do SQL Server (mssql-server) no pod master-0. O arquivo é copiado para o diretório /tmp no contêiner.
kubectl cp ~/Downloads/AdventureWorks2022.bak master-0:/tmp -c mssql-server -n mssql-cluster
Forçar a exclusão de um pod
Não é recomendável forçar a exclusão de um pod. Porém, para testar a disponibilidade, a resiliência ou a persistência de dados, você pode excluir um pod para simular uma falha de pod com o comando kubectl delete pods.
kubectl delete pods <pod_name> -n <namespace_name> --grace-period=0 --force
O seguinte exemplo exclui o pod do pool de armazenamento, storage-0-0:
kubectl delete pods storage-0-0 -n mssql-cluster --grace-period=0 --force
Obter o IP do pod
Para fins de solução de problemas, talvez seja necessário obter o IP do nó em que um pod está sendo executado. Para obter o endereço IP, use o comando kubectl get pods com a seguinte sintaxe:
kubectl get pods <pod_name> -o yaml -n <namespace_name> | grep hostIP
O seguinte exemplo obtém o endereço IP do nó em que o pod master-0 está em execução:
kubectl get pods master-0 -o yaml -n mssql-cluster | grep hostIP
Painel do Kubernetes
Inicie o painel do Kubernetes para obter mais informações sobre o cluster. As seções a seguir explicam como iniciar o painel do Kubernetes no AKS e do Kubernetes inicializado usando o kubeadm.
Iniciar o painel quando o cluster estiver em execução no AKS
Para iniciar a execução do painel do Kubernetes:
az aks browse --resource-group <azure_resource_group> --name <aks_cluster_name>
Observação
Você verá o seguinte erro: Não é possível ouvir na porta 8001: Falha na criação de todos os ouvintes com os seguintes erros: Não é possível criar o ouvinte: Erro ao escutar na TCP4 127.0.0.1:8001: >bind: Normalmente, apenas um tipo de uso de cada endereço de soquete (endereço de rede/protocolo/porta) é permitido. Não é possível criar o ouvinte: Erro ao escutar na TCP6: endereço [[::1]]:8001: porta ausente no endereço >: Não é possível escutar em nenhuma das portas solicitadas: [{8001 9090}], verifique se você não iniciou o dashboard em outra janela.
Ao iniciar o painel no navegador, você poderá obter avisos de permissão devido ao RBAC estar habilitado por padrão em clusters do AKS. Além disso, a conta de serviço usada pelo painel não tem permissões suficientes para acessar todos os recursos (por exemplo, pods são proibidos: O usuário "system:serviceaccount:kube-system:kubernetes-dashboard" não pode listar os pods no namespace "padrão" ). Execute o seguinte comando para conceder as permissões necessárias ao kubernetes-dashboard e, em seguida, reinicie o painel:
kubectl create clusterrolebinding kubernetes-dashboard -n kube-system --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard
Iniciar o dashboard quando o cluster do Kubernetes for inicializado usando o kubeadm
Para obter instruções detalhadas sobre como implantar e configurar o painel no cluster do Kubernetes, confira a documentação do Kubernetes. Para iniciar o painel do Kubernetes, execute este comando:
kubectl proxy
Próximas etapas
Para obter mais informações sobre clusters de Big Data, confira O que são Clusters de Big Data do SQL Server.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de