Debug-Pod im GitOps-Cluster: Warum ein eigener Debug-Namespace nichts bringt

Kurze Antwort: Den Debug-Pod startest du genau da, wo das Problem sitzt. Im selben Namespace.

ArgoCD lässt ihn dort laut Doku in Ruhe. Und ein eigener Debug-Namespace hilft nicht. Ist das Netz offen, isoliert er nichts. Ist es per NetworkPolicy dicht, blockiert es deinen Debug-Pod und nicht die App.

Was ist ein Debug-Pod?

Ein Debug-Pod ist ein Pod, den du von Hand startest, um dem Problem von innen auf den Zahn zu fühlen. Die App-Images haben meist keine Werkzeuge an Bord, also bringst du ein kleines Image mit Shell und Netzwerkwerkzeugen mit, zum Beispiel busybox. Das Beispiel: Die App im Namespace shop erreicht ihre Datenbank db nicht.

kubectl run debug -n shop -it --rm --image=busybox --restart=Never -- sh
# in der Shell:
nslookup db

Antwortet DNS, weißt du schon mal: Der Name stimmt. Der Pod ist weg, sobald du die Shell verlässt (--rm). Die Alternative ohne eigenen Pod: kubectl debug -it <pod> -n shop --image=busybox hängt einen Debug-Container an den Pod, der Probleme macht. Dazu unten mehr.

Die Frage aus dem Training

Ende September, Einführungstraining, wir waren gerade beim Debuggen. Ein Teilnehmer wollte wissen: Wirft ArgoCD einen von Hand gestarteten Debug-Pod nicht sofort wieder raus? GitOps setzt doch den Soll-Zustand durch.

Gute Frage. Denn die naheliegende Ausweichbewegung ist: „Dann mach ich halt einen Namespace debug auf, da redet mir keiner rein.“ Ein englischer GitOps-Blog empfiehlt genau das: einen eigenen Debug-Namespace, den ArgoCD gar nicht verwaltet.

Meine Antwort damals wie heute: Debuggen gehört in den Namespace des Problems. Ein Debug-Namespace bringt nichts.

ArgoCD ist Hausmeister, kein Türsteher

ArgoCD schmeißt nicht jeden raus, der nicht auf der Gästeliste steht. Er ist eher ein Hausmeister mit Plaketten. Alles, was er verwaltet, kriegt seine Plakette: seit Argo CD 3.0 standardmäßig die Annotation argocd.argoproj.io/tracking-id, vorher ein Label.

Dein Debug-Pod hat keine Plakette. Gehört zu keiner Application. Für den Hausmeister ist das Gerümpel, das irgendwer abgestellt hat, nicht sein Bier. Die Argo-CD-Doku nennt so was eine verwaiste Ressource. Schaltest du die Überwachung im Projekt ein, zeigt er sie an und schreibt auf Wunsch eine Warnung. Von allein weggeräumt wird nichts.

Prune räumt nur weg, was eine Plakette hat und aus Git verschwunden ist. Self-Heal dreht nur Handänderungen an Plaketten-Ressourcen zurück. Dein Debug-Pod fällt durch beide Raster.

Ganz ehrlich: Im Labor provoziert habe ich das noch nicht. Die Doku ist an der Stelle aber eindeutig. Wegen ArgoCD musst du also nicht umziehen.

Ein Namespace ist ein Schreibtisch im Großraumbüro

Jetzt der eigentliche Denkfehler. Ein eigener Namespace fühlt sich nach Abschottung und Trennung an. Dem ist nicht so.

Stell dir ein offenes Büro vor. Jeder hat seinen eigenen Schreibtisch. Das ist ein Namespace: ein virtueller Arbeitsbereich, in dem du Namen, Rechte und Quotas sortierst. Trotzdem kann jeder zum Schreibtisch des anderen gehen. Ohne NetworkPolicy ist jeder Pod laut Kubernetes-Doku in beide Richtungen offen, egal an welchem Schreibtisch er sitzt. Das ändert sich erst, wenn du Wände einziehst, zum Beispiel mit einer NetworkPolicy.

Das erlebe ich mit Umsteigern immer wieder. Im August saß einer mit Docker- und Podman-Hintergrund im Training. Er wollte wissen, wie jede Anwendung ihr eigenes Netz kriegt. So wie er’s von VLANs kannte. Meine Antwort: Gibt’s im Standard-Kubernetes so nicht. Da redet jeder Pod mit jedem, egal auf welchem Node. Einschränken geht erst mit NetworkPolicies (warum du dein Docker-Compose-Netzwerkwissen dafür wegwerfen kannst, steht dort).

Für deinen Debug-Pod heißt das: Ist das Netz offen, kommt er im Namespace shop wie im Namespace debug an dieselben Pods ran. Isoliert ist da nix. Du hast dir nur einen anderen Schreibtisch im selben offenen Büro genommen.

In der Praxis sind aber oft Wände eingezogen. Viele Cluster sperren per NetworkPolicy alles, was nicht ausdrücklich erlaubt ist, und genau darauf sind Namespaces dann gegeneinander abgeschottet. Das ist gut für die Sicherheit und schlecht für deinen Debug-Namespace. Dein Debug-Pod aus debug steht nicht auf der Liste der Erlaubten. Er läuft gegen die Wand, die App kommt durch.

Im Debug-Namespace misst du etwas anderes

Es kommt noch schlimmer: Im Debug-Namespace misst du etwas anderes als das, was deine Anwendung erlebt. Dafür gibt es zwei Gründe.

Erstens: DNS. Kurze Namen wie db löst Kubernetes im Namespace des fragenden Pods auf. Dein Debug-Pod im Namespace debug fragt nach db und findet nichts. Die App im Namespace shop findet ihre Datenbank. Und du jagst einen DNS-Fehler, den es gar nicht gibt.

Zweitens: Wände. Im Praxis-Cluster sind meist welche eingezogen. Lässt die Datenbank nur Pods aus dem Namespace shop rein, blockt sie deinen Debug-Pod, obwohl die App durchkommt. Fehlalarm, und du suchst einen Fehler, den es nicht gibt. Das kann dich einen Nachmittag kosten.

Am genauesten misst du mit kubectl debug. kubectl debug <pod> -it --image=busybox hängt dich direkt ins Netz des kaputten Pods. Ein Debug-Container mehr, gleicher Namespace, gleiches Netz, gleiche Policies. Du siehst exakt das Netz, das die App sieht. Und hat das Image deiner App keine Shell, kommst du so trotzdem rein.

Meine Regel

Debugge da, wo’s brennt: im Namespace des Problems, am liebsten mit kubectl debug direkt im Pod. ArgoCD lässt dich in Ruhe, solange dein Debug-Pod nicht in Git steht. Und hinterher räumst du auf: Einen Test-Pod löschst du, ein Debug-Container verschwindet erst mit seinem Pod.

Wie ein Test-Pod per kubectl run aussieht, zeige ich in meiner Anleitung zum Netzwerk-Debuggen mit einem Test-Pod. Dort liegen App und Test-Pod in einem gemeinsamen Übungs-Namespace, also genau nach dieser Regel.

Debuggen am Live-Cluster gehört in meinem Training Kubernetes Einführung fest dazu. Genau da kam diese Frage auch auf.