Dienst veröffentlichen: Edge oder interner Ingress
Zielgruppe: Anwender und Betreuer · Stand: 06.11.2026
Du willst einen Dienst erreichbar machen und fragst Dich, ob das über den Edge oder den internen Ingress läuft. Diese Seite erklärt den Unterschied und zeigt die Wege. Wie Du Tags und Router konkret schreibst, steht in den Büchern Traefik und Consul.
Erst klären: Wer greift zu?
- Ein Mensch im Browser (Oberfläche, Dashboard): Der Dienst bekommt einen Hostnamen am Edge. Siehe Edge-Grundsatz.
- Ein anderer Dienst (API, Job, Datenbank-Client): Der Dienst bleibt intern. Er wird über interne Namen wie
<dienst>.service.consuloder über Connect-Upstreams im Service Mesh erreicht, nie über einen Edge-Hostnamen.
Edge und interner Ingress
| Edge | Interner Ingress | |
|---|---|---|
| Was | Traefik-Paar auf eigenen VMs mit VIPs | Traefik als Nomad-Job im Cluster |
| Aufgabe | Eingangstor: Hostnamen, Zertifikate, Allowlists, öffentliche Entrypoints | verteilt Anfragen im Cluster weiter an Dienste im Mesh |
| Erreichbar | über die VIPs der Umgebung (intern bzw. öffentlich) | nur vom Edge, über Consul Connect (mTLS), ohne feste Ports 80/443 |
| Routen kommen aus | Tags im Consul-Katalog und Dateien der Rolle traefik |
der Konfiguration im Nomad-Job des Ingress |
| Zertifikate | Let's Encrypt am Edge | keine eigenen, die TLS-Verbindung endet am Edge |
Wichtig: Der interne Ingress ist kein zweiter Eingang. Jede Anfrage von Menschen kommt zuerst am Edge an.
Die Wege für einen Dienst
A: Dienst auf einer VM. Der Dienst registriert sich im Consul-Katalog mit Traefik-Tags, der Edge routet direkt dorthin.
Browser → Edge → Dienst
B: Nomad-Dienst direkt vom Edge. Der Dienst hängt im Mesh und trägt traefik.consulcatalog.connect=true. Der Edge spricht ihn per Connect an. Ein Beispiel ist Grafana im Lab.
Browser → Edge → Connect → Dienst
C: Nomad-Dienst über den internen Ingress. Der Ingress trägt die Tags für den Edge und leitet per Connect-Upstream an den Dienst weiter. Ein Beispiel ist der Demo-Dienst im Namespace cpi im Lab.
Browser → Edge → Connect → interner Ingress → Connect → Dienst
Welchen Weg Dein Nomad-Dienst nimmt (B oder C), stimmst Du mit den Betreuern ab.
Vorgehen
- Klären, ob ein Mensch oder ein Dienst zugreift (siehe oben). Für Dienste ist hier Schluss: Sie bleiben intern.
- Hostnamen unter der Wildcard der Umgebung wählen. Lab-PoC:
*.lab.bre1.dexpro.services. - Dienst im Consul-Katalog registrieren: Dienst im Consul-Katalog registrieren.
- Router-Tags setzen, bei Weg C am Ingress statt am Dienst: Router per Consul-Tags definieren.
- Bei Weg B und C die Intentions bei den Betreuern anfragen: Edge → Dienst bzw. Edge → Ingress und Ingress → Dienst.
- Prüfen, dass die Oberfläche eine eigene Anmeldung hat.
Stolperfallen
Öffentlich (Entrypoint public) ist ein Dienst nur nach Absprache mit den Betreuern. Ein interner Dienst, der über den Edge erreichbar ist, ist angreifbar.
- Edge-Hostname für Maschinen: Dienste, die einen anderen Dienst über dessen Edge-Hostnamen ansprechen, hängen unnötig am Edge und an dessen Allowlists. Nimm interne Namen.
- Fehlende Intention: Im Mesh gilt Default-Deny. Ohne Intention kommt keine Anfrage durch, auch nicht vom Edge.
Weiterführend
- Edge-Grundsatz
- Router per Consul-Tags definieren
- So liest der Edge den Consul-Katalog
- Beispiele in GitLab:
container-platform-core-services/nomad-jobs/pilot-grafana(Weg B),container-platform-core-services/nomad-jobs/traefik-ingress(Weg C)