Débogage à l'aide de la commande kubectl debug

Utilisez la commande kubectl debug node pour déployer un pod avec un securityContext privilégié sur un noeud worker dont vous souhaitez traiter les incidents.

Le pod de débogage est déployé avec un interpréteur de commandes interactif afin de vous permettre d'accéder au noeud worker juste après la création du pod. Pour plus d'informations sur le fonctionnement de la commande kubectl debug node, voir debug command in Kubernetes reference.

1. Obtenez le nom du noeud worker auquel vous souhaitez accéder. Pour les noeuds worker CoreOS, le nom est le nom d'hôte de l'agent. Pour tous les autres noeuds worker, le nom de noeud worker est l'adresse IP privée.

   kubectl get nodes -o wide
   

2. Créez un pod de débogage qui dispose d'un accès hôte. Lorsque le pod est créé, son interpréteur de commandes interactif s'ouvre automatiquement. Si la commande kubectl debug node échoue, passez à l'option 2.

   kubectl debug --image=us.icr.io/armada-master/network-alpine:latest -it node/<NODE_NAME> -- sh
   

3. Exécutez des commandes de débogage pour collecter des informations et traiter les incidents. Les commandes que vous pouvez utiliser pour le débogage, par exemple tcpdump, curl, ip, ifconfig, nc, ping et ps, sont déjà disponibles dans l'interpréteur de commandes. Vous pouvez également installer d'autres outils, tels que mtr et conntrack, en exécutant apk add <tool>.

Débogage à l'aide de la commande kubectl exec

Si la commande kubectl debug node ne peut pas être utilisée, vous pouvez créer un pod Alpine avec un securityContext privilégié et utiliser la commande kubectl exec pour exécuter des commandes de débogage à partir de l'interpréteur de commandes interactif du pod.

1. Obtenez le nom du noeud worker auquel vous souhaitez accéder. Pour les noeuds worker CoreOS, le nom est le nom d'hôte de l'agent. Pour tous les autres noeuds worker, le nom de noeud worker est l'adresse IP privée.

   kubectl get nodes -o wide
   

2. Exportez le nom dans une variable d'environnement.

   export NODE=<NODE_NAME>
   

3. Créez un pod de débogage sur le noeud worker. L'image Alpine Docker ici est utilisée à titre d'exemple. Si le nœud de travail ne dispose pas d'un accès au réseau public, vous pouvez conserver une copie de l'image à des fins de débogage dans votre propre référentiel ICR ou créer une image personnalisée à l'aide d'autres outils afin de l'adapter à vos besoins.

   kubectl apply -f - << EOF
   apiVersion: v1
   kind: Pod
   metadata:
     name: debug-${NODE}
     namespace: default
   spec:
     tolerations:
     - operator: "Exists"
     hostNetwork: true
     containers:
     - args: ["-c", "sleep 20d"]
       command: ["/bin/sh"]
       image: us.icr.io/armada-master/network-alpine:latest
       imagePullPolicy: Always
       name: debug
       securityContext:
         privileged: true
       volumeMounts:
       - mountPath: /host
         name: host-volume
     volumes:
     - name: host-volume
       hostPath:
         path: /
     nodeSelector:
       kubernetes.io/hostname: ${NODE}
     restartPolicy: Never
   EOF
   

4. Connectez-vous au pod de débogage. L'interpréteur de commandes interactif du pod s'ouvre automatiquement. Si la commande kubectl exec échoue, passez à l'option 3.

   kubectl exec -it debug-${NODE} -- sh
   

   Vous pouvez utiliser la kubectl cp commande pour récupérer les fichiers journaux ou d'autres fichiers depuis un nœud de travail. L'exemple suivant récupère le fichier « /var/log/syslog ».

   kubectl cp --retries 20 default/debug-${NODE}:/host/var/log/syslog ./syslog
   

   Récupèrez les journaux suivants pour rechercher des problèmes sur le noeud worker.

   /var/log/syslog
   /var/log/containerd.log
   /var/log/kubelet.log
   /var/log/kern.log
   

5. Exécutez des commandes de débogage pour collecter des informations et traiter les incidents. Les commandes que vous pourriez utiliser pour le débogage, telles que dig, tcpdump, mtr, curl, ip, ifconfig, nc, ping et ps, sont déjà disponibles dans le shell. Vous pouvez également installer d'autres outils, tels que conntrack, en exécutant apk add <tool>. Par exemple, pour ajouter conntrack, exécutez apk add conntrack-tools.

6. Supprimez le pod d'accès hôte que vous avez créé à des fins de débogage.

   kubectl delete pod debug-${NODE}
   

Débogage en activant l'accès SSH root sur un noeud worker

Si la commande kubectl debug node ou kubectl exec ne peut pas être utilisée, comme par exemple lorsque la connexion VPN entre le maître et les noeuds worker du cluster est arrêtée, vous pouvez créer un pod qui autorise l'accès SSH root et copie une clé SSH publique sur le noeud worker pour l'accès SSH.

Autoriser l'accès SSH racine entraîne un risque de sécurité. Vous ne devez autoriser l'accès SSH que lorsque cela est nécessaire et qu'aucune autre option ne permet de déboguer les problèmes de noeud worker. Lorsque vous avez terminé l'identification et la résolution des incidents, veillez à suivre les étapes de la section Nettoyage après le débogage pour désactiver l'accès SSH.

1. Choisissez une clé SSH publique existant ou créez-en une nouvelle.

   ssh-keygen -f /tmp/id_rsa_cluster_worker -t rsa -b 4096 -C temp-worker-ssh-key -P ''
   ls /tmp
   

   id_rsa_cluster_worker id_rsa_cluster_worker.pub
   

   cat /tmp/id_rsa_cluster_worker.pub
   

2. Obtenez le nom du noeud worker auquel vous souhaitez accéder. Pour les noeuds worker CoreOS, le nom est le nom d'hôte de l'agent. Pour tous les autres noeuds worker, le nom de noeud worker est l'adresse IP privée.

   kubectl get nodes -o wide
   

3. Créez le fichier YAML suivant pour un pod de débogage et sauvegardez-le fichier sous le nom enable-ssh.yaml. Remplacez <NODE_NAME> par le nom du noeud worker et remplacez l'exemple value pour SSH_PUBLIC_KEY par votre clé SSH publique. L'image Alpine Docker ici est utilisée à titre d'exemple. Si le nœud de travail ne dispose pas d'un accès au réseau public, vous pouvez conserver une copie de l'image dans votre propre référentiel ICR à des fins de débogage, ou créer une image personnalisée à l'aide d'autres outils afin de l'adapter à vos besoins.

   apiVersion: v1
   kind: Pod
   metadata:
     name: enable-ssh-<NODE_NAME>
     labels:
       name: enable-ssh
   spec:
     tolerations:
     - operator: "Exists"
     hostNetwork: true
     hostPID: true
     hostIPC: true
     containers:
     - image: us.icr.io/armada-master/network-alpine:latest
       env:
       - name: SSH_PUBLIC_KEY
         value: "<ssh-rsa AAA...ZZZ temp-worker-ssh-key>"
       args: ["-c", "echo $(SSH_PUBLIC_KEY) | tee -a /root/.ssh/authorized_keys && sed -i 's/^#*PermitRootLogin.*/PermitRootLogin yes/g' /host/etc/ssh/sshd_config && sed -i 's/^#*PermitRootLogin.*/PermitRootLogin yes/g' /host/etc/ssh/sshd_config.d/40-rhcos-defaults.conf || true && killall -1 sshd || yes n | ssh-keygen -f /host/etc/ssh/ssh_host_rsa_key -t rsa -b 4096 -C temp-server-ssh-key -P '' && while true; do sleep 86400; done"]
       command: ["/bin/sh"]
       name: enable-ssh
       securityContext:
         privileged: true
       volumeMounts:
       - mountPath: /host
         name: host-volume
       - mountPath: /root/.ssh
         name: ssh-volume
     volumes:
     - name: host-volume
       hostPath:
         path: /
     - name: ssh-volume
       hostPath:
         path: /root/.ssh
     nodeSelector:
       kubernetes.io/hostname: <NODE_NAME>
     restartPolicy: Never
   

4. Créez le pod dans votre cluster. Lorsque ce pod est créé, votre clé publique est ajoutée au noeud worker et SSH est configuré pour autoriser la connexion SSH racine.

   kubectl apply -f enable-ssh.yaml
   

5. Utilisez le réseau privé ou le réseau public pour accéder au noeud worker à l'aide de votre clé SSH.