Service, Route und Probes in OpenShift

1 Das Service-Modell

Ein Service ist ein fester Name plus feste ClusterIP vor einer wechselnden Menge Pods – das Objekt bleibt, die Pods dahinter nicht.

Der selector (ein Label-Ausdruck) entscheidet, welche Pods dazugehören – der Endpoints-Controller pflegt daraus die EndpointSlice: die Liste der bereiten Pod-IPs, nur Pods mit passendem Label und grüner Readiness-Probe (Schritt 6). Hinter der ClusterIP läuft kein Prozess – OVN-Kubernetes programmiert den Node-Datapath und macht DNAT auf eine ready Pod-IP, round-robin.

2 Service anlegen, per DNS erreichen

Ein Deployment mit zwei Replicas, ein Service davor, und der DNS-Name aus einem dritten Pod heraus getestet.

oc create deployment demo-web -n library --image=registry.access.redhat.com/ubi9/httpd-24 --replicas=2
oc expose deployment demo-web -n library --port=8080 --target-port=8080
oc get svc demo-web -n library

# von einem Test-Pod im selben Namespace aufloesen:
oc run dns-test -n library --rm -it --restart=Never \
  --image=registry.access.redhat.com/ubi9/ubi-minimal -- \
  curl -s -o /dev/null -w "%{http_code}\n" http://demo-web:8080/

# der vollqualifizierte Name geht auch namespaceuebergreifend:
oc run dns-test -n library --rm -it --restart=Never \
  --image=registry.access.redhat.com/ubi9/ubi-minimal -- \
  getent hosts demo-web.library.svc.cluster.local

Kurz demo-web löst nur im selben Namespace auf, demo-web.library namespaceübergreifend, und demo-web.library.svc.cluster.local ist der volle Name, den CoreDNS auflöst. port ist der Service-Port, targetPort der Container-Port – hier gleich, müssen es aber nicht sein.

3 Endpoints live brechen

Der häufigste Service-Fehler: der selector trifft keine Pods mehr.

# Ist-Zustand: Endpoints gefuellt
oc get endpointslices -n library -l kubernetes.io/service-name=demo-web
oc describe svc demo-web -n library | grep Endpoints

# den Selector kaputt machen (Tippfehler nachstellen):
oc patch svc demo-web -n library --type=merge -p '{"spec":{"selector":{"app":"demo-web-typo"}}}'
oc describe svc demo-web -n library | grep Endpoints
# -> Endpoints: 

# von aussen (Route/curl) kommt jetzt 503 statt einer Antwort - der Router
# hat niemanden, an den er weiterreichen kann

# zurueck:
oc patch svc demo-web -n library --type=merge -p '{"spec":{"selector":{"app":"demo-web"}}}'
oc describe svc demo-web -n library | grep Endpoints

4 Eine Route anlegen

Eine Route ist ein OpenShift-Objekt: Hostname → Service, mit Port, TLS-Modus und optional einem Pfad. Kubernetes-Pendant ist Ingress (F3).

# reine HTTP-Route:
oc expose svc/demo-web -n library
oc get route demo-web -n library

# oder gleich verschluesselt:
oc create route edge demo-web-tls --service=demo-web -n library
oc get route demo-web-tls -n library -o jsonpath='{.spec.host}{"\n"}'

curl -s -o /dev/null -w "%{http_code}\n" http://$(oc get route demo-web -n library -o jsonpath='{.spec.host}')/
curl -sk -o /dev/null -w "%{http_code}\n" https://$(oc get route demo-web-tls -n library -o jsonpath='{.spec.host}')/

oc get route demo-web -n library zeigt Admitted: True, sobald der Router sie angenommen hat – HostAlreadyClaimed, wenn zwei Routes denselben Host wollen.

5 Der Router und das Wildcard-Zertifikat

Der Router (HAProxy als Pod) hält Port 80 und 443 auf den Nodes, liest alle Routes clusterweit und schreibt daraus die HAProxy-Konfig neu.

Das Wildcard-DNS *.apps.<cluster> ist ein einziger A-Record, der auf den Router zeigt – du legst ihn einmal an, jede neue Route braucht danach keinen eigenen DNS-Eintrag. Der Router bringt ein Default-Wildcard-Zertifikat für *.apps.<cluster> mit (auf OKD/SNO selbstsigniert) – darum braucht eine edge-Route kein eigenes Zertifikat, ausser du willst ein anderes: inline in route.spec.tls.certificate/.key, oder ein Secret über cert-manager.

OpenShift übersetzt ein Ingress-Objekt automatisch in eine Route – wer portabel bleiben will, schreibt Ingress und überlässt OpenShift die Übersetzung.

6 Das Probe-Modell

Drei Probes, drei getrennte Aufgaben – die häufigste Verwechslung kostet einen unnötigen Restart.

readiness prüft Abhängigkeiten (DB erreichbar, Cache warm), liveness bleibt flach („antwortet der Prozess überhaupt“) – sonst startet ein kurzer DB-Blip gleich alle Replicas neu. Arten: httpGet (200–399 = ok), tcpSocket, exec (exit 0), grpc. Parameter: initialDelaySeconds, periodSeconds (10), timeoutSeconds (1 – oft zu kurz), failureThreshold (3), successThreshold.

7 Eine readiness-Probe live brechen

Ein Pod mit einer readiness-Probe auf einen Pfad, der 500 antwortet – und beobachten, wie er aus den Endpoints fliegt, ohne zu sterben.

cat <<'YAML' | oc apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-probe
  namespace: library
spec:
  replicas: 1
  selector: { matchLabels: { app: demo-probe } }
  template:
    metadata: { labels: { app: demo-probe } }
    spec:
      containers:
        - name: web
          image: registry.access.redhat.com/ubi9/httpd-24
          ports: [{ containerPort: 8080 }]
          readinessProbe:
            httpGet: { path: /nonexistent-path, port: 8080 }
            periodSeconds: 5
            failureThreshold: 2
          livenessProbe:
            httpGet: { path: /, port: 8080 }
            periodSeconds: 10
YAML

oc get pod -n library -l app=demo-probe -w
# -> READY 0/1, RESTARTS bleibt 0 (liveness ist gruen, nur readiness ist rot)

oc describe pod -n library -l app=demo-probe | grep -A2 Readiness
oc get events -n library --field-selector involvedObject.name=$(oc get pod -n library -l app=demo-probe -o jsonpath='{.items[0].metadata.name}') | grep -i unhealthy

oc delete deployment demo-probe -n library

8 Typische Fallen

9 Wie die Bibliothek es macht

OCP-Unterschied bei allen dreien: keiner – Service, Route-Übersetzung des DNS-Operators und Probes sind entweder Kern-Kubernetes oder Kern-OpenShift, identisch auf OKD und OCP.

+ Die Kurzfassung