Débogage avec la commande oc debug

Utilisez la commande oc debug node pour déployer un pod avec un contexte securityContext privilégié sur un noeud worker pour lequel vous souhaitez effectuer une opération de traitement des 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 oc debug node, voir Ce post de blogue Red Hat.

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.

   oc 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 oc debug node échoue, passez à l'option 2.

   oc debug node/<NODE_NAME>
   

   Si la commande oc debug node/<NODE_NAME> échoue, il se peut que des règles de groupe de sécurité, de liste de contrôle d'accès ou de pare-feu empêchent l'extraction de l'image de conteneur par défaut. Réessayez la commande en utilisant l'option « --image=us.icr.io/armada-master/network-alpine:latest », qui utilise une image provenant de IBM Cloud Container Registry et accessible via le réseau privé.

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 yum install <tool>.

Débogage avec la commande kubectl exec

Si vous ne parvenez pas à utiliser la commande oc debug node, vous pouvez créer un pod Alpine avec un contexte 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.

   oc 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
   

   Pour récupérer des fichiers journaux ou d'autres fichiers depuis un nœud de travail, utilisez la commande « **kubectl cp** » selon le format suivant. L'exemple suivant récupère le fichier « /var/log/messages » à partir du système de fichiers hôte du nœud de travail.

   oc cp default/debug-${NODE}:/host/var/log/messages ./messages
   

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

   /var/log/messages
   /var/log/kubelet.log
   /var/log/crio.log
   /var/log/calico/cni/cni.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 vous ne parvenez pas à utiliser les commandes oc debug node ou kubectl exec, par exemple si la connexion VPN entre le maître cluster et les noeuds worker est rompue, vous pouvez créer un pod qui active l'accès SSH racine et copie une clé SSH publique sur le noeud worker pour un 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.

   oc 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.

   oc 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.