Debugging mithilfe von kubectl debug

Verwenden Sie den Befehl kubectl debug node, um einen Pod mit einem privilegierten Sicherheitskontext (securityContext) für einen Workerknoten bereitzustellen, für den Sie eine Fehlerbehebung durchführen möchten.

Der Debug-Pod wird mit einer interaktiven Shell implementiert, so dass Sie unmittelbar nach der Erstellung des Pods auf den Workerknoten zugreifen können. Weitere Informationen zur Funktionsweise des Befehls kubectl debug node finden Sie unter debug command in der Kubernetes-Referenz.

1. Rufen Sie den Namen des Workerknotens auf, auf den Sie zugreifen möchten. Für CoreOS-Workerknoten ist der Name der Hostname des Workers. Für alle anderen Workerknoten ist der Name des Workerknotens die private IP-Adresse.

   kubectl get nodes -o wide
   

2. Erstellen Sie einen Debug-Pod, der über den Hostzugriff verfügt. Bei der Erstellung des Pods wird die interaktive Shell des Pods automatisch geöffnet. Wenn der Befehl kubectl debug node fehlschlägt, fahren Sie mit der Option 2 fort.

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

3. Führen Sie Debugbefehle aus, um Informationen zu sammeln und Probleme zu beheben. Befehle, die für das Debugging verwendet werden können, wie z. B. tcpdump, curl, ip, ifconfig, nc, pingund ps, sind bereits in der Shell verfügbar. Sie können auch andere Tools installieren, wie beispielsweise mtr und conntrack, indem Sie apk add <tool> ausführen.

Debugging mithilfe von kubectl exec

Wenn Sie den Befehl kubectl debug node nicht verwenden können, dann können Sie einen Alpine-Pod mit einem privilegierten Sicherheitskontext (securityContext) erstellen und den Befehl kubectl exec verwenden, um Debugbefehle von der interaktiven Shell des Pods auszuführen.

1. Rufen Sie den Namen des Workerknotens auf, auf den Sie zugreifen möchten. Für CoreOS-Workerknoten ist der Name der Hostname des Workers. Für alle anderen Workerknoten ist der Name des Workerknotens die private IP-Adresse.

   kubectl get nodes -o wide
   

2. Exportieren Sie den Namen in eine Umgebungsvariable.

   export NODE=<NODE_NAME>
   

3. Erstellen Sie einen Debug-Pod auf dem Workerknoten Das Alpine Docker-Image hier wird als Beispiel verwendet. Falls der Worker-Knoten keinen Zugang zum öffentlichen Netzwerk hat, können Sie eine Kopie des Images zu Debugging-Zwecken in Ihrem eigenen ICR-Repository verwalten oder mit anderen Tools ein an Ihre Anforderungen angepasstes Image erstellen.

   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. Melden Sie sich beim Debug-Pod an. Die interaktive Shell des Pods wird automatisch geöffnet. Wenn der Befehl kubectl exec fehlschlägt, fahren Sie mit der Option 3 fort.

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

   Sie können den kubectl cp Befehl verwenden, um Protokolle oder andere Dateien von einem Worker-Knoten abzurufen. Das folgende Beispiel ruft die Datei „ /var/log/syslog “ ab.

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

   Rufen Sie die folgenden Protokolle ab, um nach Problemen auf dem Workerknoten zu suchen.

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

5. Führen Sie Debugbefehle aus, um Informationen zu sammeln und Probleme zu beheben. Befehle, die Sie zum Debuggen verwenden können, wie beispielsweise „ dig “, „ tcpdump “, „ mtr “, „ curl “, „ ip “, „ ifconfig “, „ nc “, „ ping “ und „ ps “, sind in der Shell bereits verfügbar. Sie können auch andere Tools, wie beispielsweise „ conntrack “, installieren, indem Sie den Befehl „ apk add <tool> “ ausführen. Um beispielsweise „ conntrack “ hinzuzufügen, führen Sie „ apk add conntrack-tools “ aus.

6. Löschen Sie den Host-Zugriffsbereich, den Sie für das Debugging erstellt haben.

   kubectl delete pod debug-${NODE}
   

Debugging durch Aktivieren des SSH-Rootzugriffs auf einem Workerknoten

Wenn Sie die Befehle kubectl debug node oder kubectl exec nicht verwenden können, z. B. wenn die VPN-Verbindung zwischen den Master- und Workerknoten des Clusters inaktiv ist, können Sie einen Pod erstellen, der den SSH-Rootzugriff ermöglicht und einen öffentlichen SSH-Schlüssel auf den Workerknoten für den SSH-Zugriff kopiert.

Der Zugriff auf den SSH-Rootzugriff ist ein Sicherheitsrisiko. Erlauben Sie den SSH-Zugang nur dann, wenn er erforderlich ist und keine andere Option zur Fehlerbehebung bei Workerknoten-Problemen zur Verfügung steht. Wenn Sie die Fehlerbehebung fertiggestellt haben, müssen Sie die Schritte im Abschnitt Bereinigung nach Debugging ausführen, um den SSH-Zugriff zu inaktivieren.

1. Wählen Sie einen vorhandenen Schlüssel aus oder erstellen Sie einen neuen öffentlichen SSH-Schlüssel.

   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. Rufen Sie den Namen des Workerknotens auf, auf den Sie zugreifen möchten. Für CoreOS-Workerknoten ist der Name der Hostname des Workers. Für alle anderen Workerknoten ist der Name des Workerknotens die private IP-Adresse.

   kubectl get nodes -o wide
   

3. Erstellen Sie die folgende YAML-Datei für einen Debug-Pod und speichern Sie die Datei als enable-ssh.yaml. Ersetzen Sie <NODE_NAME> durch den Namen des Workerknotens und ersetzen Sie das value-Beispiel für SSH_PUBLIC_KEY durch Ihren öffentlichen SSH-Schlüssel. Das Alpine Docker-Image hier wird als Beispiel verwendet. Falls der Worker-Knoten keinen Zugang zum öffentlichen Netzwerk hat, können Sie eine Kopie des Images zu Debugging-Zwecken in Ihrem eigenen ICR-Repository speichern oder mit anderen Tools ein an Ihre Anforderungen angepasstes Image erstellen.

   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. Erstellen Sie den Pod in Ihrem Cluster. Wenn dieser Pod erstellt wird, wird der öffentliche Schlüssel zum Workerknoten hinzugefügt, und SSH ist so konfiguriert, dass die Root-SSH-Anmeldung zulässig ist.

   kubectl apply -f enable-ssh.yaml
   

5. Verwenden Sie das private oder öffentliche Netz, um über Ihren SSH-Schlüssel auf den Workerknoten zuzugreifen.