--- title: "Comment migrer du Load Balancer pour MKS (IOLB) vers le Load Balancer Public Cloud (Octavia)" description: "L'objectif de ce guide est d'aider les utilisateurs du Managed Kubernetes Service (MKS) OVHcloud à migrer d'un Load Balancer pour Managed Kubernetes existant vers un Load Balancer Public Cloud" url: https://docs.ovhcloud.com/fr/guides/public-cloud/containers-orchestration/managed-kubernetes/migrate-iolb-to-public-cloud-loadbalancer lang: fr lastUpdated: 2025-05-14 --- > For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt. # Comment migrer du Load Balancer pour MKS (IOLB) vers le Load Balancer Public Cloud (Octavia) ## Objectif L'objectif de ce guide est d'aider les utilisateurs du Managed Kubernetes Service (MKS) OVHcloud à migrer d'un [Load Balancer pour Managed Kubernetes](https://www.ovhcloud.com/fr/public-cloud/load-balancer-kubernetes/) existant vers un [Load Balancer Public Cloud](https://www.ovhcloud.com/fr/public-cloud/load-balancer/). Le [Load Balancer Public Cloud](https://www.ovhcloud.com/fr/public-cloud/load-balancer/) est le Load Balancer par défaut pour les clusters MKS utilisant des versions de Kubernetes >1.30. Le [Load Balancer pour Managed Kubernetes](https://www.ovhcloud.com/fr/public-cloud/load-balancer-kubernetes/) est déprécié pour les clusters MKS utilisant des versions de Kubernetes >1.31. Ce guide explique les étapes nécessaires pour effectuer cette transition en toute sécurité, en minimisant les interruptions de service. Enfin, il fournit des recommandations sur la gestion DNS, en particulier la réduction du TTL, afin d'optimiser la propagation des changements et d'assurer une migration en douceur. :::warning Comme Load Balancer for Kubernetes et Public Cloud Load Balancer n'utilisent pas la même solution d'allocation d'IP publique, il n'est pas possible de conserver l'IP publique existante de votre Load Balancer for Kubernetes. Changer la classe de Load Balancer de votre Service entraînera la création d'un nouveau Load Balancer et l'allocation d'une nouvelle IP publique (Floating IP). ::: ## Comparaison Voici une comparaison entre Load Balancer for Kubernetes et Public Cloud Load Balancer, mettant en évidence leurs principales différences et capacités. Public Cloud Load Balancer propose plusieurs tailles/flavors ; vous trouverez les spécifications détaillées sur la [page Public Cloud Load Balancer](https://www.ovhcloud.com/fr/public-cloud/load-balancer/). | | Load Balancer pour Managed Kubernetes | Load Balancer Public Cloud | | ------------------------------------------------ | ------------------------------------- | ------------------------------------- | | Nombre maximum de connexions | 10 000 | jusqu'à 20 000 | | Nombre maximum de requêtes HTTP | 2000 | Jusqu'à 80 000 | | Bande passante | 200 Mbit/s | jusqu'à 4 Gbit/s (montant/descendant) | | Protocole pris en charge | TCP | TCP/UDP/SCTP | | Couches d'équilibrage de charge prises en charge | L4 | L4/L7 | | Capacité à exporter métriques et logs | Non | Oui | | Scénario privé vers privé | Non | Oui | | Floating IP | Non | Oui | ## Annotations Voici une correspondance entre les annotations existantes prises en charge sur [Load Balancer pour Managed Kubernetes](https://www.ovhcloud.com/fr/public-cloud/load-balancer-kubernetes/) et leur équivalent sur [Load Balancer Public Cloud](https://www.ovhcloud.com/fr/public-cloud/load-balancer/). :::warning Si vous utilisez des annotations héritées de [Load Balancer pour Managed Kubernetes](https://www.ovhcloud.com/fr/public-cloud/load-balancer-kubernetes/), vous devez les mettre à jour vers le nouveau format prise en charge par [Load Balancer Public Cloud](https://www.ovhcloud.com/fr/public-cloud/load-balancer/) lors de la migration. Certaines annotations ont été **dépréciées** et doivent être remplacées pour garantir une compatibilité complète. ::: Vous trouverez tous les détails sur les pages de documentation officielles : - [Annotations du Load Balancer pour Managed Kubernetes](https://docs.ovhcloud.com/fr/guides/public-cloud/containers-orchestration/managed-kubernetes/using-lb.md#annotations-prises-en-charge) - [Annotations du Load Balancer Public Cloud](https://docs.ovhcloud.com/fr/guides/public-cloud/containers-orchestration/managed-kubernetes/expose-applications-using-load-balancer.md#annotations-et-fonctionnalit%C3%A9s-prises-en-charge) | Load Balancer pour Managed Kubernetes | Load Balancer Public Cloud | | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `service.beta.kubernetes.io/ovh-loadbalancer-proxy-protocol`
Valeurs prises en charge :
- v1
- v2
- v2-ssl
- v2-ssl-cn | `loadbalancer.openstack.org/proxy-protocol`
Valeurs prises en charge :
- v1, true : active la version 1 du ProxyProtocol
- v2 : active la version 2 du ProxyProtocol


| | `service.beta.kubernetes.io/ovh-loadbalancer-allowed-sources`
--> DÉPRÉCIÉE\*\* | Pas d'annotation.
La restriction d'IP est définie via `.spec.loadBalancerSourceRanges` | | `service.beta.kubernetes.io/ovh-loadbalancer-balance`
Valeurs prises en charge :
- first
- leastconn
- roundrobin
- source | `loadbalancer.openstack.org/lb-method`
Valeurs prises en charge :
- ROUND\_ROBIN
- LEAST\_CONNECTIONS
- SOURCE\_IP
| ## Migration de votre Load Balancer :::warning À partir des clusters MKS utilisant la version Kubernetes **1.31**, toute tentative de mise à niveau du cluster sera bloquée si un service de type Load Balancer reposant sur [Load Balancer pour Managed Kubernetes](https://www.ovhcloud.com/fr/public-cloud/load-balancer-kubernetes/) (IOLB) est encore présent dans le cluster. **Action requise** : avant la mise à niveau, vous devez **transformer vos services en Load Balancer Public Cloud (Octavia)** en suivant les étapes décrites dans ce guide. Si vous tentez une mise à niveau sans avoir migré au préalable, une erreur sera renvoyée, empêchant la mise à niveau. ::: Il existe deux méthodes pour passer d'un [Load Balancer pour Managed Kubernetes](https://www.ovhcloud.com/fr/public-cloud/load-balancer-kubernetes/) à un [Load Balancer Public Cloud](https://www.ovhcloud.com/fr/public-cloud/load-balancer/) : vous pouvez soit **[migrer](#migration)**, soit **[remplacer](#remplacement)** votre Load Balancer. Votre Service Load Balancer existant utilisant [Load Balancer for Kubernetes](https://www.ovhcloud.com/fr/public-cloud/load-balancer-kubernetes/) devrait comporter l'annotation suivante : ```yaml annotations: loadbalancer.ovhcloud.com/class: "iolb" ``` :::danger Chacune des deux méthodes décrites ci-dessous ([migration](#migration) ou [remplacement](#remplacement)) nécessite un changement DNS pour lequel une propagation DNS de 24 à 48 heures est requise **avant** d'effectuer la migration. Par conséquent, veuillez **lire l'intégralité de ce guide** (et notamment la section « Comment effectuer un changement DNS ? ») avant de procéder aux étapes ci-dessous. ::: ### Migration Migrer d'un [Load Balancer for Kubernetes](https://www.ovhcloud.com/fr/public-cloud/load-balancer-kubernetes/) existant vers un [Load Balancer Public Cloud](https://www.ovhcloud.com/fr/public-cloud/load-balancer/) consiste à créer un nouveau service Load Balancer utilisant le Load Balancer Public Cloud avec le même sélecteur de labels pour exposer votre application. Pendant une courte période, votre application sera accessible via les deux Load Balancers. À ce stade, vous pouvez effectuer un changement DNS puis supprimer l'ancien Load Balancer. Pour migrer d'un [Load Balancer for Kubernetes](https://www.ovhcloud.com/fr/public-cloud/load-balancer-kubernetes/) existant vers un [Load Balancer Public Cloud](https://www.ovhcloud.com/fr/public-cloud/load-balancer/), suivez ces étapes : #### Étape 1 - Créer un nouveau service Load Balancer Vous devez créer un nouveau service Load Balancer utilisant le Load Balancer Public Cloud tout en conservant l'ancien actif : - Assurez-vous que le nouveau service dispose du même labelSelector que l'ancien, afin qu'il expose la même application. - Vous pouvez définir l'annotation `loadbalancer.ovhcloud.com/class: "octavia"` pour un cluster `<1.31`, ou la supprimer complètement pour un cluster `>= 1.31`, Octavia étant utilisé par défaut. **labelSelector** : ```yaml spec: selector: app: my-app ``` **annotations** : ```yaml annotations: loadbalancer.ovhcloud.com/class: "octavia" # if your cluster <1.31 loadbalancer.ovhcloud.com/flavor: "small" # Available values: small (default) | medium | large | xl loadbalancer.openstack.org/timeout-client-data: 180000 # The default value (in milliseconds) on the iolb solution, can be customized loadbalancer.openstack.org/timeout-member-connect: 20000 # The default value (in milliseconds) on the iolb solution, can be customized loadbalancer.openstack.org/timeout-member-data: 180000 # The default value (in milliseconds) on the iolb solution, can be customized ``` Appliquez le nouveau service avec : ```yaml kubectl apply -f your-service-manifest.yaml ``` Cela créera un nouveau Load Balancer Public Cloud avec une nouvelle IP publique. #### Étape 2 - Tester l'accès à l'application Une fois le nouveau Load Balancer créé, récupérez les IP publiques des deux services : ```yaml kubectl get svc -o wide ``` Vous devriez voir deux services Load Balancer pointant vers la même application avec des IP publiques différentes. Testez l'accessibilité via les deux IP : ```yaml curl http://`` curl http://`` ``` Les deux devraient renvoyer une réponse valide de votre application. #### Étape 3 - Effectuer un changement DNS Pour effectuer un changement DNS, consultez la partie [Comment effectuer un changement DNS ?](#dns-switch) de ce guide. #### Étape 4 - Supprimer le service Load Balancer for Kubernetes (aussi appelé IOLB) Une fois que vous avez confirmé que le trafic passe bien par le nouveau Load Balancer et que l'ancien n'est plus nécessaire, supprimez l'ancien service Load Balancer en le supprimant : ```yaml kubectl delete svc old-loadbalancer-service ``` ### Remplacement Remplacer un [Load Balancer for Kubernetes](https://www.ovhcloud.com/fr/public-cloud/load-balancer-kubernetes/) existant par un [Load Balancer Public Cloud](https://www.ovhcloud.com/fr/public-cloud/load-balancer/) consiste à modifier le service existant et à changer la classe de loadbalancer de `iolb` à `octavia`. Cela entraînera la réconciliation de la classe de loadbalancer par Kubernetes, en supprimant l'ancien et en créant un nouveau loadbalancer. Une fois le nouveau Load Balancer livré, vous pouvez effectuer un changement DNS en utilisant la nouvelle IP publique. :::warning Notez que pendant le processus de suppression et de création, votre service ne sera pas accessible. Vous pouvez réduire cet impact en abaissant la durée du TTL de votre DNS ; consultez la partie [Comment effectuer un changement DNS ?](#dns-switch) de ce guide. ::: #### Étape 1 - Modifier votre Service pour changer la classe de Load Balancer en 'octavia' :::warning L'ancien Load Balancer et son adresse IP seront supprimés **définitivement**, rendant les services inaccessibles. Effectuez immédiatement le changement DNS avec la nouvelle IP fournie. ::: ```yaml annotations: loadbalancer.ovhcloud.com/class: "octavia" // not required for clusters running kubernetes versions >= 1.31, you can just remove the annotation. ``` Appliquez la mise à jour du service avec : ```yaml kubectl apply -f your-service-manifest.yaml ``` #### Étape 2 - Effectuer un changement DNS Pour effectuer un changement DNS, suivez les étapes ci-dessous. [](#) ## Comment effectuer un changement DNS ? ### Vérifier le TTL actuel Par défaut, les serveurs DNS mettent en cache l'adresse IP d'un domaine pendant une durée définie par le TTL (Time-To-Live). Un TTL trop long peut ralentir la transition en forçant certains utilisateurs à attendre plusieurs heures avant d'accéder au nouveau Load Balancer. Pour éviter cela, nous recommandons de réduire temporairement le TTL avant de mettre à jour l'IP. Avant de modifier le TTL, il est important de connaître sa valeur actuelle. Pour cela, exécutez la commande suivante dans un terminal : ```bash dig yourdomain.com +noall +answer yourdomain.com. 600 IN A 17*.***.**.*4 ``` Ici, 600 correspond au TTL en secondes (soit environ 10 minutes). Cela signifie que les serveurs DNS conservent cette IP en cache pendant cette durée avant de vérifier une mise à jour. ### Réduire le TTL avant la migration Pour réduire le TTL, suivez ces étapes : - Accédez à votre console de gestion DNS. - Trouvez l'enregistrement A (ou CNAME) associé à votre domaine. - Modifiez le TTL de votre enregistrement A ou CNAME en le réduisant à 300 secondes (5 minutes). - Attendez 24 à 48 heures pour que ce nouveau TTL se propage. :::info Pourquoi attendre ? Parce que les serveurs DNS doivent d'abord vider leur cache avant d'adopter le nouveau TTL. ::: ### Mettre à jour l'IP du Load Balancer Une fois la réduction du TTL propagée : - Remplacez l'ancienne IP par celle du nouveau Load Balancer dans votre enregistrement DNS. - Grâce à la faible valeur du TTL, les utilisateurs verront rapidement la mise à jour. - Vérifiez que le changement est effectif en utilisant la même commande `dig` qu'auparavant. Vous devriez voir la nouvelle adresse IP affichée dans le résultat de la commande. ### Restaurer le TTL après la migration Une fois la transition validée et l'ancien Load Balancer déconnecté, reconfigurez le TTL avec une valeur plus élevée. ## Ressources complémentaires - [Exposer des applications via des services de type Load Balancer](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/openstack-cloud-controller-manager/expose-applications-using-loadbalancer-type-service.md) - [Utiliser Octavia Ingress Controller](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/octavia-ingress-controller/using-octavia-ingress-controller.md) - [Concepts du Load Balancer OVHcloud](https://docs.ovhcloud.com/fr/guides/public-cloud/network-services/load-balancer-concepts.md) - [Comment monitorer votre Load Balancer Public Cloud avec Prometheus](https://docs.ovhcloud.com/fr/guides/public-cloud/network-services/loadbalancer-monitoring-prometheus.md) ## Aller plus loin Consultez le [dépôt d'exemples Github](https://github.com/ovh/public-cloud-databases-examples/). Consultez notre canal Discord dédié : [https://discord.gg/ovhcloud](https://discord.gg/ovhcloud). Posez vos questions, partagez vos retours et échangez directement avec l'équipe qui développe nos services Containers et Orchestration. Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur [ce lien](https://www.ovhcloud.com/fr/professional-services/) pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services. Échangez avec notre [communauté d'utilisateurs](https://community.ovhcloud.com/).