Drei Aussagen, drei Prüfungen
Synced: Der von Argo CD verglichene Live-Zustand entspricht dem gerenderten Soll, soweit der Vergleich ihn berücksichtigt. Das ist eine wertvolle Aussage über die Auslieferung. Es ist kein Geschäftsrequest und kein Beleg dafür, dass jede externe Abhängigkeit funktioniert.
Ready: Die konfigurierten Bereitschaftsbedingungen sind erfüllt. Eine Readiness Probe kann bewusst nur einen Teil der Anwendung prüfen. Sie startet den Container bei einem Fehler nicht neu; Startup und Liveness erfüllen andere Aufgaben.
Ein erfolgreicher Request: Ein bestimmter Pfad hat mit bestimmten Eingaben, einer bestimmten Identität und zu einem bestimmten Zeitpunkt funktioniert. Auch das ist begrenzte Evidenz. Die Kunst besteht darin, einen für die Betriebsentscheidung repräsentativen Pfad zu wählen.
Den Widerspruch eingrenzen
Angenommen, der Rollout ist Synced und die Pods sind Ready, aber eine Funktion liefert AccessDenied. Ich würde nicht als Erstes den Rollout wiederholen. Die belegte Frage lautet jetzt: Welche Identität ruft welche Aktion an welcher Ressource auf? GitOps kann die gewünschte Konfiguration erfolgreich ausliefern, obwohl diese fachlich eine Berechtigung vermissen lässt.
Bei einem Timeout ist die nächste Prüfung anders: Namensauflösung, Verbindungsaufbau, TLS und Zielzustand getrennt betrachten. Dasselbe sichtbare Anwendungssymptom kann an unterschiedlichen Grenzen entstehen. Ein Diagnoseplan sollte sich durch neue Befunde ändern dürfen.
Eine Korrektur braucht zwei Abschlüsse
Erstens muss der betroffene Anwendungspfad wieder funktionieren. Zweitens muss die Korrektur im System der Zuständigkeiten bestehen bleiben. Ein Live-Patch kann beim nächsten GitOps-Abgleich verschwinden. Eine Änderung in Git kann wirkungslos bleiben, wenn sie die betroffene Revision noch nicht erreicht hat.
Deshalb prüfe ich Wirkung und Dauerhaftigkeit getrennt: denselben Request wiederholen, den angewandten Stand zuordnen und den nächsten regulären Abgleich beobachten. Ein grüner Status ist dabei ein Signal. Die Erklärung, warum der Fehler nicht wiederkehrt, ist das Ergebnis.
Nachstellen: Readiness 200, Geschäftsrequest 503
Reproduzierbares Lernbeispiel mit synthetischen Daten. Kein Bericht über ein Arbeitgeber- oder Kundenprojekt.
Ein grüner Status kann korrekt und trotzdem unzureichend sein. Im Beispiel beantwortet eine Anwendung „/ready“ erfolgreich. Für „/report“ muss sie zusätzlich eine Abhängigkeit aufrufen, die den Zugriff verweigert.
Lokal ausführen
Python 3 genügt. Das Skript startet zwei kurzlebige HTTP-Server ausschließlich auf 127.0.0.1 und wählt freie Ports. Es benötigt keine Cloud-Zugangsdaten, schreibt keine Dateien und beendet beide Server selbst. Nach dem Download ausführen:
Python-Beispiel herunterladen · readiness-boundary.py
python readiness-boundary.pyAusgabe des Beispiels
GET /ready: 200 ready
Dependency GET /records: 403 AccessDenied
GET /report: 503 dependency denied access
Result: readiness passed; the business request failedDer 200-Status belegt nur die erfolgreiche Readiness-Antwort. Der direkte Aufruf der modellierten Abhängigkeit grenzt den Fehler auf eine Zugriffsverweigerung ein; die Anwendung übersetzt sie in 503. Diese Übersetzung ist eine Entscheidung des Beispiels, kein allgemeines Verhalten von Kubernetes oder AWS. Ein 403 allein identifiziert noch keine konkrete fehlerhafte Policy.
Den realen Befund lesen
In einer passenden Kubernetes-/Argo-CD-Umgebung beginnen beispielsweise diese lesenden Abfragen die Einordnung. „argocd“, „reporting“ und „reports“ sind Beispielnamen und müssen an die vorhandene Installation angepasst werden. Die Befehle wurden für dieses lokale Modell nicht gegen einen Cluster ausgeführt.
kubectl -n argocd get application reports -o yaml
kubectl -n reporting get deployment reports -o yaml
kubectl -n reporting get pods -l app=reports -o wide
kubectl -n reporting logs deployment/reports --since=10m --timestamps=trueBeim Application-Objekt: Revision, Sync und Health unterscheiden. Im Deployment: prüfen, was die Readiness Probe tatsächlich aufruft. Bei mehreren Pods und Containern den betroffenen Request der richtigen Instanz zuordnen; das letzte Kommando erfasst nicht automatisch alle Replikate. In Logs nach Zeitpunkt, Korrelations-ID und konkretem Abhängigkeitsfehler suchen. Interne Logs nicht ungeprüft veröffentlichen.
Die nächste Prüfung richtet sich nach der Grenze
Bei einer echten Zugriffsverweigerung zuerst Identität, Aktion und Ressource des tatsächlichen Workloads feststellen. Ein Test mit Administratorrechten beantwortet diese Frage nicht. Auch sollte nicht jede externe Abhängigkeit pauschal Teil der Readiness Probe werden: Fällt eine gemeinsame Abhängigkeit aus, können sonst alle Replikate zugleich aus dem Service-Traffic genommen werden. Die Probe muss zur gewünschten Betriebsentscheidung passen.
Das Skript demonstriert eine HTTP-Grenze, keine Kubernetes- oder Argo-CD-Installation. Es kann weder einen realen Synced-Status noch IAM-Berechtigungen beweisen. Gerade diese getrennten Aussagen sind der Punkt des Beispiels.