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.