Was wir bei der Migration von Kubernetes Ingress Controllern gelernt haben Digital.ai

In diesem Beitrag Digital.aiDas CloudOps-Team von gibt Einblicke in die Entscheidungen und die Vorgehensweise hinter einer kürzlich erfolgten Ingress-Migration.

Kunden erwarten Stabilität. Digital.ai Unser Standard-MSA gewährleistet eine Verfügbarkeit von 99.5 % oder knapp vier Stunden ungeplanter Stromausfälle pro Monat. Anfang 2025 haben wir umgestellt. Kubernetes Wir mussten einen Weg finden, den Ingress-Controller von NGINX zu Traefik zu übertragen, um einige benutzerdefinierte Funktionen zu unterstützen. safely, aber das ermöglichte uns Flexibilität. Wir entschieden uns für die Verwendung von Gewichtetes DNS Aufzeichnungen bei Amazon Route 53.

Gewichtetes DNS

Gewichtetes DNS (oder gewichtetes Routing) funktioniert durch die Zuordnung eines vollqualifizierten Domänennamens (z. B. 1234). www.digital.aiBei gewichtetem DNS werden mehrere Einträge verwendet, denen jeweils ein Gewicht zugewiesen wird. Höhere Gewichte bedeuten, dass mehr Datenverkehr an einen bestimmten Eintrag geleitet wird. So können Sie Risiken minimieren, ohne auf die Möglichkeit verzichten zu müssen, zu experimentieren und Anpassungen flexibel vorzunehmen. Beispielsweise kann die erste Welle von Gewichtungsänderungen 10 % des Datenverkehrs an Ihren neuen Endpunkt weiterleiten, während 90 % weiterhin an Ihren alten Endpunkt gehen. Weitere Wellen können das Gewicht für den neuen Endpunkt erhöhen. Durch das schrittweise Erhöhen und Verringern der Gewichte können Sie die Datenverkehrsmuster auf unerwartete Probleme überwachen und gleichzeitig deren Auswirkungen minimieren.

Überwachung

Die Überwachung des Datenverkehrs hinsichtlich 4xx/5xx-Fehlern ist entscheidend für die Gewichtung der Fehler. Steigt die Fehlerrate für Ihren neuen Endpunkt, bleibt sie für Ihren alten Endpunkt jedoch ähnlich? Untersuchen Sie die Ursache für das Fehlverhalten des neuen Endpunkts, nehmen Sie Anpassungen vor, überwachen Sie die Situation und wiederholen Sie den Vorgang bei Bedarf.

Traefik

Obwohl NGINX uns gute Dienste geleistet hat, kamen wir zu dem Schluss, dass Traefik der Ingress-Controller der Zukunft ist. Traefik ist produktionsreif, praxiserprobt und bietet zahlreiche Funktionen. Dank der besseren Überwachung mit Traefik können wir die Ursache von Problemen schneller ermitteln.

Umsetzung

Phase 1 (Einrichtung)

• Deployed Traefik parallel zu NGINX
• Identische Routingregeln konfiguriert
• Es wurden Annotationen für Ingress-Einträge erstellt, um gewichtete DNS-Einträge zu erzeugen.
  • Zunächst werden die Datensätze so gewichtet, dass der Datenverkehr ausschließlich auf NGINX gelenkt wird.

Phase 2 (Migration)

• Beginnen Sie mit einer willkürlich niedrigen Gewichtung (10 %) auf Traefik.
• Überwachen Sie die Durchsatz-, Fehler- und Latenzwerte.
• Erhöhen Sie das Gewicht beim Traefik-Einstieg

Externe DNS-Annotationen

Mithilfe der von ExternalDNS bereitgestellten Annotationen können wir gewichtete DNS-Einträge in Route53 erstellen.

external-dns.alpha.kubernetes.io/aws-weight Dies weist ExternalDNS an, einen gewichteten Datensatz zu erstellen und ihm ein Gewicht zuzuweisen. AWS erlaubt gewichtete Datensätze mit Werten zwischen 0 und 255. Wenn Sie nur sehr wenig Datenverkehr an einen Endpunkt senden möchten, können Sie das Gewicht auf 1 setzen. Dadurch wird (1/(1+255)) des Datenverkehrs an den Testendpunkt und der Rest (255/(1+255)) an den anderen Endpunkt gesendet. So können Sie den Datenverkehr durch unterschiedliche Gewichtungen auf verschiedene Endpunkte verteilen. Der Einfachheit halber haben wir 100 als Gewichtung verwendet.

external-dns.alpha.kubernetes.io/set-identifier ist eine anbieterspezifische Annotation, die eine Set-Kennung erstellt. Mithilfe einer Set-Kennung lassen sich mehrere DNS-Einträge mit derselben Kombination aus Typ und Domain voneinander unterscheiden. Beispielsweise kann ein Set auf nginx und ein anderes auf traefik verweisen. In Kombination mit Gewichtungen kann der Traffic so aufgeteilt werden, dass ein Teil auf den einen und ein anderer Teil auf den anderen Server geleitet wird.

Technische Umsetzung

Beginnen wir damit, dass der gesamte Datenverkehr an nginx geleitet wird. Wir können sehen, dass wir einen Server erstellt haben. set-identifier namens nginx. Wir erstellen einen weiteren set-identifier für Traefik und dort gibt es keinen Verkehr.

# NGINX example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-nginx
  annotations:
    external-dns.alpha.kubernetes.io/aws-weight: "100"
    external-dns.alpha.kubernetes.io/set-identifier: "nginx"
spec:
  ingressClassName: nginx
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

# Traefik example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-traefik
  annotations:
    external-dns.alpha.kubernetes.io/aws-weight: "0"
    external-dns.alpha.kubernetes.io/set-identifier: "traefik"
spec:
  ingressClassName: traefik
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

ExternalDNS überwacht die Annotationen der Ingress-Router und erstellt gewichtete DNS-Einträge in Route 53; eine manuelle DNS-Verwaltung ist nicht erforderlich. ExternalDNS ermöglicht es uns, den Datenverkehr durch Aktualisierung der Annotationen umzuleiten.

# Shift to 50/50 traffic split
kubectl patch ingress api-nginx -p '{"metadata":{"annotations":{"external-dns.alpha.kubernetes.io/aws-weight":"50"}}}'
kubectl patch ingress api-traefik -p '{"metadata":{"annotations":{"external-dns.alpha.kubernetes.io/aws-weight":"50"}}}'

# Both endpoints should now be handling half the traffic.
# Monitor traffic to ensure that traffic is behaving as expected.
# Use additional waves to update the balance of traffic until you feel confident.

# Switch to 100% Traefik
kubectl patch ingress api-nginx -p '{"metadata":{"annotations":{"external-dns.alpha.kubernetes.io/aws-weight":"0"}}}'
kubectl patch ingress api-traefik -p '{"metadata":{"annotations":{"external-dns.alpha.kubernetes.io/aws-weight":"100"}}}'

Lessons Learned

Wir haben während der Migration von NGINX zu Traefik keine Ausfallzeiten erreicht und gleichzeitig unsere Verfügbarkeit verbessert. Diesen Erfolg führen wir auf folgende Faktoren zurück:

1. Allmählich verlagernder VerkehrWeighted DNS ermöglichte es uns, den Datenverkehr einfach umzuleiten und gleichzeitig den Übergang zu überwachen.
2. ÜberwachungDie Transparenz sowohl der alten als auch der neuen Infrastruktur ermöglichte es uns, Vertrauen in unsere Fähigkeit zur Gewichtsverlagerung zu gewinnen.
3. Externes DNSDie Verwendung von ExternalDNS ermöglichte es uns, uns nicht selbst um DNS kümmern zu müssen.

Best Practices für die Migration

Unser Rat für alle, die einen ähnlichen Weg in Erwägung ziehen:

• Fangen Sie klein anBeginnen Sie Ihre Migration mit nicht kritischen Diensten.
• AutomationAutomatisieren Sie so viel wie möglich; verwenden Sie einen GitOps-Ansatz für die Änderung von Gewichtungen.
• Nehmen Sie sich ZeitNehmen Sie sich ausreichend Zeit, um Änderungen vorzunehmen.
• Kontinuierlich überwachenRichten Sie Benachrichtigungen ein, um sicherzustellen, dass Sie über mögliche Probleme informiert werden.
• Dokumentation: Prozesse, Verfahren und Handbücher für jede Phase der Migration dokumentieren.

Fazit

Die Migration von Ingress-Controllern muss nicht zwangsläufig mit geplanten Ausfallzeiten einhergehen. Durch die Nutzung gewichteter DNS-Einträge konnten wir die Ingress-Controller migrieren und eine höhere Verfügbarkeit erreichen. Entscheidend für unseren Erfolg war, die Migration als schrittweisen Prozess und nicht als abrupten Wechsel zu betrachten. So konnten wir jede Phase der Migration überwachen. Die phasenweise Migration gab uns die Gewissheit, dass unsere Änderungen einen signifikanten Einfluss hatten.