Se connecter à des nœuds de cluster AKS (Azure Kubernetes Service) pour effectuer des tâches de maintenance ou de dépannage

Article
08/02/2024

Tout au long du cycle de vie de votre cluster AKS (Azure Kubernetes Service ), vous pourriez être amené à accéder directement à un nœud AKS. que ce soit pour effectuer une tâche de maintenance, une collecte de journaux ou des opérations de dépannage.

Vous accédez à un nœud par le biais de l’authentification, quelles méthodes varient en fonction de votre Node OS et de la méthode de connexion. Vous vous authentifiez en toute sécurité auprès des nœuds Linux et Windows AKS par le biais de deux options décrites dans cet article. Vous devez disposer d’un accès à l’API Kubernetes, et l’autre se fait par le biais de l’API ARM AKS, qui fournit des informations IP privées directes. Pour des raisons de sécurité, les nœuds AKS ne sont pas exposés à Internet. Au lieu de cela, pour vous connecter directement à tous les nœuds AKS, vous devez utiliser kubectl debug ou l’adresse IP privée.

Accéder aux nœuds à l’aide de l’API Kubernetes

Cette méthode nécessite l’utilisation de la commande kubectl debug.

Avant de commencer

Ce guide montre comment créer une connexion à un nœud AKS et mettre à jour la clé SSH sur votre cluster AKS. Pour suivre les étapes, vous devez utiliser Azure CLI qui prend en charge la version 2.0.64 ou ultérieure. Pour vérifier la version, exécutez az --version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.

Effectuez ces étapes si vous n’avez pas de clé SSH. Créez une clé SSH en fonction de votre image Node OS, pour macOS et Linux ou Windows. Veillez à enregistrer la paire de clés au format OpenSSH, évitez les formats non pris en charge tels que .ppk. Ensuite, reportez-vous à Gérer la configuration SSH pour ajouter la clé à votre cluster.

Linux et macOS

Les utilisateurs de Linux et de macOS peuvent accéder à leur nœud en utilisant kubectl debug ou leur adresse IP privée. Les utilisateurs Windows doivent passer à la section Windows Server Proxy pour une solution de contournement à SSH par le biais d’un proxy.

Se connecter en utilisant le débogage kubectl

Pour créer une connexion interactive d’interpréteur de commandes, utilisez la commande kubectl debug pour exécuter un conteneur privilégié sur votre nœud.

Pour lister vos nœuds, utilisez la commande kubectl get nodes suivante :

kubectl get nodes -o wide

Exemple de sortie :

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

Utilisez la commande kubectl debug pour démarrer un conteneur privilégié sur votre nœud et vous y connecter.
```
kubectl debug node/aks-nodepool1-37663765-vmss000000 -it --image=mcr.microsoft.com/cbl-mariner/busybox:2.0
```
Exemple de sortie :
```
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:/#
```
Vous avez maintenant accès au nœud par le biais d’un conteneur privilégié en tant que pod de débogage.

Remarque

Vous pouvez interagir avec la session de nœud en exécutant chroot /host à partir du conteneur privilégié.

Quitter le mode de débogage kubectl

Lorsque vous avez terminé avec votre nœud, entrez la commande exit pour mettre fin à la session d’interpréteur de commandes interactive. Une fois la session de conteneur interactive fermée, supprimez le pod de débogage avec kubectl delete pod.

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

Connexion proxy Windows Server pour SSH

Procédez comme solution de contournement pour vous connecter à SSH sur un nœud Windows Server.

Créer un serveur proxy

À ce stade, vous ne pouvez pas vous connecter à un nœud Windows Server directement à l’aide de kubectl debug. Au lieu de cela, vous devez d’abord vous connecter à un autre nœud du cluster à l’aide de kubectl, puis vous connecter au nœud Windows Server à partir de ce nœud à l’aide de SSH.

Pour vous connecter à un autre nœud du cluster, utilisez la commande kubectl debug. Pour plus d’informations, suivez les étapes ci-dessus dans la section kubectl. Pour créer une connexion SSH au nœud Windows Server à partir d’un autre nœud, utilisez les clés SSH fournies lors de la création du cluster AKS et l’adresse IP interne du nœud Windows Server.

Important

Les étapes suivantes pour créer la connexion SSH au nœud Windows Server à partir d’un autre nœud peuvent être utilisées seulement si vous avez créé votre cluster AKS en utilisant Azure CLI avec le paramètre --generate-ssh-keys. Si vous souhaitez utiliser vos propres clés SSH à la place, vous pouvez utiliser az aks update pour gérer les clés SSH sur un cluster AKS existant. Pour plus d’informations, consultez Gérer l’accès au nœud SSH.

Remarque

Si votre nœud proxy Linux est arrêté ou ne répond pas, utilisez la méthode Azure Bastion pour vous connecter à la place.

Utilisez la commande kubectl debug pour démarrer un conteneur privilégié sur votre nœud proxy (Linux) et vous y connecter.

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

Exemple de sortie :

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:/#

Ouvrez une nouvelle fenêtre de terminal et utilisez la commande kubectl get pods pour obtenir le nom du pod démarré par kubectl debug.
```
kubectl get pods
```
Exemple de sortie :
```
NAME                                                    READY   STATUS    RESTARTS   AGE
node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx   1/1     Running   0          21s
```
Dans l’exemple de sortie, node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx est le nom du pod démarré par kubectl debug.
Utilisez la commande kubectl port-forward pour ouvrir une connexion au pod déployé :
```
kubectl port-forward node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx 2022:22
```
Exemple de sortie :
```
Forwarding from 127.0.0.1:2022 -> 22
Forwarding from [::1]:2022 -> 22
```
L’exemple ci-dessus commence à transférer le trafic réseau du port 2022de votre ordinateur de développement vers le port 22sur le pod déployé. Lorsque vous utilisez kubectl port-forward pour ouvrir une connexion et transférer le trafic réseau, la connexion reste ouverte jusqu’à ce que vous arrêtiez la commande kubectl port-forward.
Ouvrez un nouveau terminal et exécutez la commande kubectl get nodes pour afficher l’adresse IP interne du nœud Windows Server :
```
kubectl get no -o custom-columns=NAME:metadata.name,'INTERNAL_IP:status.addresses[?(@.type == \"InternalIP\")].address'
```
Exemple de sortie :
```
NAME                                INTERNAL_IP
aks-nodepool1-19409214-vmss000003   10.224.0.8
```
Dans l’exemple ci-dessus, 10.224.0.62 est l’adresse IP interne du nœud Windows Server.
Créez une connexion SSH au nœud Windows Server à l’aide de l’adresse IP interne, et connectez-vous au port22par l’intermédiaire du port2022sur votre ordinateur de développement. Le nom d’utilisateur par défaut pour les nœuds AKS est azureuser. Acceptez l’invite pour poursuivre la connexion. Vous obtenez alors l’invite Bash de votre nœud Windows Server :
```
ssh -o 'ProxyCommand ssh -p 2022 -W %h:%p azureuser@127.0.0.1' azureuser@10.224.0.62
```
Exemple de sortie :
```
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
```
Remarque

Si vous préférez utiliser l’authentification par mot de passe, ajoutez le paramètre -o PreferredAuthentications=password. Par exemple :
```
 ssh -o 'ProxyCommand ssh -p 2022 -W %h:%p azureuser@127.0.0.1' -o PreferredAuthentications=password azureuser@10.224.0.62
```

Utiliser le conteneur de processus hôte pour accéder au nœud Windows

Créez hostprocess.yaml avec le contenu suivant et remplacez AKSWINDOWSNODENAME par le nom du nœud Windows AKS.

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

Exécutez kubectl apply -f hostprocess.yaml pour déployer le conteneur de processus hôte (HPC) Windows dans le nœud Windows spécifié.
Utiliser kubectl exec -it [HPC-POD-NAME] -- powershell.
Vous pouvez exécuter n’importe quelle commande PowerShell à l’intérieur du conteneur HPC pour accéder au nœud Windows.

Remarque

Vous devez basculer le dossier racine vers C:\ à l’intérieur du conteneur HPC pour accéder aux fichiers dans le nœud Windows.

SSH à l’aide d’Azure Bastion pour Windows

Si votre nœud proxy Linux n’est pas accessible, l’utilisation d’Azure Bastion en tant que proxy est une alternative. Cette méthode nécessite que vous configurez un hôte Azure Bastion pour le réseau virtuel dans lequel réside le cluster. Pour plus d’informations, consultez Se connecter à Azure Bastion.

SSH à l’aide d’adresses IP privées à partir de l’API AKS (préversion)

Si vous n’avez pas accès à l’API Kubernetes, vous pouvez accéder aux propriétés telles que Node IP et Node Name à l’aide de l’API pool d’agents AKS (préversion), (disponible pour les préversions 07-02-2023 ou ultérieures) pour connecter les nœuds AKS.

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

Créer une connexion interactive d’interpréteur de commandes à un nœud à l’aide de l’adresse IP

Par souci de commodité, les nœuds AKS sont exposés sur le réseau virtuel du cluster par le biais d’adresses IP privées. Vous devez toutefois être dans le réseau virtuel du cluster pour se connecter à SSH dans le nœud. Si vous n’avez pas encore configuré d’environnement, vous pouvez utiliser Azure Bastion pour établir un proxy à partir duquel vous pouvez utiliser SSH pour les nœuds de cluster. Assurez-vous qu’Azure Bastion est déployé dans le même réseau virtuel que le cluster.

Obtenez des adresses IP privées à l’aide de la commande az aks machine list, ciblant toutes les machines virtuelles d’un pool de nœuds spécifique avec l’indicateur --nodepool-name.

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

L’exemple de sortie suivant montre les adresses IP internes de tous les nœuds du pool de nœuds :

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

Pour cibler un nœud spécifique à l’intérieur du pool de nœuds, utilisez l’indicateur --machine-name :

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

L’exemple de sortie suivant montre l’adresse IP interne de tous les nœuds spécifiés :

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

SSH vers le nœud à l’aide de l’adresse IP privée que vous avez obtenue à l’étape précédente. Cette étape s’applique uniquement aux machines Linux. Pour les machines Windows, consultez Se connecter à l’aide d’Azure Bastion.
```
ssh -i /path/to/private_key.pem azureuser@10.224.0.33
```

Étapes suivantes

Si vous avez besoin de données de dépannage supplémentaires, vous pouvez Afficher les journaux d’activité kubelet ou Afficher les journaux d’activité du plan de contrôle Kubernetes.

Pour en savoir plus sur la gestion de vos clés SSH, consultez Gérer la configuration SSH.

Partager via