Veröffentlicht am

Kubernetes Service nicht erreichbar: Netzwerk-Troubleshooting

Teilen:
Authors

Kubernetes Service nicht erreichbar - Netzwerk Troubleshooting Guide

Ihr Kubernetes Service antwortet nicht? Pods können sich nicht verbinden? Dieser Guide zeigt systematisches Debugging von Kubernetes-Netzwerkproblemen.

TL;DR - Schnelle Checkliste

# 1. Hat der Service Endpoints?
kubectl get endpoints <service-name>

# 2. Matchen die Labels?
kubectl get pods --selector=<service-selector>

# 3. Läuft der Pod und ist ready?
kubectl get pods -l <label>

# 4. DNS funktioniert?
kubectl run debug --rm -it --image=busybox -- nslookup <service>

80% der Probleme: Service hat keine Endpoints (falsche Selector-Labels).

Die 10 häufigsten Ursachen

1. Service Selector matcht keine Pods

Häufigstes Problem!

Symptom:

kubectl get endpoints my-service
# NAME         ENDPOINTS   AGE
# my-service   <none>      5m

Diagnose:

# Service Selector anzeigen
kubectl get service my-service -o jsonpath='{.spec.selector}'
# {"app":"myapp"}

# Pods mit diesem Label suchen
kubectl get pods -l app=myapp
# No resources found

Lösung:

# 1. Pod-Labels prüfen
kubectl get pods --show-labels

# 2. Service Selector anpassen oder Pod-Labels korrigieren
kubectl label pod my-pod app=myapp

# Service Selector muss mit Pod Labels übereinstimmen!
# service.yaml
spec:
  selector:
    app: myapp    # ← Muss matchen

# pod.yaml
metadata:
  labels:
    app: myapp    # ← Mit diesem Label

2. Pod ist nicht Ready

Symptom: Service hat Endpoints, aber Pod ist 0/1 Running.

kubectl get pods
# NAME      READY   STATUS    RESTARTS
# my-pod    0/1     Running   0

Diagnose:

# Warum ist Pod nicht Ready?
kubectl describe pod my-pod | grep -A 10 Conditions

Häufige Ursachen:

  • Readiness Probe schlägt fehl
  • Container noch beim Starten
  • Dependency nicht verfügbar

Lösung:

# Readiness Probe anpassen
spec:
  containers:
  - name: app
    readinessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 10  # Mehr Zeit zum Starten
      periodSeconds: 5
      failureThreshold: 3

3. Falscher Port im Service

Symptom: Connection refused oder Timeout.

Diagnose:

# Service Ports prüfen
kubectl get service my-service -o yaml | grep -A 10 ports

# Pod Container Ports prüfen
kubectl get pod my-pod -o yaml | grep -A 5 containerPort

Lösung:

# Service
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80          # Service Port (extern)
    targetPort: 8080  # Container Port (muss matchen!)
  selector:
    app: myapp

# Pod
spec:
  containers:
  - name: app
    ports:
    - containerPort: 8080  # ← Muss mit targetPort übereinstimmen

4. DNS-Problem

Symptom: could not resolve host

Diagnose:

# DNS vom Debug-Pod testen
kubectl run debug --rm -it --image=busybox:1.36 -- sh

# Im Pod:
nslookup my-service
nslookup my-service.default.svc.cluster.local
nslookup kubernetes.default

Wenn DNS nicht funktioniert:

# CoreDNS Status prüfen
kubectl get pods -n kube-system -l k8s-app=kube-dns

# CoreDNS Logs
kubectl logs -n kube-system -l k8s-app=kube-dns

Lösung:

# CoreDNS neu starten
kubectl rollout restart deployment coredns -n kube-system

5. NetworkPolicy blockiert Traffic

Symptom: Verbindung wird gedropt (Timeout, keine Antwort).

Diagnose:

# NetworkPolicies im Namespace
kubectl get networkpolicy -n <namespace>

# Details einer Policy
kubectl describe networkpolicy <name>

Lösung:

# NetworkPolicy die Traffic erlaubt
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Debug-Tipp: Temporär alle NetworkPolicies löschen zum Testen:

kubectl delete networkpolicy --all -n <namespace>

6. Service Type falsch

Symptom: Service intern erreichbar, extern nicht.

Service Types:

TypeErreichbarkeit
ClusterIPNur cluster-intern
NodePortÜber Node-IP:Port
LoadBalancerÜber externe IP

Lösung für externen Zugriff:

# NodePort
apiVersion: v1
kind: Service
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30080  # Erreichbar über <Node-IP>:30080

# LoadBalancer (Cloud)
apiVersion: v1
kind: Service
spec:
  type: LoadBalancer
  ports:
  - port: 80

7. kube-proxy Problem

Symptom: Services funktionieren nicht cluster-weit.

Diagnose:

# kube-proxy Status
kubectl get pods -n kube-system -l k8s-app=kube-proxy

# kube-proxy Logs
kubectl logs -n kube-system -l k8s-app=kube-proxy

# iptables Rules prüfen (auf Node)
iptables -t nat -L KUBE-SERVICES | head -20

Lösung:

# kube-proxy neu starten
kubectl rollout restart daemonset kube-proxy -n kube-system

8. Pod im falschen Namespace

Symptom: Service gefunden, aber falsche Pods.

Diagnose:

# In welchem Namespace ist der Service?
kubectl get service my-service -A

# In welchem Namespace die Pods?
kubectl get pods -l app=myapp -A

Lösung:

Service-Discovery über Namespaces:

# Vollständiger DNS-Name
my-service.other-namespace.svc.cluster.local

9. Container lauscht auf localhost

Symptom: curl vom gleichen Pod funktioniert, aber Service nicht.

Diagnose:

# Im Pod prüfen
kubectl exec my-pod -- netstat -tlnp
# Ergebnis: 127.0.0.1:8080 ← Problem!

Problem: Anwendung bindet nur auf localhost, nicht auf alle Interfaces.

Lösung:

# Anwendung muss auf 0.0.0.0 binden
# In der App-Config:
server.address=0.0.0.0

# Oder als Env-Variable:
env:
- name: HOST
  value: "0.0.0.0"

10. CNI Plugin Problem

Symptom: Pods auf verschiedenen Nodes können sich nicht erreichen.

Diagnose:

# CNI Plugin Status
kubectl get pods -n kube-system | grep -E 'calico|cilium|flannel|weave'

# Pod-IPs auf verschiedenen Nodes
kubectl get pods -o wide

Lösung:

# CNI Pods neu starten
kubectl rollout restart daemonset calico-node -n kube-system

# Oder Flannel
kubectl rollout restart daemonset kube-flannel-ds -n kube-system

Systematischer Debug-Workflow

┌─────────────────────────────────────┐
│ kubectl get endpoints <service>    │
└─────────────────┬───────────────────┘
                  │
        ┌─────────▼─────────┐
        │ Endpoints leer?   │
        └─────────┬─────────┘
                  │
       ┌──────────┴──────────┐
       │                     │
   ┌───▼───┐            ┌────▼────┐
   │  JA   │            │  NEIN   │
   └───┬───┘            └────┬────┘
       │                     │
       ▼                     ▼
  Labels prüfen        Pod Ready?
       │                     │
       │              ┌──────┴──────┐
       │              │             │
       │          ┌───▼───┐    ┌────▼────┐
       │          │  JA   │    │  NEIN   │
       │          └───┬───┘    └────┬────┘
       │              │             │
       │              ▼             ▼
       │         Port prüfen   Readiness
       │              │         Probe
       │              ▼
       │         DNS prüfen
       │              │
       │              ▼
       │         NetworkPolicy
       │
       ▼
  Selector korrigieren

Nützliche Debug-Befehle

# === Basis-Checks ===

# Service Details
kubectl describe service <name>

# Endpoints
kubectl get endpoints <name>

# Pod Readiness
kubectl get pods -l <selector> -o wide

# === Netzwerk Tests ===

# DNS Test
kubectl run debug --rm -it --image=busybox:1.36 -- nslookup <service>

# TCP Verbindung testen
kubectl run debug --rm -it --image=busybox:1.36 -- nc -zv <service> <port>

# HTTP Request
kubectl run debug --rm -it --image=curlimages/curl -- curl -v http://<service>:<port>/

# === Erweiterte Diagnose ===

# Von einem Pod aus testen
kubectl exec <source-pod> -- curl -v http://<service>:<port>/

# Service YAML exportieren
kubectl get service <name> -o yaml

# Alle Services im Namespace
kubectl get svc -o wide

Debug-Skript

#!/bin/bash
# service-debug.sh

SVC=$1
NS=${2:-default}

echo "=== Service Details ==="
kubectl get service $SVC -n $NS -o wide

echo -e "\n=== Service Selector ==="
SELECTOR=$(kubectl get service $SVC -n $NS -o jsonpath='{.spec.selector}')
echo $SELECTOR

echo -e "\n=== Endpoints ==="
kubectl get endpoints $SVC -n $NS

echo -e "\n=== Matching Pods ==="
kubectl get pods -n $NS -l $(echo $SELECTOR | jq -r 'to_entries|map("\(.key)=\(.value)")|join(",")') -o wide

echo -e "\n=== Pod Readiness ==="
kubectl get pods -n $NS -l $(echo $SELECTOR | jq -r 'to_entries|map("\(.key)=\(.value)")|join(",")') -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.conditions[?(@.type=="Ready")].status}{"\n"}{end}'

echo -e "\n=== NetworkPolicies ==="
kubectl get networkpolicy -n $NS

echo -e "\n=== DNS Test (run manually) ==="
echo "kubectl run debug --rm -it --image=busybox:1.36 -- nslookup $SVC.$NS.svc.cluster.local"

CKA-Prüfungstipp

Service-Debugging ist 30% der CKA-Prüfung (Troubleshooting-Bereich).

Wichtigste Befehle:

# 1. Endpoints prüfen - IMMER ZUERST!
kubectl get endpoints <service>

# 2. Labels vergleichen
kubectl get svc <name> -o yaml | grep selector
kubectl get pods --show-labels

# 3. Port prüfen
kubectl describe service <name> | grep -i port

Häufige Prüfungsszenarien:

  • Service Selector korrigieren
  • Port mismatch fixen
  • NetworkPolicy anpassen

Mehr: CKA Zertifizierung Guide

Zusammenfassung

ProblemDiagnoseLösung
Keine Endpointsget endpoints leerSelector-Labels fixen
Pod nicht Readyget pods zeigt 0/1Readiness Probe
Port Mismatchdescribe servicetargetPort korrigieren
DNS kaputtnslookup schlägt fehlCoreDNS prüfen
NetworkPolicyTimeoutPolicy anpassen
Falscher TypeExtern nicht erreichbarNodePort/LoadBalancer
localhost bindingNur lokal erreichbarAuf 0.0.0.0 binden

Wichtigster Tipp: Zuerst kubectl get endpoints <service> - keine Endpoints = Selector-Problem!

Dieser Troubleshooting-Guide wird regelmäßig aktualisiert. Letzte Aktualisierung: Januar 2026.

Diskutieren auf Twitter

Kubernetes-Beratung gesucht?

Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.

Termin buchenKontakt aufnehmen

📖 Verwandte Artikel

Weitere interessante Beiträge zu ähnlichen Themen

Alle Artikel durchsuchen