Netzwerkpfad: OVN, Router und Service Mesh

1 Drei Datenpfade auseinanderhalten

OVN, Router und Service Mesh lösen unterschiedliche Aufgaben. Sie liegen bei einem Request hintereinander, sind aber keine austauschbaren Produkte.

2 Netzwerktyp und Komponenten prüfen

Diese Befehle lesen nur. Für System-Namespaces und spätere OVN-Vertiefung brauchst du cluster-admin.

oc whoami
oc get network.operator.openshift.io cluster -o jsonpath='{.spec.defaultNetwork.type}{"\n"}'
oc get network.config.openshift.io cluster -o yaml
oc get co network ingress
oc get pods -n openshift-ovn-kubernetes -o wide
oc get pods -n openshift-ingress -o wide

3 Zwei isolierte Test-Workloads anlegen

Die beiden Deployments dienen nur als Quell- und Ziel-Pod. Das Ziel erhält zusätzlich einen Service und eine Route.

oc new-project network-path-lab
oc create deployment source --image=quay.io/openshifttest/nginx
oc create deployment destination --image=quay.io/openshifttest/nginx
oc expose deployment destination --port=80
oc expose service destination
oc wait --for=condition=Available deployment/source deployment/destination --timeout=120s
oc get pod,service,route -o wide

Die Deployments und ihre Pods werden von dir angefordert. ReplicaSets und Pods werden von Kubernetes generiert. Die ClusterIP des Service und der Hostname der Route werden vom Cluster vergeben.

4 Service bis zur Pod-IP verfolgen

Eine ClusterIP ist kein Prozess und keine Netzwerkkarte. Sie ist eine virtuelle Adresse, für die OVN Regeln mit den EndpointSlice-Adressen programmiert.

oc get service destination -o yaml
oc get endpointslice -l kubernetes.io/service-name=destination -o yaml
oc get pods -l app=destination -o wide
oc describe service destination

oc run probe --rm -i --restart=Never --image=registry.access.redhat.com/ubi9/ubi-minimal:latest --command -- curl -sS http://destination:80/

Wenn der Curl-Aufruf funktioniert, wurden DNS-Auflösung, Service-Auswahl, OVN-Regeln und Zielprozess gemeinsam bestätigt. Eine leere EndpointSlice bedeutet meist, dass Selector oder Readiness nicht passen.

5 Geneve und OVN am Node sehen

Geneve kapselt Podverkehr nur dann, wenn Quell- und Ziel-Pod auf verschiedenen Nodes liegen. Auf einer SNO bleibt der Verkehr lokal und zeigt keinen echten Tunnel-Hop.

$node = oc get pod -l app=destination -o jsonpath='{.items[0].spec.nodeName}'
$ovnPod = oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node --field-selector spec.nodeName=$node -o jsonpath='{.items[0].metadata.name}'
"Node: $node"
"OVN-Pod: $ovnPod"
oc debug --as-root node/$node -- chroot /host ip -d link show genev_sys_6081
oc logs -n openshift-ovn-kubernetes pod/$ovnPod -c ovnkube-node --since=5m

node=$(oc get pod -l app=destination -o jsonpath='{.items[0].spec.nodeName}')
ovn_pod=$(oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node --field-selector "spec.nodeName=$node" -o jsonpath='{.items[0].metadata.name}')
printf 'Node: %s\nOVN-Pod: %s\n' "$node" "$ovn_pod"
oc debug --as-root "node/$node" -- chroot /host ip -d link show genev_sys_6081
oc logs -n openshift-ovn-kubernetes "pod/$ovn_pod" -c ovnkube-node --since=5m

6 Optional: den OVN-Pfad simulieren

ovnkube-trace simuliert einen TCP- oder UDP-Pfad durch logische OVN- und OpenFlow-Regeln. Diese Vertiefung läuft in Linux oder WSL mit funktionierendem oc-Zugang.

pod=$(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-control-plane -o name | head -1 | cut -d/ -f2)
oc cp -n openshift-ovn-kubernetes "$pod:/usr/bin/ovnkube-trace" -c ovnkube-cluster-manager ./ovnkube-trace
chmod +x ./ovnkube-trace

./ovnkube-trace \
  -src source -src-namespace network-path-lab \
  -dst destination -dst-namespace network-path-lab \
  -service destination -tcp -dst-port 80 -loglevel 2

ovnkube-trace wird aus dem laufenden Control-Plane-Pod kopiert. Es ist ein temporäres Diagnosewerkzeug und gehört nicht ins Repository. Entferne es danach mit rm -- ./ovnkube-trace.

7 Route bis zur generierten HAProxy-Konfiguration verfolgen

Der Ingress Operator verwaltet einen IngressController. Dieser erzeugt das Router-Deployment. Der Router beobachtet Routes und Endpoints und rendert daraus seine HAProxy-Konfiguration.

$hostName = oc get route destination -o jsonpath='{.spec.host}'
$hostName
curl.exe -i "http://$hostName"

oc get ingresscontroller default -n openshift-ingress-operator -o yaml
oc get deployment router-default -n openshift-ingress -o yaml
oc exec -n openshift-ingress deployment/router-default -- cat /var/lib/haproxy/conf/haproxy.config | Select-String -Pattern 'network-path-lab'

host_name=$(oc get route destination -o jsonpath='{.spec.host}')
printf '%s\n' "$host_name"
curl -i "http://$host_name"

oc get ingresscontroller default -n openshift-ingress-operator -o yaml
oc get deployment router-default -n openshift-ingress -o yaml
oc exec -n openshift-ingress deployment/router-default -- cat /var/lib/haproxy/conf/haproxy.config | grep -n 'network-path-lab'

/var/lib/haproxy/conf/haproxy.config wird vom Router generiert. Du liest sie zur Diagnose, bearbeitest sie aber nie. Eine direkte Änderung würde beim nächsten Reconcile überschrieben.

TLS am eigenen Lab einschalten

oc patch route destination --type=merge -p '{"spec":{"tls":{"termination":"edge","insecureEdgeTerminationPolicy":"Redirect"}}}'
oc get route destination -o yaml
$hostName = oc get route destination -o jsonpath='{.spec.host}'
curl.exe -Ik "https://$hostName"

oc patch route destination --type=merge -p '{"spec":{"tls":{"termination":"edge","insecureEdgeTerminationPolicy":"Redirect"}}}'
oc get route destination -o yaml
host_name=$(oc get route destination -o jsonpath='{.spec.host}')
curl -Ik "https://$host_name"

Bei edge endet TLS am Router. Zwischen Router und Pod läuft hier HTTP. reencrypt baut eine zweite TLS-Verbindung zum Backend auf. passthrough lässt die verschlüsselte Verbindung bis zum Pod durch und kann deshalb nur anhand des TLS-Servernamens auswählen.

8 Ingress-Sharding verstehen, ohne es anzulegen

Sharding bedeutet, dass mehrere IngressController jeweils nur ausgewählte Namespaces oder Routes übernehmen. So lassen sich intern, extern oder nach Mandant getrennte Router betreiben.

oc get ingresscontroller -n openshift-ingress-operator
oc explain ingresscontroller.spec.domain
oc explain ingresscontroller.spec.namespaceSelector
oc explain ingresscontroller.spec.routeSelector
oc get route destination --show-labels

9 Service-Mesh-Generation erkennen

OpenShift Service Mesh 3 nutzt den OpenShift Service Mesh Operator und Sail-APIs. Die frühere Generation nutzte Maistra-Ressourcen wie ServiceMeshControlPlane.

oc get csv -A | Select-String -Pattern 'servicemesh|sail|istio|maistra'
oc api-resources | Select-String -Pattern 'Istio|ServiceMeshControlPlane|ServiceMeshMemberRoll'
oc get istio.sailoperator.io -A
oc get istiorevision.sailoperator.io -A
oc get servicemeshcontrolplane.maistra.io -A
oc get pod -n network-path-lab -o jsonpath='{range .items[*]}{.metadata.name}{": "}{.spec.containers[*].name}{"\n"}{end}'

oc get csv -A | grep -Ei 'servicemesh|sail|istio|maistra'
oc api-resources | grep -E 'Istio|ServiceMeshControlPlane|ServiceMeshMemberRoll'
oc get istio.sailoperator.io -A
oc get istiorevision.sailoperator.io -A
oc get servicemeshcontrolplane.maistra.io -A
oc get pod -n network-path-lab -o jsonpath='{range .items[*]}{.metadata.name}{": "}{.spec.containers[*].name}{"\n"}{end}'

10 Entscheiden, ob ein Mesh nötig ist

Auf einer kleinen SNO kostet ein Sidecar pro Pod zusätzlichen RAM und CPU. Für die Bibliothek ist Service-CA plus NetworkPolicy meist die kleinere und verständlichere Lösung. Ein Mesh lohnt sich erst, wenn seine zentralen Regeln mehrere Anwendungen konsistent entlasten.

11 Fehler an der richtigen Schicht eingrenzen

Die Grundlagen für Service, Route und Readiness stehen in der Service-, Route- und Probes-Anleitung. Policy-Fehler werden in der NetworkPolicy-Anleitung praktisch isoliert.

12 Lab vollständig aufräumen

oc delete project network-path-lab

Falls du ovnkube-trace kopiert hast, entferne zusätzlich die lokale Binärdatei. Das Service Mesh und die OpenShift-Systemkomponenten wurden durch dieses Lab nicht verändert.