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 avec l'option --image=us.icr.io/armada-master/network-alpine:latest, qui utilise une image provenant de IBM Cloud Container Registry accessible sur 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 pour le débogage dans votre propre dépôt ICR ou créer une image personnalisée avec d'autres outils pour répondre à 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 obtenir des journaux ou d'autres fichiers d'un nœud de travail, utilisez la commande " **kubectl cp** dans le format suivant. L'exemple suivant extrait le fichier " /var/log/messages 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 déboguer, telles que 'dig, 'tcpdump, 'mtr, '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 " conntrack, en exécutant " apk add <tool>. Par exemple, pour ajouter le " conntrack, exécutez le " 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 pour le débogage dans votre propre dépôt ICR ou créer une image personnalisée avec d'autres outils pour répondre à 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.