33 Routing und Ingress-Controller

Routing und Ingress-Controller implementieren Layer-7 Traffic-Management für HTTP/HTTPS-basierte Anwendungen durch intelligentes Request-Routing, SSL-Terminierung und content-basierte Load-Balancing-Strategien. Diese Application-Layer-Netzwerkkomponenten abstrahieren komplexe Reverse-Proxy-Konfigurationen und ermöglichen fortgeschrittene Traffic-Management-Policies für moderne Mikroservice-Architekturen.

33.1 OpenShift Routes vs. Kubernetes Ingress

OpenShift Routes erweitern die Standard-Kubernetes-Ingress-Funktionalität durch native Integration mit HAProxy-basiertem Router für erweiterte Layer-7 Load-Balancing- und SSL-Management-Features. Diese OpenShift-spezifische Abstraktion vereinfacht die externe Service-Exposition ohne zusätzliche Ingress-Controller-Installation.

33.1.1 OpenShift Routes

Routes sind OpenShifts primärer Mechanismus für die Exposition von HTTP/HTTPS-Services nach außen. Sie bieten eine vereinfachte Abstraktion über Kubernetes-Ingress-Ressourcen:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: webapp-route
spec:
  host: webapp.apps.cluster.example.com
  to:
    kind: Service
    name: webapp-service
    weight: 100
  port:
    targetPort: http
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

Vorteile von OpenShift Routes: - Automatische DNS-Integration mit Wildcard-Domains - Integrierte SSL-Zertifikatsverwaltung - Blue-Green und A/B-Testing-Unterstützung - Native HAProxy-Integration

33.1.2 Kubernetes Ingress

Standard-Kubernetes-Ingress bietet plattform-agnostische HTTP-Routing-Konfiguration:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
    - webapp.example.com
    secretName: webapp-tls
  rules:
  - host: webapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: webapp-service
            port:
              number: 80

[Diagramm: Route-Ingress-Architektur mit Traffic-Flow]

33.2 HAProxy Router-Architektur

OpenShifts Standard-Router basiert auf HAProxy und implementiert hochperformantes HTTP/HTTPS Load-Balancing mit erweiterten Health-Checking- und SSL-Terminierungs-Capabilities. Diese Enterprise-Grade Proxy-Technologie gewährleistet produktionstaugliche Performance und Zuverlässigkeit.

33.2.1 Dynamic Configuration Management

Die Route-Configuration-Synchronisation überwacht die Kubernetes-API für Route-Ressourcen-Änderungen und generiert dynamische HAProxy-Konfigurationen ohne Service-Unterbrechung:

HAProxy-Konfiguration (automatisch generiert):

frontend public
    bind *:80
    bind *:443 ssl crt /etc/ssl/certs/
    redirect scheme https if !{ ssl_fc }
    
    # Route-spezifische ACLs
    acl webapp_route hdr(host) -i webapp.apps.cluster.example.com
    use_backend webapp_backend if webapp_route

backend webapp_backend
    balance roundrobin
    option httpchk GET /health
    server pod1 10.128.0.10:8080 check
    server pod2 10.128.0.11:8080 check

33.2.2 SSL-Zertifikats-Management

SSL-Certificate-Management integriert mit Let’s Encrypt oder Custom Certificate Authorities für automatische Zertifikatsbereitstellung und -erneuerung:

Automatische Let’s Encrypt Integration:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: webapp-auto-ssl
  annotations:
    kubernetes.io/tls-acme: "true"
spec:
  host: webapp.example.com
  to:
    kind: Service
    name: webapp-service
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

33.2.3 Performance-Optimierungen

Connection-Pooling und Keep-Alive-Optimierung auf Router-Level minimieren Backend-Connection-Overhead:

Performance-Tuning-Annotations:

metadata:
  annotations:
    haproxy.router.openshift.io/timeout: "30s"
    haproxy.router.openshift.io/balance: "roundrobin"
    haproxy.router.openshift.io/disable_cookies: "true"

33.3 Alternative Ingress-Controller

Neben dem Standard-HAProxy-Router unterstützt OpenShift verschiedene alternative Ingress-Controller für spezielle Anforderungen.

33.3.1 NGINX Ingress Controller

NGINX Ingress Controller bieten alternative Router-Implementierungen mit NGINX-spezifischen Features:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rate-limit: "100"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"
spec:
  ingressClassName: nginx
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /api/v1
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

NGINX-spezifische Features: - Rate Limiting und Request Buffering - Advanced SSL-Konfigurationen - WebSocket-Unterstützung - Custom Error Pages

33.3.2 Traefik Ingress Controller

Traefik implementiert dynamische Service-Discovery mit automatischer Route-Generierung:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: traefik-ingress
  annotations:
    traefik.ingress.kubernetes.io/router.middlewares: "default-auth@kubernetescrd"
spec:
  rules:
  - host: dashboard.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: dashboard-service
            port:
              number: 8080

33.3.3 Istio Gateway Integration

Istio Gateway ermöglicht Service-Mesh-basiertes Traffic-Management mit erweiterten Sicherheits-Features:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: webapp-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - webapp.example.com
    tls:
      httpsRedirect: true
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: webapp-tls-secret
    hosts:
    - webapp.example.com

33.4 Routing-Strategien

33.4.1 Host-basiertes Routing

Host-basiertes Routing dirigiert Traffic basierend auf HTTP-Host-Headern zu verschiedenen Backend-Services:

# Route 1: Hauptanwendung
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: main-app-route
spec:
  host: app.example.com
  to:
    kind: Service
    name: main-app-service

---
# Route 2: API-Service
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: api-route
spec:
  host: api.example.com
  to:
    kind: Service
    name: api-service

33.4.2 Path-basiertes Routing

Path-basiertes Routing implementiert URL-Path-Matching für Request-Routing zu spezifischen Services:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: path-based-ingress
spec:
  rules:
  - host: platform.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /frontend
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 3000
      - path: /admin
        pathType: Prefix
        backend:
          service:
            name: admin-service
            port:
              number: 8080

33.4.3 Wildcard-Domain-Support

Wildcard-Domains ermöglichen dynamisches Subdomain-Routing für Multi-Tenant-SaaS-Anwendungen:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: tenant-wildcard-route
spec:
  host: "*.tenants.example.com"
  to:
    kind: Service
    name: tenant-service
  tls:
    termination: edge
    wildcardPolicy: Subdomain

33.5 SSL/TLS-Management

33.5.1 TLS-Terminierungs-Modi

OpenShift unterstützt verschiedene TLS-Terminierungs-Strategien je nach Sicherheitsanforderungen:

Terminierungs-Typ Beschreibung Anwendungsfall
Edge TLS-Terminierung am Router Standard-Web-Anwendungen
Passthrough TLS-Terminierung am Pod End-to-End-Verschlüsselung erforderlich
Re-encrypt TLS-Terminierung am Router, Re-Verschlüsselung zum Pod Hybrid-Sicherheitsanforderungen

Edge Termination:

spec:
  tls:
    termination: edge
    certificate: |
      -----BEGIN CERTIFICATE-----
      [Certificate content]
      -----END CERTIFICATE-----
    key: |
      -----BEGIN PRIVATE KEY-----
      [Private key content]
      -----END PRIVATE KEY-----
    caCertificate: |
      -----BEGIN CERTIFICATE-----
      [CA Certificate content]
      -----END CERTIFICATE-----

Passthrough Termination:

spec:
  tls:
    termination: passthrough
  # Kein Zertifikat erforderlich - wird vom Pod bereitgestellt

33.5.2 Automatische Zertifikatserneuerung

Let’s Encrypt-Integration für automatische Zertifikatserneuerung:

# cert-manager Installation
oc apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.yaml

# ClusterIssuer für Let's Encrypt
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

33.5.3 Security Headers

Sicherheits-Header-Konfiguration für verbesserte Web-Anwendungssicherheit:

metadata:
  annotations:
    haproxy.router.openshift.io/set-header: |
      Strict-Transport-Security "max-age=31536000; includeSubDomains"
      X-Frame-Options "DENY"
      X-Content-Type-Options "nosniff"
      X-XSS-Protection "1; mode=block"
      Referrer-Policy "strict-origin-when-cross-origin"

33.6 Traffic-Management und Load-Balancing

33.6.1 Weighted Routing für Canary Deployments

Weighted Routing ermöglicht Traffic-Verteilungskontrolle zwischen Services für Canary-Deployments:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: canary-route
spec:
  host: webapp.example.com
  to:
    kind: Service
    name: webapp-stable
    weight: 90
  alternateBackends:
  - kind: Service
    name: webapp-canary
    weight: 10
  tls:
    termination: edge

33.6.2 Session Affinity

Session-Affinity-Implementierung über HTTP-Cookies:

metadata:
  annotations:
    haproxy.router.openshift.io/balance: "source"
    # oder Cookie-basierte Affinität:
    haproxy.router.openshift.io/cookie_name: "webapp-session"

33.6.3 Rate Limiting

Rate-Limiting-Policies auf Router-Level für DDoS-Schutz:

# NGINX Ingress Rate Limiting
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rate-limit-requests: "100"
    nginx.ingress.kubernetes.io/rate-limit-window: "1m"
    nginx.ingress.kubernetes.io/rate-limit-connections: "10"

33.6.4 Health Checks

Erweiterte Health-Check-Konfiguration:

metadata:
  annotations:
    haproxy.router.openshift.io/health_check_interval: "5s"
    haproxy.router.openshift.io/health_check_timeout: "3s"
    haproxy.router.openshift.io/health_check_uri: "/health"

33.7 Monitoring und Observability

33.7.1 Request-Tracing

Request-Tracing auf Ingress-Level für End-to-End Request-Tracking:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/enable-opentracing: "true"
    nginx.ingress.kubernetes.io/opentracing-operation-name: "HTTP $request_method $uri"

33.7.2 Access Logging

Strukturierte Access-Logs für Traffic-Analytics:

# HAProxy Router Logging-Konfiguration
metadata:
  annotations:
    haproxy.router.openshift.io/log-level: "info"
    # Custom Log-Format
    haproxy.router.openshift.io/capture-headers: "X-Request-ID,User-Agent"

33.7.3 Performance-Metriken

Wichtige Ingress-Controller-Metriken für Monitoring:

HAProxy Router Metriken: - haproxy_frontend_http_requests_total: Gesamtanzahl HTTP-Requests - haproxy_frontend_http_response_time_average_seconds: Durchschnittliche Antwortzeit - haproxy_backend_up: Backend-Gesundheitsstatus - haproxy_frontend_current_sessions: Aktuelle Sessions

NGINX Ingress Metriken: - nginx_ingress_controller_requests: Request-Anzahl nach Ingress - nginx_ingress_controller_request_duration_seconds: Request-Dauer - nginx_ingress_controller_response_size_bytes: Response-Größe

33.7.4 Prometheus-Integration

Metriken-Sammlung für Ingress-Controller:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: nginx-ingress-metrics
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
  endpoints:
  - port: prometheus
    interval: 30s
    path: /metrics

33.8 Custom Annotations und erweiterte Funktionalität

33.8.1 HAProxy-spezifische Annotations

Route-Annotations für HAProxy-spezifische Features:

metadata:
  annotations:
    # Timeout-Konfiguration
    haproxy.router.openshift.io/timeout: "30s"
    haproxy.router.openshift.io/timeout-tunnel: "1h"
    
    # Backend-Konfiguration
    haproxy.router.openshift.io/balance: "leastconn"
    haproxy.router.openshift.io/disable_cookies: "true"
    
    # Header-Manipulation
    haproxy.router.openshift.io/set-header: "X-Forwarded-Proto https"
    haproxy.router.openshift.io/rewrite-target: "/api/v1"

33.8.2 Custom Error Pages

Benutzerdefinierte Fehlerseiten-Konfiguration:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/custom-http-errors: "404,503"
    nginx.ingress.kubernetes.io/default-backend: "error-pages-service"

33.8.3 Maintenance Mode

Wartungsmodus-Konfiguration über Annotations:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/server-snippet: |
      return 503 "Service temporarily unavailable";

33.9 Development und Testing

33.9.1 Local Development mit nip.io

Wildcard-DNS-Resolution für Development ohne DNS-Server-Konfiguration:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: dev-webapp-route
spec:
  host: webapp.192.168.1.100.nip.io
  to:
    kind: Service
    name: webapp-service

33.9.2 Port-Forwarding-Alternative

kubectl/oc port-forward als Alternative für schnelle Tests:

# Port-Forwarding zum Service
oc port-forward service/webapp-service 8080:80

# Port-Forwarding zu einem Pod
oc port-forward pod/webapp-pod-12345 8080:8080

# Hintergrund-Prozess
oc port-forward service/webapp-service 8080:80 &

33.9.3 Local SSL-Testing

Self-Signed Certificates für lokale SSL-Tests:

# Zertifikat erstellen
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout tls.key -out tls.crt \
  -subj "/CN=webapp.local.example.com"

# Secret erstellen
oc create secret tls webapp-tls --cert=tls.crt --key=tls.key

33.9.4 Multi-Environment Routing

Environment-spezifische Routing-Konfiguration:

# Development
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: webapp-dev
  namespace: webapp-dev
spec:
  host: webapp-dev.apps.cluster.example.com
  to:
    kind: Service
    name: webapp-service

---
# Production
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: webapp-prod
  namespace: webapp-prod
spec:
  host: webapp.example.com
  to:
    kind: Service
    name: webapp-service
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect