Ce que nous avons appris en migrant les contrôleurs d'entrée Kubernetes chez Digital.ai

Dans ce post, Digital.aiL'équipe CloudOps de [Nom de l'entreprise] partage son point de vue sur les décisions et l'approche qui ont guidé une récente migration Ingress.

Les clients s'attendent à de la stabilité. Digital.ai Notre contrat de niveau de service (MSA) standard garantit une disponibilité de 99.5 % ou plus. un peu moins de quatre heures de coupures non programmées par mois. Au début de 2025, nous avons changé notre Kubernetes Nous devions concevoir une solution pour mettre en place un contrôleur d'entrée NGINX vers Traefik afin de prendre en charge certaines fonctionnalités personnalisées. safely, mais cela nous a permis une certaine flexibilité. Nous avons opté pour l'utilisation de DNS pondéré enregistrements avec Amazon Route 53.

DNS pondéré

Le DNS pondéré (ou routage pondéré) fonctionne en associant un nom de domaine pleinement qualifié (par exemple, un nom de domaine complet). www.digital.aiLe DNS pondéré utilise plusieurs enregistrements, chacun se voyant attribuer un poids. Plus le poids est élevé, plus le trafic est important vers cet enregistrement. Le DNS pondéré permet de minimiser les risques sans compromettre la possibilité d'expérimenter et d'ajuster en temps réel. Par exemple, une première série de modifications de poids peut diriger 10 % du trafic vers votre nouveau point de terminaison, tandis que 90 % restent dirigés vers l'ancien. Les séries suivantes peuvent augmenter le poids du nouveau point de terminaison. Ces modifications successives des poids permettent de surveiller les tendances de trafic et de détecter les problèmes inattendus, tout en minimisant l'impact des changements.

Le Monitoring

Le suivi des erreurs 4xx/5xx vous permettra de déterminer les pondérations appropriées. Si le nombre d'erreurs augmente pour votre nouveau point de terminaison, mais reste stable pour l'ancien, recherchez la cause du dysfonctionnement du nouveau point de terminaison, effectuez les ajustements nécessaires, surveillez la situation et répétez l'opération si besoin.

Traefik

Bien que NGINX nous ait donné entière satisfaction, nous sommes arrivés à la conclusion que Traefik était le contrôleur Ingress idéal pour l'avenir. Traefik est prêt pour la production, éprouvé en conditions réelles et offre de nombreuses fonctionnalités. Une meilleure visibilité grâce à Traefik nous permet d'identifier plus rapidement la cause première des problèmes.

Mise en œuvre

Phase 1 (mise en place)

• Deployed Traefik en parallèle avec NGINX
• Règles de routage identiques configurées
• Création d'annotations sur les Ingress pour créer des enregistrements DNS pondérés
  • Pondération initiale des enregistrements pour diriger le trafic exclusivement vers NGINX.

Phase 2 (migration)

• Commencez par un poids arbitrairement faible (10 %) sur Traefik
• Surveillez les indicateurs de débit, d'erreurs et de latence.
• Augmenter le poids sur l'entrée Traefik

Annotations DNS externes

Grâce aux annotations fournies par ExternalDNS, nous pouvons créer des enregistrements DNS pondérés dans Route53.

external-dns.alpha.kubernetes.io/aws-weight Cela indique à ExternalDNS de créer un enregistrement pondéré et de lui attribuer un poids. AWS autorise les enregistrements pondérés avec des valeurs comprises entre 0 et 255. Si vous souhaitez diriger un très faible volume de trafic vers un point de terminaison, vous pouvez définir le poids à 1, ce qui enverra (1/(1+255)) du trafic vers le point de terminaison de test et le reste (255/(1+255)) vers l'autre point de terminaison. Ceci permet d'utiliser des poids différents pour équilibrer le trafic vers différents points de terminaison. Par souci de simplicité, nous avons utilisé 100 comme poids.

external-dns.alpha.kubernetes.io/set-identifier Il s'agit d'une annotation spécifique au fournisseur qui crée un identifiant d'ensemble. Cet identifiant permet de différencier plusieurs enregistrements DNS ayant la même combinaison de type et de domaine. Par exemple, un ensemble peut pointer vers nginx et un autre vers traefik. En combinant ces identifiants avec des pondérations, il est possible de répartir le trafic entre les deux serveurs.

Mise en œuvre technique

Commençons par diriger tout le trafic vers nginx ; nous pouvons constater que nous avons créé un set-identifier appelé nginx. Nous en créons un autre set-identifier pour Traefik et il n'y a aucun trafic vers cette destination.

# 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 surveille les annotations des Ingress et crée des enregistrements DNS pondérés dans Route 53 ; aucune gestion DNS manuelle n’est requise. ExternalDNS nous permet de rediriger le trafic en mettant à jour les annotations.

# 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"}}}'

Leçons apprises

Nous avons assuré une migration sans interruption de service de NGINX vers Traefik, tout en améliorant notre disponibilité. Ce succès est dû aux facteurs suivants :

1. Changement progressif de la circulationLe DNS pondéré nous a permis de rediriger facilement le trafic tout en surveillant la transition.
2. Le MonitoringLa visibilité sur les infrastructures anciennes et nouvelles nous a permis de gagner en confiance dans notre capacité à déplacer les charges.
3. DNS externeL'utilisation d'ExternalDNS nous a permis d'adopter une approche non interventionniste en matière de DNS.

Meilleures pratiques de migration

Nos conseils à tous ceux qui envisagent une voie similaire :

• Commencez petitCommencez votre migration par les services non critiques.
• AutomatisationAutomatisez autant que possible, utilisez une approche GitOps pour modifier les pondérations.
• Ré-apprenez à prendre votre tempsAccordez-vous le temps nécessaire pour effectuer les changements.
• Surveiller en permanenceConfigurez un système d'alertes pour être informé de tout problème potentiel.
• Documentation: Documenter les processus, les procédures et les manuels d'exploitation pour chaque phase de la migration.

Conclusion

La migration des contrôleurs Ingress ne nécessite pas d'interruption de service planifiée. Grâce à l'utilisation d'enregistrements DNS pondérés, nous avons pu migrer les contrôleurs Ingress tout en améliorant la disponibilité. La clé de notre succès a été d'aborder la migration comme un processus progressif plutôt que comme une opération binaire. Cela nous a permis de suivre chaque étape de la migration. Cette approche par phases nous a donné l'assurance que nos modifications avaient un impact significatif.