Netzwerk

Dein Namespace ist in keine der beiden Richtungen offen. Im Manifest steht nirgends, wo die Grenzen liegen, deshalb lohnt es sich, sie zu kennen, bevor du darum herum planst.

Eingehend

Von	Erreicht deine Pods?
Das gemeinsame Gateway	Ja. Genau das lässt eine HTTPRoute funktionieren
Andere Pods in deinem Namespace	Ja, frei, auf jedem Port
Der Namespace eines anderen Kunden	Nein
Das öffentliche Internet, direkt	Nein. Nur über das Gateway

Einen rohen TCP-Port ins Internet zu stellen, ist nicht möglich. Services vom Typ NodePort und LoadBalancer werden abgelehnt, der Weg nach draußen ist eine HTTPRoute am gemeinsamen Gateway, siehe Gateway API.

Weil sich Pods innerhalb deines Namespace ohne Einschränkung erreichen, gehören Datenbank, Cache oder interne API in denselben Namespace wie die Anwendung, die sie nutzt, adressiert über den Service-Namen:

text

postgresql://app-db-rw:5432/mydb
redis://cache:6379
http://myapp:80

Ausgehend in bezahlten Tarifen

Praktisch offen, mit zwei Ausnahmen.

Port 25 ist gesperrt, in jedem Tarif, auch in den bezahlten. Sich direkt mit dem Mailserver des Empfängers zu verbinden, funktioniert nicht. Versende über 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. SDKs, die Cloud-Zugangsdaten automatisch finden wollen, hängen erst dagegen, bevor sie auf das zurückfallen, was du konfiguriert hast. Das äußert sich als ein paar Sekunden Verzögerung beim Start. Konfigurier Zugangsdaten explizit, statt die Bibliothek suchen zu lassen.

Alles andere geht: HTTP und HTTPS, externe Datenbanken auf ihren eigenen Ports, Message Broker, SSH zu deinen eigenen Hosts, DNS.

Ausgehend im Free Tier

Deutlich enger. Ein Free-Tier-Namespace erreicht nur:

HTTP (80) und HTTPS (443), überallhin
DNS
die Kubernetes-API
andere Pods im eigenen Namespace

Alles andere wird ohne Fehler verworfen, das Symptom ist also ein Hängen und danach ein Timeout. Insbesondere sind eine externe Datenbank, ein Cache oder ein Message Broker auf eigenem Port nicht erreichbar, und daran führt kein Weg vorbei. Lass die Abhängigkeit im eigenen Namespace laufen oder wechsle in einen bezahlten Tarif. Siehe Free Tier.

Die Kubernetes-API aus einem Pod erreichen

Das funktioniert, aber nur, wenn der Pod unter dem ServiceAccount deines Namespace läuft.

Der default-ServiceAccount hat keinerlei Rechte

Ein Pod ohne serviceAccountName läuft als default, und der bekommt gar nichts: Jeder API-Aufruf endet in Forbidden. Selbst reparieren kannst du das nicht, denn Roles und RoleBindings anzulegen ist nicht erlaubt.

Trag stattdessen den ServiceAccount deines Namespace am Pod ein. Er heißt wie der Namespace:

yaml

spec:
  serviceAccountName: <dein-namespace>

Damit ist die In-Cluster-Konfiguration vorhanden, die Client-Bibliotheken erwarten, und der Pod hat genau den Zugriff aus Berechtigungen und Richtlinien, und keinen weiteren.

Wie es weitergeht

Gateway API, um Traffic hereinzubekommen
Ausgehende Verbindungen scheitern, wenn etwas nicht verbindet

Netzwerk ​

Eingehend ​

Ausgehend in bezahlten Tarifen ​

Ausgehend im Free Tier ​

Die Kubernetes-API aus einem Pod erreichen ​