kubectl node-shell: Shell-Zugriff auf jeden Kubernetes Node

Das Problem

Ein Pod verhält sich seltsam. Du hast die Logs geprüft. Du hast dich in den Container exec’d. Aber das Problem liegt nicht im Pod – es liegt auf dem Node selbst.

Vielleicht ist es ein Disk-Pressure-Problem. Vielleicht ein Netzwerkproblem auf Host-Ebene. Vielleicht musst du kubelet-Logs prüfen, die Container-Runtime inspizieren oder schauen, was auf dem eigentlichen Linux-Host passiert.

Normalerweise würdest du dich per SSH auf den Node verbinden. Aber in modernen Kubernetes-Umgebungen – Managed Clusters auf EKS, GKE, AKS oder gehärteten On-Premise-Setups – ist SSH-Zugriff auf Nodes oft eingeschränkt, deaktiviert oder erfordert viele Zwischenschritte.

kubectl node-shell

kubectl node-shell startet einen privilegierten Pod auf dem Ziel-Node, der dir eine Root-Shell auf dem Host gibt – direkt aus kubectl heraus, ohne SSH.

Ein Befehl. Voller Node-Zugriff. Kein SSH erforderlich.

Du brauchst RBAC-Rechte für privilegierte Pods und das Plugin. Wenn deine Rolle das nicht darf, ist das gewollte Policy.

Installation

Via krew:

kubectl krew install node-shell

Kontext zuerst prüfen – kubectx & kubens. Für die Pod-Ebene: k9s und stern; node-shell, wenn es unter dem kubelet liegt.

Grundlegende Verwendung

# Shell auf einem bestimmten Node öffnen
kubectl node-shell my-node-name

# Verfügbare Nodes auflisten
kubectl get nodes

# Dann verbinden
kubectl node-shell k8s-worker-01

Das war es. Du landest innerhalb von Sekunden in einer Root-Shell auf dem Node.

Was du aus einer Node-Shell tun kannst

Mit Node-Zugriff kannst du Dinge untersuchen, die von innerhalb eines Pods schlicht nicht sichtbar sind:

kubelet Status und Logs prüfen:

systemctl status kubelet
journalctl -u kubelet -n 100

Disk-Nutzung auf Host-Ebene inspizieren:

df -h
du -sh /var/lib/docker/*
du -sh /var/lib/containerd/*

Node-Netzwerk prüfen:

ip addr show
ip route show
iptables -L -n
ss -tulpn

Container-Runtime direkt inspizieren:

# Für containerd
crictl ps
crictl logs <container-id>
crictl inspect <container-id>

# Für Docker (ältere Setups)
docker ps
docker stats

Systemressourcen prüfen:

top
free -h
cat /proc/meminfo
dmesg | tail -50

OOM Kills untersuchen:

dmesg | grep -i "oom\|killed"
journalctl -k | grep -i oom

Wie es funktioniert

kubectl node-shell erstellt einen temporären privilegierten Pod mit hostPID: true, hostNetwork: true und hostIPC: true, eingehängt in das Host-Dateisystem. Dann exec’d es in diesen Pod mit nsenter, um die Namespaces des Nodes zu betreten – was dir eine Shell gibt, die auf Host-Ebene operiert, nicht auf Container-Ebene.

Beim Beenden wird der Pod automatisch gelöscht.

Wichtig: Mit Bedacht verwenden

node-shell gibt dir Root-Zugriff auf den Host. Das ist mächtig und bei Missbrauch gefährlich:

• Auf Production-Nodes immer nur lesend / untersuchend vorgehen
• Vorsicht bei Schreiboperationen – du bist auf dem echten Host
• In regulierten Umgebungen sollte node-shell Zugriff geloggt und auditiert werden
• Eine node-shell Session niemals offen und unbeaufsichtigt lassen

Das Tool ist für Debugging konzipiert, nicht für Routineoperationen. Entsprechend behandeln.

Auf Pod-Ebene bleiben kubectl tree und kubectl neat im Werkzeugkasten.

Wann Pod-Zugriff nicht ausreicht

Zusammenfassung

Wenn das Problem unterhalb der Pod-Ebene liegt, ist kubectl node-shell der schnellste Weg zur Wahrheit.