Ausgehende Verbindungen scheitern

Deine Anwendung erreicht etwas außerhalb des Clusters nicht. Kein Manifest wird abgelehnt, und in den Logs steht nichts außer einem Timeout. Das macht die Diagnose schwerer, als sie sein müsste.

Prüf zuerst den Tarif, denn die Antwort ist völlig unterschiedlich.

Im Free Tier: nur das Web

Ein Free-Tier-Namespace darf ausgehende Verbindungen nur über HTTP (80) und HTTPS (443) aufbauen, dazu DNS. Alles andere wird verworfen, und zwar stillschweigend. Das Symptom ist also ein Hängen und danach ein Timeout.

Eine externe Datenbank, ein Cache oder ein Message Broker ist damit nicht erreichbar. In diesem Tarif führt daran kein Weg vorbei:

Ziel	Geht im Free Tier?
Eine HTTPS-API	Ja
Eine Container-Registry	Ja
PostgreSQL auf 5432, MySQL auf 3306, Redis auf 6379	Nein
SMTP auf irgendeinem Port	Nein
Alles andere auf einem Nicht-Web-Port	Nein

Die Lösung ist, die Abhängigkeit im eigenen Namespace laufen zu lassen, wo sich Pods frei erreichen, oder auf einen bezahlten Tarif zu wechseln. Siehe Free Tier.

In bezahlten Tarifen: fast alles geht

Ausgehend ist offen, mit zwei Ausnahmen.

Port 25 ist gesperrt, in jedem Tarif. Mail zu versenden, indem du dich direkt mit dem Mailserver des Empfängers verbindest, funktioniert nicht. Nimm den Submission-Port oder die HTTP-API eines Mail-Anbieters. Das ist die häufigste Überraschung auf dieser Seite.

Die Cloud-Metadaten-Adresse ist nicht erreichbar. Bibliotheken, die Cloud-Zugangsdaten automatisch finden wollen, hängen dagegen und fallen dann zurück. Wenn ein SDK beim Start ein paar Sekunden verzögert, ist meistens das der Grund. Konfigurier Zugangsdaten explizit, statt sie suchen zu lassen.

Etwas im Cluster ist nicht erreichbar

Pods im selben Namespace erreichen sich ohne Einschränkung. Nimm den Service-Namen:

kubectl run -it --rm check --image=busybox --restart=Never -- \
  wget -qO- http://myapp:80/healthz

Der Namespace eines anderen Kunden ist nicht erreichbar, so gewollt, und deiner von dort aus ebenfalls nicht.

Die Kubernetes-API ist aus einem Pod heraus erreichbar, falls deine Anwendung sie braucht.

Bestätigen, dass es das Netzwerk ist und nicht deine App

Starte einen Wegwerf-Pod und probier die Verbindung von Hand. Hängt das, liegt es nicht an deiner Anwendung:

kubectl run -it --rm netcheck --image=busybox --restart=Never -- \
  sh -c 'nc -zv -w 5 db.example.com 5432; wget -qO- -T 5 https://example.com >/dev/null && echo https-ok'

In einem Free-Tier-Namespace läuft das Erste in einen Timeout und das Zweite gelingt. Das ist die Signatur der Allowlist und nicht die eines kaputten Hosts.

Wie es weitergeht

• Free Tier für alle Einschränkungen des Free Tier
• Datenbanken, um eine im eigenen Namespace zu betreiben