Kubernetes-Services
Die wichtigsten Befehle zum Merken
kubectl get service— den vorgesehenen Service-Endpunkt prüfen.kubectl get endpointslices— zugehörige Backendadressen untersuchen.kubectl exec … -- curl— den Service aus dem Cluster anfragen.
Befehle und Optionen
| Befehl oder Option | Bedeutung |
|---|---|
config current-context |
Gewählten Clusterkontext zeigen. |
-n lab |
Testnamespace wählen. |
get … -o yaml |
Genannte oder passende Ressourcen als YAML lesen. |
-l kubernetes.io/service-name=web |
EndpointSlices mit dem Servicelabel web wählen. |
exec dns-lab -- curl … |
curl im vorhandenen Diagnose-Pod ausführen. |
--silent --show-error --max-time 5 |
Fortschritt verbergen, Fehler behalten, auf fünf Sekunden begrenzen. |
-i http://web:8080/ |
HTTP-Header eines GET auf dem Serviceport mit ausgeben. |
8080 ist hier der vorausgesetzte Serviceport; targetPort kann abweichen. Die URL muss ein lesender Testendpunkt sein, keine Aktion auslösen.
Die entscheidenden Konzepte
1. Ein Service trennt Clientadresse und Podlebensdauer
Ein Kubernetes-Service bietet einen stabilen Zugang zu einer logischen Backendgruppe. Clients verwenden Namen und Port, während Pods ersetzt oder verschoben werden.
Ein normaler ClusterIP-Service besitzt eine virtuelle Adresse. Er ist selbst kein Anwendungspod. Clusternetzwerk und kube-proxy oder eine andere unterstützte Datenpfadimplementierung leiten Verkehr an geeignete Endpunkte weiter.
2. Selektoren und EndpointSlices verbinden Absicht und Adressen
Bei Services mit Selektor finden Controller passende Pods und pflegen EndpointSlices mit Adressen, Ports und Zuständen. Ein korrekt angelegter Service mit falschem Selektor kann deshalb ohne nutzbare Backends bleiben.
Readiness beeinflusst normalerweise die Eignung für Verkehr; ausdrücklich veröffentlichte nichtbereite Endpunkte sind eine Ausnahme. Serviceexistenz, passende Pods, bereite Endpunkte und funktionierende Anwendungen sind getrennte Prüfpunkte.
3. Serviceport und Zielport unterscheiden sich
port ist der vom Client adressierte Serviceport. targetPort bestimmt den Backendport direkt oder über einen Namen. Eine Portdeklaration im Container erzeugt keinen Listener.
Verkehr bleibt häufig für eine Verbindung einem Backend zugeordnet. Mehrere HTTP-Anfragen über dieselbe dauerhafte Verbindung wechseln deshalb nicht zwingend den Pod. Mehrere Endpunkte garantieren kein Round-Robin pro Anfrage.
4. Der Servicetyp regelt Veröffentlichung, nicht Anwendungskorrektheit
ClusterIP, NodePort und LoadBalancer beschreiben unterschiedliche Zugangsarten. LoadBalancer benötigt eine unterstützende Implementierung. Ein angelegtes Objekt garantiert keine sofort verfügbare externe Adresse.
Network Policy, Routing, Listener und Anwendung können weiterhin scheitern. DNS kann einen Service ohne antwortendes Backend auflösen. Prüfe daher Konfiguration, Endpunkte und schließlich eine echte Anfrage.
Ein kleines Beispiel
Optional: Prüfe zuerst den Kontext und nutze dann die genannten vorhandenen Testressourcen. Das Beispiel erzeugt und ändert keine Clusterobjekte.
kubectl config current-context
kubectl -n lab get service web -o yaml
kubectl -n lab get endpointslices -l kubernetes.io/service-name=web -o yaml
kubectl -n lab exec dns-lab -- curl --silent --show-error --max-time 5 -i http://web:8080/Vergleiche Selektor, ClusterIP, port und targetPort mit Adressen, Ports und Bereitschaft in EndpointSlices. Prüfe anschließend Status und Inhalt der HTTP-Antwort aus dem Diagnose-Pod.
Eine Antwort belegt einen Anfragepfad zu diesem Zeitpunkt, nicht Gesundheit aller Backends oder Failover. 5xx ist ein Anwendungsbefund trotz möglicherweise funktionierendem DNS und Transport. Fehlende EndpointSlices können Selektor- oder Konfigurationsprobleme bedeuten, nicht eindeutig DNS. Aufräumen entfällt.
Merke dir: Ein Service führt stabil zu wechselnden Endpunkten. Auswahl, Ports und tatsächliche Backendantwort sind separat zu prüfen.