Das passende Training Kubernetes Networking Training – 3 Tage Praxis & Debugging
Ingress oder LoadBalancer? Es ist einfacher als du denkst
Kurz und unmissverständlich: Für HTTP(S)-Traffic willst du Ingress. Für alles andere - TCP-Streaming, gRPC, sonstige Protokolle - type: LoadBalancer. Der zweite Fall ist die Ausnahme, keine Gewohnheit.
Was Ingress dir wirklich bringt
Ingress guckt sich Hostname und Pfad der Anfrage an und schickt sie gezielt weiter - /shop zu Service A, /api zu Service B, alles über eine einzige Adresse. type: LoadBalancer kann das schlicht nicht, der leitet blind auf L4 durch.
Der eigentliche Hammer ist aber die TLS-Terminierung. Mit type: LoadBalancer machst du das für jeden Dienst einzeln - eigenes Zertifikat, eigene Rotation, eigene Baustelle. Mit Ingress wandert das an eine Stelle. Kombiniert mit Cert-Manager und Let’s Encrypt ist das ein Träumchen: Zertifikate werden automatisch angefordert, erneuert und gleich automatisch verwendet, ohne dass du je manuell ran musst. Und wenn du auf Ingress verzichtest, ist Schluss mit der Leichtigkeit. Dann musst du dich selbst kümmern: TLS in die App einbauen, oder dir das umständlich in eine eigene Nginx-Config reinfummeln. Das Zertifikat selbst bekommst du zwar auch ohne Ingress automatisch - ein eigenes cert-manager-Certificate-Objekt schreibt dir ein Secret. Aber dabei bleibt’s nicht: Du brauchst zusätzlich eine ConfigMap für die Nginx-Konfiguration, die Volume-Mounts für Secret und ConfigMap, einen kompletten zweiten Container nur fürs TLS-Handling - und das pro Pod. Wie das Zertifikat am Ende wirklich im Container ankommt und benutzt wird? Dein Job.
Wann type: LoadBalancer doch der richtige Weg ist
Bei TCP-Streaming oder anderen Nicht-HTTP-Protokollen ist type: LoadBalancer the way to go. Bei gRPC geht’s technisch zwar auch über Ingress (z.B. ingress-nginx), aber unnötig kompliziert - das native Ingress-Objekt kennt gRPC gar nicht, du bist auf controller-spezifische Annotationen angewiesen. Ansonsten: Finger weg von type: LoadBalancer.
| Ingress | type: LoadBalancer | |
|---|---|---|
| Routing nach Host/Pfad | Ja | Nein |
| TLS-Terminierung | Zentral, ein Ort (+ Cert-Manager/Let’s Encrypt) | Pro Service einzeln |
| TCP-Streaming | Nein | Ja |
| gRPC | Nur über controller-spezifische Annotationen | Ja, nativ |
Ein Reality-Check aus einem Training
In einem Firmentraining hat mir ein Teilnehmer bei genau diesem Thema die Augen geöffnet: Mittelständler, gut 120 Leute, eigenes Rechenzentrum, keine Cloud. Sein Kommentar zu type: LoadBalancer: “Weißt du eigentlich, dass ich bei uns jede einzelne öffentliche IP bei unserem Provider einzeln beantragen muss?” Provider: du kennst ihn, das Unternehmen mit dem einen großen Buchstaben in leuchtender Farbe. On-Prem ist type: LoadBalancer pro Service also nicht nur eine Kostenfrage, sondern ein Verwaltungsvorgang - noch ein Grund mehr, bei Ingress zu bleiben, wo’s nur einen davon braucht.
Meine klare Ansage
Ingress ist der Standardweg für HTTP(S) - nicht primär wegen der Kosten, sondern weil TLS-Terminierung und Routing an einer Stelle zusammenlaufen. type: LoadBalancer bleibt die Ausnahme: TCP-Streaming, gRPC, alles, was kein HTTP ist.
Genau diesen Umschwung - weg vom Balancer-pro-Dienst, hin zum zentralen Ingress mit automatischem TLS - üben wir im Kubernetes Networking Training im Detail und mit echtem Debugging durch.