01
Zusammengehörige Objekte einfügen
Trennen Sie Ingress und Service mit --- und ergänzen Sie optional Deployment oder Pod. Ein gleichnamiger Service in einem anderen Namespace zählt nicht als Backend.
Kubernetes / Helm
Ingress Pfad prüfen
Fügen Sie gerendertes YAML ein und prüfen Sie einen konkreten Host mit einem Pfad.
Ingress Pfad prüfen
Routenbericht
Manifest einfügen oder Beispiel laden.
Analyse im Browser; keine Clusterverbindung und keine HTTP-Anfrage.
Anfrageeinstellungen
Exact und Prefix folgen Kubernetes; Controllerregeln werden nicht simuliert.
Grenzen: 300.000 Zeichen, 100 Ressourcen, 500 Pfade.
Manifest einfügen oder Beispiel laden.
Ein Ingress kann einen passenden Pfad haben und trotzdem auf einen Port zeigen, den der Service nicht anbietet. Mit Ingress Pfad prüfen sehen Sie die Referenzkette für genau eine Anfrage.
Das Ergebnis beschreibt die eingefügten Manifeste. Es misst weder den Cluster noch die Antwort der Anwendung und trennt deshalb sichere Brüche von fehlenden Laufzeitdaten.
Warum Ingress Pfad prüfen?
Die gewählte Regel bis zum Zielport verfolgen
Ingress Pfad prüfen wählt den längsten passenden Pfad und bei Gleichstand Exact vor Prefix. Danach wird der Service-Port auf targetPort abgebildet. Ein Fehler bei /api bleibt so nicht hinter einem allgemeinen Diagramm verborgen.
Fehlende Referenz von fehlenden Daten trennen
Ein nicht vorhandener Service-Port ist ein belegbarer Bruch. Fehlen dagegen Pod-Manifeste, bleibt der Arbeitslast-Status unbekannt; daraus folgt kein Ausfall.
Drei Prüfungen vor der Änderung
02
Die Anfrage konkret festlegen
Der Pfad beginnt mit /. Tragen Sie etwa /api/orders und den HTTP-Host ein. Ohne Host können nur Regeln ohne Host geprüft werden.
03
Den Befund richtig einordnen
„Passend“ betrifft nur die statische Regel. „Defekt“ zeigt eine fehlende Referenz, „Ungewiss“ eine Controller-Abhängigkeit. Nach jeder Änderung muss die Prüfung erneut laufen.
Vom Host bis zum Service-Port
Segmentbewusste Pfade
Ingress Pfad prüfen unterstützt Exact, Prefix nach Pfadsegmenten, exakte Hosts und Wildcards für genau eine Subdomain. /api trifft nicht auf /apix zu. Kubernetes Ingress Routing wird hier nur nach den Standardregeln beurteilt.
Port und targetPort auseinanderhalten
Das Ingress-Backend sucht den Service-Port anhand von Nummer oder Name. Erst der Service führt zu targetPort; fehlt dieses Feld, gilt der Portwert.
Optionale Auswahl der Arbeitslast
Sind Pod oder Deployment vorhanden, werden Service-Selektor und Labels verglichen. Ohne diese Manifeste wird keine gesunde EndpointSlice behauptet.
Grenzen der statischen Aussage
- Controller-spezifische Pfade bleiben offen
- ImplementationSpecific, Regex- und Rewrite-Annotationen hängen vom Controller ab. Ingress Pfad prüfen kennzeichnet sie als ungewiss, statt Prefix-Verhalten zu erfinden.
- Kein Netzwerktest
- Für einen Ingress 404 Fehler brauchen Sie gegebenenfalls Controller-Logs, DNS, EndpointSlices und eine echte Anfrage. Der lokale Befund beweist keine Erreichbarkeit.
- Fehlende Pods sind kein sicherer Bruch
- Pods können im eingefügten Ausschnitt fehlen; Services können manuelle Endpoints verwenden. Nur ein fehlender referenzierter Service oder Port gilt hier als defekte Referenz.
- Begrenzter Eingabebereich
- Maximal 300.000 Zeichen, 100 Ressourcen und 500 Pfade. Verarbeitet werden gerenderte Ingress- und Service-Manifeste; Gateway API und Helm-Vorlagen sind ausgeschlossen.
Häufige Fragen: Ingress Pfad prüfen
Warum liefert mein Ingress für einen Pfad 404?
Ein 404 kann durch Host- oder Pfadabweichung, Default-Backend, Rewrite oder die Anwendung selbst entstehen. Der Bericht zeigt die statische Kette; prüfen Sie anschließend Controller und Anwendung.
Muss der Ingress Backend-Port dem Service-Port oder dem targetPort entsprechen?
Das Backend verwendet die Nummer oder den Namen des Service-Ports. Der Service leitet erst danach an targetPort weiter. Der Pod-Port ist nicht automatisch der Ingress-Backend-Port.
Trifft Prefix /foo auch auf /foobar zu?
Nein. Prefix /foo passt zu /foo und /foo/bar, aber nicht zu /foobar. Groß- und Kleinschreibung werden berücksichtigt.
Welche Regel gewinnt bei Exact und Prefix?
Der längste passende Pfad gewinnt. Bei gleicher Länge hat Exact Vorrang vor Prefix; gleichrangige Regeln in mehreren Ingress-Objekten werden als Konflikt gekennzeichnet.
Kann eine YAML-Prüfung die Erreichbarkeit des Pods beweisen?
Nein. Aus YAML folgen weder Pod-Bereitschaft noch DNS, Load-Balancer, EndpointSlice oder eine erfolgreiche HTTP-Antwort.
Noch eine Frage zur Route?
Jetzt Ingress Pfad prüfen
Probieren Sie den Beispiel-Host und ändern Sie den Pfad, um den gewählten Service-Port zu sehen.
Die Analyse bleibt im Browser.