Risolvere i problemi relativi a Kubernetes per Cluster Big Data di SQL Server

Si applica a: SQL Server 2019 (15.x)

Importante

Il componente aggiuntivo per i cluster Big Data di Microsoft SQL Server 2019 verrà ritirato. Il supporto per i cluster Big Data di SQL Server 2019 terminerà il 28 febbraio 2025. Tutti gli utenti esistenti di SQL Server 2019 con Software Assurance saranno completamente supportati nella piattaforma e fino a quel momento il software continuerà a ricevere aggiornamenti cumulativi di SQL Server. Per altre informazioni, vedere il post di blog relativo all'annuncio e Opzioni per i Big Data nella piattaforma Microsoft SQL Server.

Questo articolo descrive diversi comandi utili di Kubernetes che è possibile usare per il monitoraggio e la risoluzione dei problemi di cluster Big Data di SQL Server 2019. Mostra come visualizzare dettagli approfonditi su un pod o altri elementi di Kubernetes che si trovano nel cluster Big Data. Questo articolo presenta anche le attività comuni, ad esempio la copia di file in o da un contenitore che esegue uno dei cluster Big Data di SQL Server.

Suggerimento

Per il monitoraggio dello stato di componenti di cluster Big Data è possibile usare i comandi azdata bdc status o i notebook per la risoluzione dei problemi disponibili in Azure Data Studio.

Suggerimento

Eseguire i comandi kubectl seguenti in un computer client Windows (cmd.exe o PowerShell) o Linux (Bash). Questi comandi richiedono la precedente autenticazione nel cluster e un contesto del cluster per l'esecuzione. Ad esempio, per un cluster del servizio Azure Kubernetes creato in precedenza è possibile eseguire az aks get-credentials --name <aks_cluster_name> --resource-group <azure_resource_group_name> per scaricare il file di configurazione del cluster Kubernetes e impostare il contesto del cluster.

Ottenere lo stato dei pod

È possibile usare il comando kubectl get pods per ottenere lo stato dei pod nel cluster per tutti gli spazi dei nomi o per lo spazio dei nomi del cluster Big Data. Le sezioni seguenti mostrano esempi di entrambi i casi.

Mostrare lo stato di tutti i pod nel cluster Kubernetes

Eseguire il comando seguente per ottenere tutti i pod e i rispettivi stati, inclusi i pod che fanno parte dello spazio dei nomi in cui vengono creati i pod del cluster Big Data di SQL Server:

kubectl get pods --all-namespaces

Mostrare lo stato di tutti i pod nel cluster Big Data di SQL Server

Usare il parametro -n per specificare un determinato spazio dei nomi. I pod del cluster Big Data di SQL Server vengono creati in un nuovo spazio dei nomi creato in fase di bootstrap del cluster in base al nome del cluster specificato nel file di configurazione della distribuzione. Qui viene usato il nome predefinito mssql-cluster.

kubectl get pods -n mssql-cluster

Per un cluster Big Data in esecuzione, l'output dovrebbe essere simile all'elenco seguente:

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

Nota

Durante la distribuzione, i pod con STATUSContainerCreating sono ancora in arrivo. Se la distribuzione viene interrotta per qualsiasi motivo, questo può dare un'indicazione del problema. Osservare anche la colonna READY. Questa colonna indica il numero di contenitori avviati nel pod. Si noti che le distribuzioni possono richiedere 30 o più minuti, a seconda della configurazione e della rete. Gran parte di questo tempo è dedicato al download delle immagini dei contenitori per diversi componenti.

Ottenere i dettagli del pod

Eseguire il comando seguente per ottenere una descrizione dettagliata di un pod specifico con output in formato JSON. Sono inclusi i dettagli, ad esempio il nodo Kubernetes corrente in cui si trova il pod, i contenitori in esecuzione all'interno del pod e l'immagine usata per il bootstrap dei contenitori. Mostra anche altri dettagli, tra cui etichette, stato e attestazioni di volumi permanenti associati al pod.

kubectl describe pod  <pod_name> -n <namespace_name>

L'esempio seguente mostra i dettagli per il pod master-0 in un cluster Big Data denominato mssql-cluster:

kubectl describe pod  master-0 -n mssql-cluster

Se si verificano errori, talvolta è possibile visualizzare l'errore negli eventi recenti per il pod.

Ottenere i log del pod

È possibile recuperare i log per i contenitori in esecuzione in un pod. Il comando seguente recupera i log per tutti i contenitori in esecuzione nel pod denominato master-0 e li restituisce in un file denominato master-0-pod-logs.txt:

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

Ottenere lo stato dei servizi

Eseguire il comando seguente per ottenere i dettagli per i servizi del cluster Big Data. Questi dettagli includono il tipo e gli indirizzi IP associati ai rispettivi servizi e porte. I servizi del cluster Big Data di SQL Server vengono creati in un nuovo spazio dei nomi creato in fase di bootstrap del cluster in base al nome del cluster specificato nel file di configurazione della distribuzione.

kubectl get svc -n <namespace_name>

L'esempio seguente mostra lo stato per i servizi in un cluster Big Data denominato mssql-cluster:

kubectl get svc -n mssql-cluster

I servizi seguenti supportano connessioni esterne al cluster Big Data:

Servizio Descrizione
master-svc-external Permette l'accesso all'istanza master
(EXTERNAL-IP, 31433 e utente SA).
controller-svc-external Supporta strumenti e client che gestiscono il cluster.
gateway-svc-external Permette l'accesso al gateway ADFS/Spark
(EXTERNAL-IP e utente <AZDATA_USERNAME>)1
appproxy-svc-external Supporta scenari di distribuzione di applicazioni.

1 A partire da SQL Server 2019 (15.x) CU 5, quando si distribuisce un nuovo cluster con l'autenticazione di base, tutti gli endpoint, incluso il gateway, usano AZDATA_USERNAME e AZDATA_PASSWORD. Gli endpoint nei cluster aggiornati a CU5 continuano a usare root come nome utente per la connessione all'endpoint del gateway. Questa modifica non si applica alle distribuzioni che usano l'autenticazione Active Directory. Vedere Credenziali per l'accesso ai servizi tramite l'endpoint del gateway nelle note sulla versione.

Suggerimento

Questo è un modo per visualizzare i servizi con kubectl, ma è anche possibile usare il comando azdata bdc endpoint list per visualizzare questi endpoint. Per altre informazioni, vedere Ottenere gli endpoint del cluster Big Data.

Ottenere i dettagli dei servizi

Eseguire il comando seguente per ottenere una descrizione dettagliata di un servizio con output in formato JSON. La descrizione includerà dettagli come etichette, selettore, indirizzo IP esterno (se il servizio è di tipo LoadBalancer), porta e così via.

kubectl describe service <service_name> -n <namespace_name>

L'esempio seguente recupera i dettagli per il servizio master-svc-external:

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

Copiare i file

Se è necessario copiare file dal contenitore al computer locale, usare il comando kubectl cp con la sintassi seguente:

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

Analogamente, è possibile usare kubectl cp per copiare file dal computer locale a un contenitore specifico.

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

Copiare file da un contenitore

L'esempio seguente copia i file di log di SQL Server dal contenitore al percorso ~/temp/sqlserverlogs nel computer locale (in questo esempio il computer locale è un client Linux):

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

Copiare i file in un contenitore

L'esempio seguente copia il file AdventureWorks2022 dal computer locale al contenitore dell'istanza master di SQL Server (mssql-server) nel pod master-0. Il file viene copiato nella directory /tmp nel contenitore.

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

Forzare l'eliminazione di un pod

Non è consigliabile forzare l'eliminazione di un pod. Tuttavia, per verificare la disponibilità, la resilienza o il salvataggio permanente dei dati, è possibile eliminare un pod per simulare un errore del pod con il comando kubectl delete pods.

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

L'esempio seguente elimina il pod del pool di archiviazione storage-0-0:

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

Ottenere l'indirizzo IP del pod

Ai fini della risoluzione dei problemi, può essere necessario ottenere l'indirizzo IP del nodo in cui viene attualmente eseguito un pod. Per ottenere l'indirizzo IP, usare il comando kubectl get pods con la sintassi seguente:

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

L'esempio seguente ottiene l'indirizzo IP del nodo in cui viene eseguito il pod master-0:

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

Dashboard di Kubernetes

È possibile avviare il dashboard di Kubernetes per altre informazioni sul cluster. Le sezioni seguenti descrivono come avviare il dashboard per Kubernetes nel servizio Azure Kubernetes e per Kubernetes quando viene eseguito il bootstrap con kubeadm.

Avviare il dashboard quando il cluster è in esecuzione nel servizio Azure Kubernetes

Per avviare il dashboard di Kubernetes, eseguire:

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

Nota

Se viene restituito l'errore seguente: Unable to listen on port 8001: All listeners failed to create with the following errors: Unable to create listener: Error listen tcp4 127.0.0.1:8001: >bind: Only one usage of each socket address (protocol/network address/port) is normally permitted. Unable to create listener: Error listen tcp6: address [[::1]]:8001: missing port in >address error: Unable to listen on any of the requested ports: [{8001 9090}], assicurarsi di non avere già avviato il dashboard in un'altra finestra.

Quando si avvia il dashboard nel browser, possono essere restituiti avvisi di autorizzazione perché il controllo degli accessi in base al ruolo è abilitato per impostazione predefinita nei cluster del servizio Azure Kubernetes e l'account del servizio usato dal dashboard non ha autorizzazioni sufficienti per accedere a tutte le risorse; ad esempio: pods is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list pods in the namespace "default"). Eseguire il comando seguente per concedere le autorizzazioni necessarie a kubernetes-dashboard e quindi riavviare il dashboard:

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

Avviare il dashboard quando il bootstrap del cluster Kubernetes viene eseguito con kubeadm

Per istruzioni dettagliate su come distribuire e configurare il dashboard nel cluster Kubernetes, vedere la documentazione di Kubernetes. Per avviare il dashboard di Kubernetes, eseguire questo comando:

kubectl proxy

Passaggi successivi

Per altre informazioni sui cluster Big Data, vedere Informazioni sui cluster Big Data di SQL Server.