Migration du contrôleur Ingress ( NGINX ) vers le contrôleur Ingress Traefik

Migrer votre configuration Ingress afin d'utiliser le contrôleur Traefik à la place du contrôleur Ingress- NGINX.

Avant de commencer

Vérifiez ces conditions préalables avant de procéder à la migration.

  1. Assurez-vous de disposer des autorisations nécessaires.

    • Rôle d'accès à la plateforme Administrateur pour le cluster
    • Rôle d'accès au service Responsable dans tous les espaces de nom

  2. Passez en revue les ressources Ingress existantes afin de repérer les annotations ou configurations spécifiques à Ingress- NGINX. Consultez la documentation relative aux principales différences entre les deux contrôleurs Ingress.

  3. Élaborez votre stratégie de migration en fonction des exigences liées à la charge de travail, de la tolérance aux temps d'arrêt et de la disponibilité des ressources. Les deux contrôleurs peuvent fonctionner simultanément pendant la migration.

  4. Veillez à ce que votre cluster dispose d'au moins deux nœuds de travail par zone afin de garantir une haute disponibilité.

  5. Sauvegardez vos configurations Ingress actuelles avant d'effectuer des modifications.

Stratégie n° 1 : configuration séparée d'Ingress avec un domaine différent

Testez Traefik avec une configuration distincte tout en conservant l'environnement de production sur Ingress : NGINX. Cette stratégie garantit une isolation et une sécurité optimales.

Utilisez cette stratégie lorsque :

  • Vous devez tester Traefik de manière approfondie avant de migrer les charges de travail de production.
  • Vous pouvez déployer un ensemble différent d'applications à des fins de test.
  • Vous disposez des ressources nécessaires pour faire fonctionner d'autres ALB.
  • Vous souhaitez que votre environnement de production ne courre aucun risque pendant les tests.

Étapes

  1. Obtenir les versions disponibles de Traefik.
    ibmcloud ks ingress alb versions
  2. Créer un nouvel ALB avec Traefik.

Grappes classiques sh {: pre} ibmcloud ks ingress alb create classic --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --vlan VLAN_ID --version TRAEFIK_VERSION Clusters VPC sh {: pre} ibmcloud ks ingress alb create vpc-gen2 --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --version TRAEFIK_VERSION

  1. Pour les clusters VPC, déployez manuellement un service « LoadBalancer » supplémentaire à des fins de test. Définissez « spec.selector » pour inclure « app.kubernetes.io/vpcComponent: public-cr<cluster_id>-traefik » (ou « private-cr<cluster_id>-traefik » pour les ALB privées). Sur les clusters Classic, un nouvel équilibreur de charge est automatiquement mis en place et aucune configuration supplémentaire n'est nécessaire.

  2. Créez un domaine personnalisé pour l'ALB Traefik et associez-le au nom d'hôte ou à l'adresse IP de l'équilibreur de charge. Pour obtenir des instructions détaillées, consultez la section « Création de domaines personnalisés ».

  3. Créez une ressource Ingress pour les applications de test à l'aide de la classe Traefik Ingress. Suivez l'étape 3 : Créez la ressource Ingress en indiquant ingressClassName: public-iks-traefik (ou private-iks-traefik pour les ALB privés).

  4. Testez les applications via le domaine Traefik et vérifiez leur bon fonctionnement.

  5. Une fois les tests terminés, passez à la section « Migration » pour migrer vos charges de travail de production.

Stratégie n° 2 : deux équilibreurs de charge traitant la même charge de travail

Testez les deux contrôleurs sur la même charge de travail en créant deux ressources Ingress pointant vers le même service. Vous pouvez comparer directement le comportement des contrôleurs sans affecter le trafic de production.

Utilisez cette stratégie lorsque :

  • Vous souhaitez comparer le comportement d'Ingress ( NGINX ) et de Traefik sur une même charge de travail.
  • Vous devez vérifier que Traefik gère correctement votre application spécifique.
  • Vous pouvez effectuer des tests en utilisant un domaine hors production.
  • Vous souhaitez réduire au minimum le nombre d'applications de test nécessaires.

Étapes

  1. Activer un nouvel ALB utilisant une version basée sur Traefik.

Grappes classiques sh {: pre} ibmcloud ks ingress alb create classic --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --vlan VLAN_ID --version TRAEFIK_VERSION Clusters VPC sh {: pre} ibmcloud ks ingress alb create vpc-gen2 --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --version TRAEFIK_VERSION

  1. Pour les clusters VPC, déployez manuellement un service « LoadBalancer » supplémentaire à des fins de test. Définissez « spec.selector » pour inclure « app.kubernetes.io/vpcComponent: public-cr<cluster_id>-traefik » (ou « private-cr<cluster_id>-traefik » pour les ALB privées). Sur les clusters Classic, un nouvel équilibreur de charge est automatiquement mis en place et aucune configuration supplémentaire n'est nécessaire.

  2. Créez un domaine personnalisé pour l'ALB Traefik et associez-le au nom d'hôte ou à l'adresse IP de l'équilibreur de charge. Pour obtenir des instructions détaillées, consultez la section « Création de domaines personnalisés ».

  3. Créez une deuxième ressource Ingress qui utilise la classe Ingress de Traefik, mais qui pointe vers le même service que votre ressource Ingress existante : NGINX. Suivez les instructions de l'étape 3 : Créer la ressource Ingress, en veillant à :

    • Indiquez ingressClassName: public-iks-traefik (ou private-iks-traefik pour les ALB privées)
    • Utilisez la même valeur « service.name » que celle utilisée par votre ressource Ingress existante : NGINX Ingress
    • Indiquez votre domaine de test dans les champs « host » et « tls.hosts »

  4. Testez votre application sur ces deux domaines.

    • Accès via le domaine Ingress- NGINX (production)
    • Accès via le domaine Traefik (en test)

  5. Comparez le comportement, les performances et les fonctionnalités des deux contrôleurs.

  6. Une fois la validation effectuée, passez à la section « Effectuer la migration » pour migrer votre domaine de production vers Traefik.

Stratégie n° 3 : Tests de DNS fractionné

Utilisez une configuration DNS fractionnée pour tester Traefik avec votre domaine de production dans un environnement similaire à celui de production, sans perturber vos utilisateurs.

Utilisez cette stratégie lorsque :

  • Vous souhaitez effectuer des tests sur votre domaine de production réel.
  • Vous avez le contrôle de la configuration DNS de votre environnement de test.
  • Vous devez vérifier la configuration exacte de l'environnement de production.
  • Vous souhaitez réduire au minimum les différences entre l'environnement de test et l'environnement de production.

Étapes

  1. Activer un nouvel ALB utilisant une version basée sur Traefik.

Grappes classiques sh {: pre} ibmcloud ks ingress alb create classic --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --vlan VLAN_ID --version TRAEFIK_VERSION Clusters VPC sh {: pre} ibmcloud ks ingress alb create vpc-gen2 --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --version TRAEFIK_VERSION

  1. Pour les clusters VPC, déployez manuellement un service « LoadBalancer » supplémentaire à des fins de test. Définissez « spec.selector » pour inclure « app.kubernetes.io/vpcComponent: public-cr<cluster_id>-traefik » (ou « private-cr<cluster_id>-traefik » pour les ALB privées). Sur les clusters Classic, un nouvel équilibreur de charge est automatiquement mis en place et aucune configuration supplémentaire n'est nécessaire.

  2. Récupérez l'adresse IP (méthode classique) ou le nom d'hôte (VPC) du nouvel ALB Traefik.

    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME

  3. Configurez le DNS fractionné dans votre environnement de test.

    • Pour vos machines de test ou votre réseau, configurez le DNS afin que votre domaine de production soit résolu vers l'adresse IP ou le nom d'hôte de l'ALB Traefik
    • Les utilisateurs de production continuent de se connecter à l'ALB Ingress- NGINX
    • Cela peut se faire via des fichiers « /etc/hosts » locaux, des serveurs DNS internes ou des configurations DNS spécifiques au VPN

  4. Créez une nouvelle ressource Ingress à l'aide de la classe Traefik Ingress en utilisant votre domaine de production. Suivez l'étape 3 : créez la ressource Ingress en indiquant ingressClassName: public-iks-traefik (ou private-iks-traefik pour les ALB privés) ainsi que votre domaine de production dans les champs « host » et « tls.hosts ».

  5. Effectuez un test depuis votre environnement DNS à double point de résolution afin de valider le fonctionnement de Traefik avec le domaine et la configuration de production.

  6. Une fois la validation effectuée, passez à la section « Effectuer la bascule » pour mettre à jour le DNS de production afin qu'il pointe vers Traefik.

Stratégie n° 4 : Migration directe

Passez directement d'Ingress ( NGINX ) à Traefik avec un minimum de modifications de configuration et de gestion des ressources.

Cette stratégie entraîne une interruption du service pendant la migration. Prévoyez une fenêtre de maintenance avant de commencer.

Utilisez cette stratégie lorsque :

  • Votre charge de travail est faible ou vous utilisez des applications non critiques.
  • Vous pouvez accepter de brèves interruptions de service pendant la migration.
  • Vous souhaitez réduire au minimum le nombre de ressources à gérer.
  • Vous avez déjà vérifié la compatibilité avec Traefik dans un autre environnement.
  • Dans l'environnement Classic, vous devez conserver les adresses IP de vos ALB, car vos clients se connectent à l'aide d'adresses IP plutôt que de noms de domaine DNS.

La désactivation puis la réactivation d'un ALB permettent de conserver son adresse IP d'origine, à moins que celle-ci n'ait été attribuée à d'autres services entre-temps. Pour plus d'informations, consultez la section « Activation ou désactivation des ALB ».

Étapes

  1. Récupérez l'ID de votre ALB Ingress- NGINX actuel.

    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME

  2. Désactivez l'ALB Ingress- NGINX.

    ibmcloud ks ingress alb disable --alb ALB_ID --cluster CLUSTER_NAME

    Clusters VPC: si vous désactivez votre dernier ALB public ou privé, attendez que le déploiement de l'ALB et la ressource de service d'équilibrage de charge correspondante soient supprimés avant d'activer un ALB Traefik.

  3. Activez l'ALB avec une version de Traefik.

Grappes classiques sh {: pre} ibmcloud ks ingress alb enable classic --alb ALB_ID --version TRAEFIK_VERSION --cluster CLUSTER_NAME Pour utiliser une adresse IP spécifique pour l'ALB sur Classic, utilisez le drapeau « --ip ». Pour plus d'informations, consultez la section « Activation ou désactivation des ALB ».

[Clusters VPC]{: tag-vpc}
```sh {: pre}
ibmcloud ks ingress alb enable vpc-gen2 --alb ALB_ID --version TRAEFIK_VERSION --cluster CLUSTER_NAME
```
  1. Pour les clusters VPC, configurez Traefik comme backend de l'équilibreur de charge.

Clusters VPC sh {: pre} ibmcloud ks ingress load-balancer backend set --cluster CLUSTER-ID --public-backend traefik [--private-backend traefik]

  1. Mettez à jour vos ressources Ingress afin d'utiliser la classe Ingress de Traefik. Si vos ressources définissent explicitement la classe Ingress, remplacez spec.ingressClassName par public-iks-traefik dans public-iks-k8s-nginx (ou private-iks-k8s-nginx par private-iks-traefik pour les ALB privés).

  2. Appliquez les ressources Ingress mises à jour.

    kubectl apply -f ingress.yaml

  3. Vérifiez que vos applications sont accessibles via le contrôleur Traefik.

    curl https://<domain>/<app_path>

Passer à Traefik

Une fois les tests terminés, basculez le trafic de production vers le contrôleur Traefik. Les étapes diffèrent selon qu'il s'agit d'un cluster classique ou d'un cluster VPC. Sélectionnez l'option qui correspond à votre type de cluster et à votre configuration.

Clusters classiques

Pour les clusters classiques, mettez à jour votre domaine de production afin qu’il pointe vers l’équilibreur de charge qui expose Traefik au lieu d’Ingress : NGINX.

Option 1 : Mettre à jour le mappage de domaine

  1. Récupérez l'adresse IP de votre ALB Traefik.
    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME
  2. Mettez à jour votre nom de domaine pour qu'il pointe vers l'ALB Traefik.
    ibmcloud ks ingress domain update --cluster CLUSTER_NAME --domain DOMAIN_NAME --ip TRAEFIK_ALB_IP
  3. Vérifiez la mise à jour du nom de domaine.
    ibmcloud ks ingress domain ls --cluster CLUSTER_NAME
  4. Testez vos applications via le domaine de production pour vous assurer qu'elles sont désormais gérées par Traefik.

Option 2 : Désactiver les ALB Ingress- NGINX

Vous pouvez également désactiver tous les ALB basés sur Ingress- NGINX, ce qui mettra automatiquement à jour les mappages de domaines.

  1. Répertorier tous les ALB et identifier ceux basés sur Ingress- NGINX.
    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME
  2. Désactivez chaque ALB Ingress- NGINX.
    ibmcloud ks ingress alb disable --alb NGINX_ALB_ID --cluster CLUSTER_NAME
  3. Vérifiez que votre domaine pointe désormais vers les ALB Traefik.
    ibmcloud ks ingress domain ls --cluster CLUSTER_NAME

Option 3 : Conserver les adresses IP de l'ALB

Si vos clients se connectent directement aux adresses IP de l'ALB plutôt qu'aux noms DNS, vous pouvez conserver ces adresses IP pendant la migration. La conservation des adresses IP nécessite la désactivation temporaire des ALB, ce qui entraîne une brève interruption du service.

La désactivation puis la réactivation d'un ALB permettent de conserver son adresse IP d'origine, à moins que celle-ci n'ait été réutilisée par d'autres services.

  1. Répertorier tous les ALB et identifier ceux basés sur Ingress- NGINX afin d'obtenir leurs identifiants et leurs adresses IP.

    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME

  2. Désactivez l'ALB Ingress- NGINX. Cela entraîne une brève interruption du service pour le trafic lié à cette adresse IP.

    ibmcloud ks ingress alb disable --alb ALB_ID --cluster CLUSTER_NAME

  3. Réactivez l'ALB avec une version de Traefik afin de réutiliser la même adresse IP.

    ibmcloud ks ingress alb enable classic --alb ALB_ID --version TRAEFIK_VERSION --cluster CLUSTER_NAME

    Vous pouvez également créer un nouvel ALB et utiliser l'indicateur « --ip » pour réutiliser l'adresse IP d'origine.

  4. Mettez à jour vos ressources Ingress afin d'utiliser la classe Ingress de Traefik. Si vos ressources définissent explicitement la classe Ingress, remplacez spec.ingressClassName par public-iks-traefik dans public-iks-k8s-nginx (ou private-iks-k8s-nginx par private-iks-traefik pour les ALB privés).

  5. Appliquez les ressources Ingress mises à jour.

    kubectl apply -f ingress.yaml

  6. Vérifiez que vos applications sont accessibles via le contrôleur Traefik.

    curl https://<domain>/<app_path>

Clusters de VPC

Pour les clusters VPC, mettez à jour le backend de l'équilibreur de charge afin d'exposer Traefik à la place d'Ingress : NGINX.

Option 1 : Mettre à jour le backend de l'équilibreur de charge

  1. Mettez à jour l'équilibreur de charge pour qu'il utilise le backend Traefik.
    ibmcloud ks ingress load-balancer backend set --cluster CLUSTER_NAME --public-backend traefik [--private-backend traefik]
  2. Vérifiez la configuration de l'équilibreur de charge.
    ibmcloud ks ingress load-balancer get --cluster CLUSTER_NAME
  3. Testez vos applications pour vous assurer qu'elles sont désormais servies par Traefik.

Option 2 : Désactiver les ALB Ingress- NGINX

Vous pouvez également désactiver tous les ALB basés sur Ingress- NGINX.

  1. Répertorier tous les ALB et identifier ceux basés sur Ingress- NGINX.
    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME
  2. Désactivez chaque ALB Ingress- NGINX.
    ibmcloud ks ingress alb disable --alb NGINX_ALB_ID --cluster CLUSTER_NAME
  3. Vérifiez que l'équilibreur de charge utilise désormais les ALB Traefik.
    ibmcloud ks ingress load-balancer get --cluster CLUSTER_NAME

Tâches post-migration

Une fois la migration vers Traefik effectuée, procédez comme suit :

  1. Surveillez vos applications afin de détecter tout comportement inattendu ou toute erreur après la migration.

  2. Mettre à jour la documentation interne afin de refléter la nouvelle configuration d'Ingress avec Traefik.

  3. Supprimez tous les ALB, domaines ou ressources Ingress de test qui ne sont plus nécessaires.

  4. Après avoir vérifié que Traefik fonctionne comme prévu, désactivez les ALB Ingress- NGINX s restants.

    ibmcloud ks ingress alb disable --alb NGINX_ALB_ID --cluster CLUSTER_NAME

Traitement des incidents

Si vous rencontrez des problèmes pendant ou après la migration, suivez les étapes ci-dessous pour les diagnostiquer et les résoudre.

Vérifier la classe Ingress

Vérifiez que les ressources Ingress utilisent la classe Traefik appropriée (public-iks-traefik ou private-iks-traefik).

Vérifier l'état de l'ALB

Assurez-vous que vos ALB Traefik sont en bon état de fonctionnement.

ibmcloud ks ingress alb ls --cluster CLUSTER_NAME
Vérifier l'état d'Ingress

Vérifiez l'état de vos ressources Ingress.

kubectl get ingress -A
Consulter les journaux

Vérifiez si les journaux du contrôleur Traefik contiennent des erreurs.

kubectl logs -n kube-system -l alb-image-type=traefik
Exécuter les diagnostics

Utilisez le rapport d'état d'Ingress pour identifier les problèmes.

ibmcloud ks ingress status-report get --cluster CLUSTER_NAME
Revenir en arrière si nécessaire

Si vous rencontrez des problèmes critiques, revenez à la version Ingress- NGINX en désactivant l'ALB Traefik, puis réactivez l'ALB Ingress- NGINX avec sa version d'origine. Prévoyez de résoudre ces problèmes et de procéder à une nouvelle migration.

Pour obtenir de l'aide supplémentaire, consultez la section « Dépannage d'Ingress » ou contactez le support technique d' IBM Cloud.