Deine App ist nicht erreichbar

Deine Pods laufen, und der Hostname liefert trotzdem nicht deine Anwendung. Geh diese Liste von oben durch, sie ist so sortiert, dass jeder Schritt alles darüber ausschließt.

Hängt die Route überhaupt?

kubectl get httproute
kubectl describe httproute <name>

Der Abschnitt Parents am Ende von describe ist die Antwort. Accepted: True und ResolvedRefs: True heißen, das Gateway hat deine Route angenommen. Alles andere benennt das Problem.

Zwei Fehler zeigen sich hier statt beim Apply:

• ResolvedRefs: False mit einem Backend-Fehler heißt, der Service in backendRefs existiert nicht oder sein Port passt nicht. Die Route hängt und antwortet, nur ohne etwas dahinter.
• Kein passender Listener heißt, sectionName nennt einen Listener, der nie angelegt wurde.

sectionName passt nicht zum Hostnamen

Der mit Abstand häufigste Routing-Fehler. Der Listener-Name ist der Hostname mit Bindestrichen statt Punkten, davor https-:

Hostname	sectionName
myapp.tenant-7.itsh.dev	https-myapp-tenant-7-itsh-dev
shop.example.com	https-shop-example-com

Passt das nicht, hängt die Route am falschen Listener oder an gar keinem.

Die Seite kommt über einfaches HTTP

Du hast sectionName weggelassen. Ohne die Angabe bindet die Route zusätzlich den Port-80-Listener, deine Anwendung wird also unverschlüsselt ausgeliefert.

Setz sectionName auf den HTTPS-Listener. Wenn einfaches HTTP weiterleiten statt ausliefern soll, leg die separate Redirect-Route aus Gateway API an.

Der Browser warnt wegen des Zertifikats

Zertifikate entstehen automatisch, aber nur, wenn die HTTPRoute die Annotation trägt:

metadata:
  annotations:
    cert-manager.io/cluster-issuer: "auto"

Es zählt allein, dass die Annotation vorhanden ist, der Wert wählt nichts aus. Ohne sie gibt es keinen HTTPS-Listener und kein Zertifikat.

Die Ausstellung passiert nicht sofort. Ein neuer Hostname braucht einen Moment, und in diesem Fenster sieht der Browser eine Namensabweichung statt deines Zertifikats. Bleibt es dabei, liegt es meist an DNS: Das Zertifikat kann nicht ausgestellt werden, solange der Hostname nicht auf das Gateway auflöst.

Der Hostname löst nicht auf

Für einen Namen unter der Subdomain deines Namespace gibt es nichts einzurichten, er zeigt bereits auf das Gateway. Löst so einer nicht auf, liegt das Problem woanders auf dieser Seite, nicht bei DNS.

Für deine eigene Domain zeig sie hierauf:

Typ	Wert
A	91.98.6.3
AAAA	2a01:4f8:1c1f:7bfa::1

Prüf, was die Welt sieht, nicht was dein Rechner gecacht hat:

dig +short myapp.example.com

Denk daran, dass die Domain im Portal verifiziert sein muss, bevor eine Route sie verwenden darf, und dass das Free Tier gar keine eigenen Domains kann.

Deine Anwendung sieht die falsche Client-IP

Das Gateway setzt X-Forwarded-For und X-Real-IP. Deine Anwendung sollte diesen Headern nur trauen, wenn die Verbindung vom Gateway kommt, nie von beliebigen Absendern. Vertraut sie jedem, kann jeder Client jede beliebige Adresse behaupten und damit dein Logging, dein Rate-Limiting und IP-basierte Regeln aushebeln.

Wie es weitergeht

• Gateway API für die Routing-Konventionen im Ganzen
• Die API sagt nein, wenn die Route schon beim Apply abgelehnt wurde