Connettersi ai nodi del cluster del servizio Azure Kubernetes per la risoluzione dei problemi e le attività di manutenzione

Durante tutto il ciclo di vita del cluster del servizio Azure Kubernetes, alla fine è necessario accedere direttamente a un nodo del servizio Azure Kubernetes. Questo accesso potrebbe servire per la manutenzione, la raccolta dei registri o operazioni di risoluzione dei problemi.

È possibile accedere a un nodo tramite l'autenticazione, che i metodi variano a seconda del sistema operativo node e del metodo di connessione. È possibile eseguire l'autenticazione in modo sicuro nei nodi Linux e Windows del servizio Azure Kubernetes tramite due opzioni descritte in questo articolo. Uno richiede l'accesso all'API Kubernetes e l'altro è tramite l'API ARM del servizio Azure Kubernetes, che fornisce informazioni IP private dirette. Per motivi di sicurezza, i nodi del servizio Azure Kubernetes non sono esposti a Internet. Per connettersi direttamente a qualsiasi nodo del servizio Azure Kubernetes, è invece necessario usare kubectl debug o l'indirizzo IP privato dell'host.

Accedere ai nodi usando l'API Kubernetes

Questo metodo richiede l'utilizzo del comando kubectl debug.

Operazioni preliminari

Questa guida illustra come creare una connessione a un nodo del servizio Azure Kubernetes e aggiornare la chiave SSH del cluster del servizio Azure Kubernetes. Per seguire i passaggi, è necessario usare l'interfaccia della riga di comando di Azure che supporta la versione 2.0.64 o successiva. Eseguire az --version per controllare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

Completare questi passaggi se non si ha una chiave SSH. Creare una chiave SSH a seconda dell'immagine del sistema operativo del nodo, per macOS e Linuxo Windows. Assicurarsi di salvare la coppia di chiavi nel formato OpenSSH, evitare formati non supportati, ad esempio .ppk. Fare quindi riferimento a Gestire la configurazione SSH per aggiungere la chiave al cluster.

Linux e macOS

Gli utenti linux e macOS possono accedere al proprio nodo usando o il kubectl debug relativo indirizzo IP privato. Gli utenti di Windows devono passare alla sezione Proxy di Windows Server per una soluzione alternativa a SSH tramite proxy.

Connessione usando il debug kubectl

Per creare una connessione shell interattiva, usare il comando kubectl debug per eseguire un contenitore con privilegi nel nodo.

1. Per elencare i nodi, usare il comando kubectl get nodes:

   kubectl get nodes -o wide
   

   Output di esempio:

   NAME                                STATUS   ROLES   AGE    VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE
   aks-nodepool1-37663765-vmss000000   Ready    agent   166m   v1.25.6   10.224.0.33   <none>        Ubuntu 22.04.2 LTS
   aks-nodepool1-37663765-vmss000001   Ready    agent   166m   v1.25.6   10.224.0.4    <none>        Ubuntu 22.04.2 LTS
   aksnpwin000000                      Ready    agent   160m   v1.25.6   10.224.0.62   <none>        Windows Server 2022 Datacenter
   

2. Usare il comando kubectl debug per avviare un contenitore con privilegi nel nodo e connettersi.

   kubectl debug node/aks-nodepool1-37663765-vmss000000 -it --image=mcr.microsoft.com/cbl-mariner/busybox:2.0
   

   Output di esempio:

   Creating debugging pod node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx with container debugger on node aks-nodepool1-37663765-vmss000000.
   If you don't see a command prompt, try pressing enter.
   root@aks-nodepool1-37663765-vmss000000:/#
   

   È ora possibile accedere al nodo tramite un contenitore con privilegi come pod di debug.

   Nota

   È possibile interagire con la sessione del nodo eseguendo chroot /host dal contenitore con privilegi.

Uscire dalla modalità di debug kubectl

Al termine del nodo, immettere il comando exit per terminare la sessione interattiva della shell. Al termine della sessione interattiva del contenitore, eliminare il pod di debug usato con kubectl delete pod.

kubectl delete pod node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx

Connessione proxy di Windows Server per SSH

Seguire questa procedura come soluzione alternativa per connettersi con SSH in un nodo di Windows Server.

Creare un server proxy

Al momento, non è possibile connettersi direttamente a un nodo di Windows Server usando kubectl debug. È invece necessario connettersi prima a un altro nodo del cluster con kubectl, quindi connettersi al nodo Windows Server da tale nodo usando SSH.

Per connettersi a un altro nodo nel cluster, usare il comando kubectl debug. Per altre informazioni, seguire i passaggi precedenti nella sezione kubectl. Creare una connessione SSH al nodo Windows Server da un altro nodo usando le chiavi SSH fornite quando è stato creato il cluster servizio Azure Kubernetes e l'indirizzo IP interno del nodo Windows Server.

1. Usare il comando kubectl debug per avviare un contenitore con privilegi nel nodo proxy (Linux) e connettersi.

   kubectl debug node/aks-nodepool1-37663765-vmss000000 -it --image=mcr.microsoft.com/cbl-mariner/busybox:2.0
   

   Output di esempio:

   Creating debugging pod node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx with container debugger on node aks-nodepool1-37663765-vmss000000.
   If you don't see a command prompt, try pressing enter.
   root@aks-nodepool1-37663765-vmss000000:/#
   

2. Aprire una nuova finestra del terminale e usare il comando kubectl get pods per ottenere il nome del pod avviato da kubectl debug.

   kubectl get pods
   

   Output di esempio:

   NAME                                                    READY   STATUS    RESTARTS   AGE
   node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx   1/1     Running   0          21s
   

   Nell'output di esempio node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx è il nome del pod avviato da kubectl debug.

3. Usare il comando kubectl port-forward per aprire una connessione al pod distribuito:

   kubectl port-forward node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx 2022:22
   

   Output di esempio:

   Forwarding from 127.0.0.1:2022 -> 22
   Forwarding from [::1]:2022 -> 22
   

   L'esempio precedente inizia a inoltrare il traffico di rete dalla porta 2022 nel computer di sviluppo alla porta 22 nel pod distribuito. Quando si usa kubectl port-forward per aprire una connessione e inoltrare il traffico di rete, la connessione rimane aperta fino a quando non si arresta il comando kubectl port-forward.

4. Aprire un nuovo terminale ed eseguire il comando kubectl get nodes per visualizzare l'indirizzo IP interno del nodo Windows Server:

   kubectl get no -o custom-columns=NAME:metadata.name,'INTERNAL_IP:status.addresses[?(@.type == \"InternalIP\")].address'
   

   Output di esempio:

   NAME                                INTERNAL_IP
   aks-nodepool1-19409214-vmss000003   10.224.0.8
   

   Nell'esempio precedente, 10.224.0.62 è l'indirizzo IP interno del nodo Windows Server.

5. Creare una connessione SSH al nodo Windows Server usando l'indirizzo IP interno e connettersi alla porta 22 tramite LA porta 2022 nel computer di sviluppo. Il nome utente predefinito per i nodi del servizio Azure Kubernetes è azureuser. Accettare la richiesta di continuare con la connessione. Viene quindi fornito il prompt bash del nodo Windows Server:

   ssh -o 'ProxyCommand ssh -p 2022 -W %h:%p azureuser@127.0.0.1' azureuser@10.224.0.62
   

   Output di esempio:

   The authenticity of host '10.224.0.62 (10.224.0.62)' can't be established.
   ECDSA key fingerprint is SHA256:1234567890abcdefghijklmnopqrstuvwxyzABCDEFG.
   Are you sure you want to continue connecting (yes/no)? yes
   

   Nota

   Se si preferisce usare l'autenticazione password, includere il parametro -o PreferredAuthentications=password. Ad esempio:

    ssh -o 'ProxyCommand ssh -p 2022 -W %h:%p azureuser@127.0.0.1' -o PreferredAuthentications=password azureuser@10.224.0.62
   

Usare il contenitore del processo host per accedere al nodo Windows

1. Creare hostprocess.yaml con il contenuto seguente e sostituendo AKSWINDOWSNODENAME con il nome del nodo windows del servizio Azure Kubernetes.

   apiVersion: v1
   kind: Pod
   metadata:
     labels:
       pod: hpc
     name: hpc
   spec:
     securityContext:
       windowsOptions:
         hostProcess: true
         runAsUserName: "NT AUTHORITY\\SYSTEM"
     hostNetwork: true
     containers:
       - name: hpc
         image: mcr.microsoft.com/windows/servercore:ltsc2022 # Use servercore:1809 for WS2019
         command:
           - powershell.exe
           - -Command
           - "Start-Sleep 2147483"
         imagePullPolicy: IfNotPresent
     nodeSelector:
       kubernetes.io/os: windows
       kubernetes.io/hostname: AKSWINDOWSNODENAME
     tolerations:
       - effect: NoSchedule
         key: node.kubernetes.io/unschedulable
         operator: Exists
       - effect: NoSchedule
         key: node.kubernetes.io/network-unavailable
         operator: Exists
       - effect: NoExecute
         key: node.kubernetes.io/unreachable
         operator: Exists
   

2. Eseguire kubectl apply -f hostprocess.yaml per distribuire il contenitore HPC (Host Process Container) di Windows nel nodo Windows specificato.

3. Usare kubectl exec -it [HPC-POD-NAME] -- powershell.

4. È possibile eseguire qualsiasi comando di PowerShell all'interno del contenitore HPC per accedere al nodo Windows.

SSH con Azure Bastion per Windows

Se il nodo proxy Linux non è raggiungibile, l'uso di Azure Bastion come proxy è un'alternativa. Questo metodo richiede di configurare un host Azure Bastion per la rete virtuale in cui risiede il cluster. Per altri dettagli, vedere Connettersi con Azure Bastion.

SSH con indirizzi IP privati dall'API del servizio Azure Kubernetes (anteprima)

Se non si ha accesso all'API Kubernetes, è possibile accedere alle proprietà, ad esempio Node IP e Node Name tramite l'API del pool di agenti del servizio Azure Kubernetes (anteprima), (disponibile nelle versioni di anteprima 07-02-2023 o versioni successive) per connettersi ai nodi del servizio Azure Kubernetes.

Creare una connessione shell interattiva a un nodo usando l'indirizzo IP

Per praticità, i nodi del servizio Azure Kubernetes vengono esposti nella rete virtuale del cluster tramite indirizzi IP privati. Tuttavia, è necessario trovarsi nella rete virtuale del cluster per connettersi tramite SSH al nodo. Se non è già configurato un ambiente, è possibile usare Azure Bastion per stabilire un proxy da cui è possibile connettersi tramite SSH ai nodi del cluster. Assicurarsi che Azure Bastion sia distribuito nella stessa rete virtuale del cluster.

1. Ottenere indirizzi IP privati usando il comando az aks machine list, destinato a tutte le macchine virtuali in un pool di nodi specifico con il flag --nodepool-name.

   az aks machine list --resource-group myResourceGroup  --cluster-name myAKSCluster --nodepool-name nodepool1 -o table
   

   L'output di esempio seguente mostra gli indirizzi IP interni di tutti i nodi nel pool di nodi:

   Name                               Ip           Family
   ---------------------------------  -----------  -----------
   aks-nodepool1-33555069-vmss000000  10.224.0.5   IPv4
   aks-nodepool1-33555069-vmss000001  10.224.0.6   IPv4
   aks-nodepool1-33555069-vmss000002  10.224.0.4   IPv4
   

   Per specificare come destinazione un nodo specifico all'interno del pool di nodi, usare il flag --machine-name:

   az aks machine show --cluster-name myAKScluster --nodepool-name nodepool1 -g myResourceGroup --machine-name aks-nodepool1-33555069-vmss000000 -o table
   

   L'output di esempio seguente mostra l'indirizzo IP interno di tutto il nodo specificato:

   Name                               Ip         Family
   ---------------------------------  -----------  -----------
   aks-nodepool1-33555069-vmss000000  10.224.0.5   IPv4
   

2. Connettersi tramite SSH al nodo usando l'indirizzo IP privato ottenuto nel passaggio precedente. Questo passaggio è applicabile solo per i computer Linux. Per i computer Windows, vedere Connettersi con Azure Bastion.

   ssh -i /path/to/private_key.pem azureuser@10.224.0.33
   

Passaggi successivi

Se sono necessari altri dati per la risoluzione dei problemi, è possibile visualizzare i log kubelet o visualizzare i log del piano di controllo Kubernetes.

Per informazioni sulla gestione delle chiavi SSH, vedere Gestire la configurazione SSH.