Exposer vos applications à l'aide du Load Balancer OVHcloud Public Cloud

Objectif

Ce guide explique comment utiliser le Load Balancer OVHcloud Public Cloud pour exposer vos applications hébergées sur Managed Kubernetes Service (MKS). Si vous n'êtes pas à l'aise avec les différentes façons d'exposer vos applications dans Kubernetes, ou si la notion de type de service « loadbalancer » ne vous est pas familière, nous vous recommandons de commencer par lire le guide expliquant comment exposer votre application déployée sur un OVHcloud Managed Kubernetes Service. Ce guide détaille les différentes méthodes permettant d'exposer vos applications conteneurisées hébergées sur Managed Kubernetes Service.

Notre Load Balancer Public Cloud repose sur le projet OpenStack Octavia, qui fournit un Cloud Controller Manager (CCM) permettant aux clusters Kubernetes d'interagir avec les Load Balancers. Pour Managed Kubernetes Service (MKS), ce Cloud Controller est installé et configuré par notre équipe, ce qui vous permet de créer, d'utiliser et de configurer facilement nos Load Balancers Public Cloud. Vous trouverez la documentation du projet open source CCM ici.

Ce guide utilise des concepts propres à notre Load Balancer Public Cloud (listener, pool, health monitor, member, etc.) et au réseau OVHcloud Public Cloud (Gateway, Floating IP). Vous trouverez plus d'informations sur les concepts du réseau Public Cloud dans notre documentation officielle, par exemple les concepts réseau et les concepts du loadbalancer.

Prérequis

Version de Kubernetes

Pour pouvoir déployer un Load Balancer Public Cloud, votre Managed Kubernetes Service doit utiliser, ou avoir été mis à niveau vers, les versions de correctif suivantes :

Notez que pour les clusters utilisant ces versions, vous devez utiliser l'annotation loadbalancer.ovhcloud.com/class: octavia pour indiquer que vous souhaitez déployer un Load Balancer Public Cloud (basé sur le projet Octavia) pour votre cluster MKS.

Les versions suivantes utiliseront le Load Balancer Public Cloud comme solution de répartition de charge par défaut ; vous n'avez besoin de spécifier aucune annotation :

Prérequis réseau pour exposer vos Load Balancers publiquement

La première étape consiste à vous assurer qu'un vRack existe déjà sur votre projet Public Cloud. Pour cela, vous pouvez suivre ce guide qui explique comment configurer un vRack pour Public Cloud.

Si vous prévoyez d'exposer votre Load Balancer publiquement, afin d'attacher une Floating IP à votre Load Balancer, il est obligatoire de disposer d'une Gateway OVHcloud (un routeur OpenStack) déployée sur le subnet hébergeant votre Load Balancer.

Si elle n'existe pas lorsque vous créez votre premier Load Balancer Public Cloud, un Managed Gateway de taille S sera automatiquement créé. C'est pourquoi nous recommandons de déployer vos clusters MKS sur un réseau et un subnet où une Gateway OVHcloud peut être créée (manuellement ou automatiquement - cf. Créer un réseau privé avec Gateway) ou existe déjà.

Si vous disposez d'un cluster existant/déjà déployé et si :

• Le GatewayIP du subnet est déjà utilisé par une Gateway OVHcloud, aucune action n'est nécessaire. La Gateway OVHcloud (routeur OpenStack) actuelle sera utilisée.
• Le subnet ne dispose pas d'IP réservée pour une Gateway, vous devrez fournir ou créer un subnet compatible. Trois options sont disponibles :
  • Modifier un subnet existant pour réserver une IP pour une Gateway : reportez-vous à la documentation Mettre à jour les propriétés d'un subnet.
  • Fournir un autre subnet compatible : un subnet disposant déjà d'une Gateway OVHcloud ou d'une adresse IP réservée pour une Gateway (Créer un réseau privé avec Gateway)
  • Utiliser un subnet dédié à votre load balancer : cette option est accessible dans l'espace client OVHcloud sous Paramètres avancés > Loadbalancer Subnet, ou via les API/l'Infra as Code, en utilisant le paramètre loadBalancersSubnetId.
• Le GatewayIP est déjà attribué à une Gateway non-OVHcloud (routeur OpenStack). Deux options sont disponibles :
  • Fournir un autre subnet compatible : un subnet disposant déjà d'une Gateway OVHcloud ou d'une adresse IP réservée pour une Gateway (Créer un réseau privé avec Gateway)
  • Utiliser un subnet dédié à vos load balancers : cette option est accessible dans l'espace client OVHcloud sous Paramètres avancés > Loadbalancer Subnet, ou via les API/l'Infra as Code, avec le paramètre loadBalancersSubnetId.

Limitations

• Les Layer 7 Policy & Rules et la terminaison TLS (listener TERMINATED_HTTPS) ne sont pas encore disponibles. Pour ces cas d'usage, vous pouvez vous appuyer sur l'Octavia Ingress Controller
• Le Proxy Protocol n'est pris en charge que pour les services TCP.

Facturation

Lorsque vous exposez votre load balancer publiquement (public-to-public ou public-to-private) :

• S'il n'existe pas déjà, une Gateway OVHcloud unique sera automatiquement créée et facturée pour tous les Load Balancers déployés dans le subnet https://www.ovhcloud.com/fr/public-cloud/prices/#10394.
• Une Floating IP publique sera utilisée : https://www.ovhcloud.com/fr/public-cloud/prices/#10346.
• Chaque Load Balancer Public Cloud est facturé selon sa flavor : https://www.ovhcloud.com/fr/public-cloud/prices/#10420.

En pratique

Selon la version de Kubernetes utilisée par votre cluster, si vous souhaitez utiliser un Load Balancer Public Cloud plutôt que la solution historique Loadbalancer for Kubernetes, vous devrez peut-être ajouter l'annotation loadbalancer.ovhcloud.com/class: "octavia" sur le manifeste de votre Service Kubernetes. Reportez-vous à la section sur la matrice des versions.

Voici un exemple simple d'utilisation du Load Balancer Public Cloud.

1. Déployez un cluster Managed Kubernetes (MKS) fonctionnel à l'aide de l'espace client OVHcloud, de Terraform, Pulumi ou de l'API OVHcloud.

2. Récupérez le fichier kubeconfig nécessaire pour utiliser l'outil kubectl (via l'espace client OVHcloud, Terraform, Pulumi ou l'API). Vous pouvez suivre ce guide.

3. Créez un Namespace et une ressource Deployment à l'aide de la commande suivante :

kubectl create namespace test-lb-ns
kubectl create deployment test-lb --image=nginx -n=test-lb-ns

4. Copiez/collez le code suivant dans un fichier nommé test-lb-service.yaml :

apiVersion: v1
kind: Service
metadata:
  labels:
    app: test-lb
  name: test-lb-service
  namespace: test-lb-ns
  annotations:
    loadbalancer.ovhcloud.com/class: octavia //not required for cluster running kubernetes versions >= 1.31

    # Use `openstack loadbalancer flavor list` to get the full list of available flavors.
    loadbalancer.ovhcloud.com/flavor: small # Name of a loadbalancer flavor, used in MKS Free ONLY.
    loadbalancer.openstack.org/flavor-id: xxx # UUID of a loadbalancer flavor, used in MKS Standard ONLY.
spec:
  ports:
    - name: 80-80
      port: 80
      protocol: TCP
      targetPort: 80
  selector:
      app: test-lb
  type: LoadBalancer

5. Créez un « Service » à l'aide de la commande suivante :

kubectl apply -f test-lb-service.yaml

6. Récupérez l'adresse IP du Service à l'aide de la ligne de commande suivante :

$ kubectl get service test-lb-service -n=test-lb-ns
NAME                 TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
test-lb-service      LoadBalancer   10.3.107.18   141.94.215.240   80:30172/TCP   12m

7. Ouvrez un navigateur web et accédez à : http://141.94.215.240

Cas d'usage

Vous trouverez un ensemble d'exemples d'utilisation de notre Load Balancer Public Cloud avec Managed Kubernetes Service (MKS) sur notre dépôt Github dédié : https://github.com/ovh/public-cloud-examples

Public-to-Private (votre cluster est attaché à un réseau/subnet privé)

Dans un scénario public-to-private, vous utilisez votre Load Balancer pour exposer publiquement des applications hébergées sur votre cluster Managed Kubernetes. Le principal avantage de ce scénario est que vos nœuds Kubernetes ne sont pas exposés sur Internet.

Exemple de service :

apiVersion: v1
kind: Service
metadata:
  name: my-lb-service
  namespace: test-lb-ns
  annotations:
    loadbalancer.ovhcloud.com/class: "octavia" //not required for cluster running kubernetes versions >= 1.31

    # Use `openstack loadbalancer flavor list` to get the full list of available flavors.
    # When not specified, the "small" flavor is used by default.
    loadbalancer.ovhcloud.com/flavor: medium # Name of a loadbalancer flavor, used in MKS Free ONLY.
    loadbalancer.openstack.org/flavor-id: yyy # UUID of a loadbalancer flavor, used in MKS Standard ONLY.
  labels:
    app: test-octavia
spec:
  ports:
  - name: client
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer

Private-to-Private

Dans un scénario private-to-private, votre Load Balancer n'est pas exposé publiquement ; cela peut être utile si vous souhaitez exposer votre service conteneurisé au sein de votre réseau privé OVHcloud.

Exemple de service :

apiVersion: v1
kind: Service
metadata:
  name: my-lb-service
  namespace: test-lb-ns
  annotations:
    loadbalancer.ovhcloud.com/class: "octavia" //not required for cluster running kubernetes versions >= 1.31
    service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
  labels:
    app: test-octavia
spec:
  ports:
  - name: client
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer

Public-to-Public (vous utilisez un cluster Managed Kubernetes public)

Dans un scénario public-to-public, tous vos nœuds Kubernetes disposent d'une interface réseau publique. La communication inter-nœuds/pods reposera sur le réseau public. C'est la façon la plus simple de déployer un cluster MKS, car elle ne nécessite pas la création d'une topologie de réseau et de subnet. Bien que tous vos nœuds disposent déjà d'une adresse IP publique pour exposer vos applications, vous pouvez choisir d'utiliser un loadbalancer pour les exposer derrière une adresse IP unique.

Exemple de service :

apiVersion: v1
kind: Service
metadata:
  name: my-lb-service
  namespace: test-lb-ns
  annotations:
    loadbalancer.ovhcloud.com/class: "octavia" //not required for cluster running kubernetes versions >= 1.31

    # Use `openstack loadbalancer flavor list` to get the full list of available flavors.
    # When not specified, the "small" flavor is used by default.
    loadbalancer.ovhcloud.com/flavor: medium # Name of a loadbalancer flavor, used in MKS Free ONLY.
    loadbalancer.openstack.org/flavor-id: yyy # UUID of a loadbalancer flavor, used in MKS Standard ONLY.
  labels:
    app: test-octavia
spec:
  ports:
  - name: client
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer

Annotations et fonctionnalités prises en charge

Annotations de service prises en charge

• loadbalancer.ovhcloud.com/class

Valeurs autorisées : octavia = Load Balancer Public Cloud, iolb = Loadbalancer for Managed Kubernetes Service (sera dépréciée dans les prochaines versions). Si elle n'est pas spécifiée, la classe par défaut de la version de Kubernetes MKS que vous utilisez sera appliquée ; reportez-vous à la section sur la matrice des versions.

• loadbalancer.ovhcloud.com/flavor (MKS Free uniquement)

  Il ne s'agit pas d'une annotation OpenStack Octavia standard (elle est spécifique à OVHcloud). Il s'agit de la taille utilisée pour créer le loadbalancer. Les spécifications sont disponibles sur la page spécifications du Load Balancer. Valeurs autorisées => small,medium,large, xl. La valeur par défaut est small.

• loadbalancer.openstack.org/flavor-id (MKS Standard uniquement)

  L'UUID de la flavor utilisée pour créer le loadbalancer. Pour obtenir les UUID des flavors, consultez les guides suivants :

  • Préparer l'environnement pour utiliser l'API OpenStack ;
  • Charger les variables d'environnement OpenStack.
  • Exécutez openstack loadbalancer flavor list pour obtenir la liste des flavors et leurs UUID.

• service.beta.kubernetes.io/openstack-internal-load-balancer

  Si true, le loadbalancer disposera uniquement d'une IP sur le réseau privé (aucune Floating IP n'est associée au Load Balancer). La valeur par défaut est false.

• loadbalancer.openstack.org/subnet-id

  Le subnet ID à partir duquel l'IP privée du load balancer sera récupérée. Par défaut, le subnet-id du subnet configuré pour votre cluster OVHcloud Managed Kubernetes Service sera utilisé.

• loadbalancer.openstack.org/member-subnet-id

  Le subnet ID membre du load balancer créé. Par défaut, le subnet-id du subnet configuré pour votre cluster OVHcloud Managed Kubernetes Service sera utilisé.

• loadbalancer.openstack.org/network-id

  Le network ID qui allouera l'IP virtuelle pour le loadbalancer. Par défaut, le network-id du réseau configuré pour votre cluster OVHcloud Managed Kubernetes Service sera utilisé.

• loadbalancer.openstack.org/port-id

  Le port ID pour l'IP privée du load balancer. Peut être utilisé si vous souhaitez utiliser une IP privée spécifique.

• loadbalancer.openstack.org/connection-limit

  Le nombre maximal de connexions par seconde autorisées pour le listener. Entier positif, ou -1 pour illimité (valeur par défaut). Cette annotation prend en charge les opérations de mise à jour.

• loadbalancer.openstack.org/keep-floatingip

  Si true, la Floating IP ne sera PAS supprimée lors de la suppression du load balancer. La valeur par défaut est false. Utile si vous souhaitez conserver votre Floating IP après la suppression du Load Balancer.

• loadbalancer.openstack.org/proxy-protocol

  Active le ProxyProtocol sur tous les listeners. La valeur par défaut est false.

Valeurs :

• v1, true : active la version 1 du ProxyProtocol
• v2 : active la version 2 du ProxyProtocol

• loadbalancer.openstack.org/timeout-client-data

  Délai d'inactivité côté client frontend en millisecondes pour le load balancer. Valeur par défaut (s) = 50.

• loadbalancer.openstack.org/timeout-member-connect

  Délai de connexion des membres backend en millisecondes pour le load balancer. Valeur par défaut (s) = 5.

• loadbalancer.openstack.org/timeout-member-data

  Délai d'inactivité des membres backend en millisecondes pour le load balancer. Valeur par défaut (s) = 50.

• loadbalancer.openstack.org/timeout-tcp-inspect

  Temps d'attente pour des paquets TCP additionnels pour l'inspection du contenu, en millisecondes, pour le load balancer. Valeur par défaut (ms) = 0.

• loadbalancer.openstack.org/enable-health-monitor

  Définit s'il faut créer un health monitor pour le pool du load balancer. La valeur par défaut est true. Le health monitor peut être créé ou supprimé dynamiquement. Un health monitor est requis pour les services avec spec.externalTrafficPolicy: Local.

• loadbalancer.openstack.org/health-monitor-delay

  Définit le délai du health monitor en secondes pour les pools du loadbalancer. Valeur par défaut (ms) = 5000

• loadbalancer.openstack.org/health-monitor-timeout

  Définit le timeout du health monitor en secondes pour les pools du loadbalancer. Cette valeur doit être inférieure au délai. Valeur par défaut (ms) = 3000

• loadbalancer.openstack.org/health-monitor-max-retries

  Définit le nombre de tentatives du health monitor pour que les membres du pool du loadbalancer soient marqués comme actifs (online). Valeur par défaut = 1

• loadbalancer.openstack.org/health-monitor-max-retries-down

  Définit le nombre de tentatives du health monitor pour que les membres du pool du loadbalancer soient marqués comme inactifs (down). Valeur par défaut = 3

• loadbalancer.openstack.org/flavor-id

  L'ID de la flavor utilisée pour créer le loadbalancer : utilisé uniquement pour MKS Standard. MKS Free utilise loadbalancer.ovhcloud.com/flavor.

• loadbalancer.openstack.org/load-balancer-id

  Cette annotation est automatiquement ajoutée au Service si elle n'est pas spécifiée lors de la création. Une fois le Service créé avec succès, elle ne doit pas être modifiée, sous peine que le Service ne se comporte pas comme attendu.

  Si cette annotation est spécifiée avec un ID de load balancer cloud valide lors de la création du Service, le Service réutilise ce load balancer plutôt que d'en créer un nouveau. Plus de détails ci-dessous.

  Si cette annotation est spécifiée, les autres annotations définissant les fonctionnalités du load balancer seront ignorées.

• loadbalancer.openstack.org/hostname

  Cette annotation définit explicitement un hostname dans le statut du service de load balancer.

• loadbalancer.openstack.org/load-balancer-address

  Cette annotation est automatiquement ajoutée et contient l'adresse Floating IP du service de load balancer. Lorsque l'annotation loadbalancer.openstack.org/hostname est utilisée, c'est le seul endroit où voir l'adresse réelle du load balancer.

• loadbalancer.openstack.org/lb-method

  Cette annotation configure l'algorithme de répartition de charge à utiliser pour distribuer les nouvelles connexions. Algorithme par défaut : ROUND_ROBIN Autres algorithmes disponibles : LEAST_CONNECTIONS, SOURCE_IP

Annotations non prises en charge

• loadbalancer.openstack.org/availability-zone

  Le nom de l'availability zone du loadbalancer à utiliser. Elle est ignorée si la version d'Octavia ne prend pas encore en charge les availability zones.

• loadbalancer.openstack.org/x-forwarded-for

  Si vous souhaitez effectuer de la répartition de charge de niveau 7 (Layer 7), nous vous recommandons d'utiliser l'Ingress-controller Octavia officiel : https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/octavia-ingress-controller/using-octavia-ingress-controller.md

Fonctionnalités

Redimensionner votre LoadBalancer

Il n'existe pas encore de méthode adaptée pour redimensionner « à chaud » votre loadbalancer (travail en cours). La meilleure alternative pour changer la flavor de votre load balancer consiste à recréer un nouveau Service Kubernetes qui utilisera la même IP publique qu'un service existant. Vous trouverez le tutoriel complet et des exemples sur notre dépôt Github public : https://github.com/ovh/public-cloud-examples/tree/main/containers-orchestration/managed-kubernetes/use-public-cloud-load-balancer.

• Assurez-vous d'abord que le service existant utilise l'annotation loadbalancer.openstack.org/keep-floatingip. Si ce n'est pas le cas, la Floating IP publique sera libérée (elle peut être ajoutée après la création du service).
• Récupérez l'IP publique de votre service existant :

$ kubectl get service my-small-lb
NAME                 TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
test-lb-todel        LoadBalancer   10.3.107.18   141.94.215.240   80:30172/TCP   12m

• Créez un nouveau service avec la nouvelle flavor souhaitée :

  apiVersion: v1
  kind: Service
  metadata:
    name: my-medium-lb
    annotations:
      loadbalancer.ovhcloud.com/class: "octavia" # not required for clusters running kubernetes versions >= 1.31

      # Use `openstack loadbalancer flavor list` to get the full list of available flavors.
      loadbalancer.ovhcloud.com/flavor: medium # Name of a loadbalancer flavor, used in MKS Free ONLY.
      loadbalancer.openstack.org/flavor-id: yyy # UUID of a loadbalancer flavor, used in MKS Standard ONLY.
    labels:
      app: demo-upgrade
  spec:
    loadBalancerIP: 141.94.215.240 # Use the IP address from the previous service
    ports:
    - name: client
      port: 80
      protocol: TCP
      targetPort: 80
    selector:
      app: nginx
    type: LoadBalancer

• Jusqu'à la suppression du service précédent, ce Service ne déploiera le LoadBalancer que sans Floating IP.
• Lorsque la Floating IP devient disponible (la suppression du service LB initial libère l'IP), la Floating IP sera attachée à ce nouveau LB.

Utiliser le protocole PROXY pour préserver l'IP client

Lorsque vous exposez des services comme nginx-ingress-controller, il est courant que les informations de connexion du client doivent transiter par des serveurs proxy et des load balancers, et donc être visibles par les services backend. Connaître l'adresse IP d'origine d'un client peut être utile pour définir une langue particulière pour un site web, maintenir une liste noire d'adresses IP, ou simplement à des fins de journalisation et de statistiques. Vous pouvez suivre la documentation officielle du Cloud Controller Manager sur Comment utiliser le protocole PROXY pour préserver l'IP client.

Utiliser une Floating IP existante dans le tenant

Pour utiliser une Floating IP disponible pour votre LoadBalancer K8S, utilisez le champ .spec.loadBalancerIP pour retrouver cette Floating IP dans votre tenant.

• Si la Floating IP n'est pas trouvée, le LoadBalancer restera bloqué pendant le provisionnement.
• Si la Floating IP est déjà attribuée à un autre composant, le LoadBalancer sera provisionné. La Floating IP ne sera attribuée que lorsqu'elle deviendra disponible.

apiVersion: v1
kind: Service
metadata:
  name: octavia-keepip-with-existing-ip
  annotations:
    loadbalancer.ovhcloud.com/class: "octavia" //not required for clusters running kubernetes versions >= 1.31
    # loadbalancer.openstack.org/keep-floatingip: "true" # Useless, since the FIP was provided, the FIP will not be managed by the MKS cluster
spec:
  loadBalancerIP: 1.2.3.4
  type: LoadBalancer

Utiliser une Virtual-IP (VIP) fixe pour le LoadBalancer dans le subnet

Pour attribuer une VIP fixe au LoadBalancer dans le subnet OpenStack, vous devez créer un Port OpenStack, par exemple avec la CLI OpenStack :

openstack port create --network <network> --fixed-ip subnet=<subnet>,ip-address=10.2.3.4 my-fixed-octavia-vip

Utilisez ensuite l'annotation loadbalancer.openstack.org/port-id avec l'UUID du port OpenStack :

apiVersion: v1
kind: Service
metadata:
  name: octavia-with-fixed-vip
  annotations:
    loadbalancer.ovhcloud.com/class: "octavia"    //not required for clusters running kubernetes versions >= 1.31
    service.beta.kubernetes.io/openstack-internal-load-balancer: "true" // most of the time, your LB is private in this case (but it's not mandatory)
    loadbalancer.openstack.org/port-id: "<openstack-port-uuid>"
spec:
  type: LoadBalancer

Restreindre l'accès à un Service LoadBalancer

Pour appliquer une restriction d'IP au Service LoadBalancer K8S, vous pouvez définir le tableau .spec.loadBalancerSourceRanges avec une liste de plages CIDR.

apiVersion: v1
kind: Service
metadata:
  name: octavia-ip-restrictions
  annotations:
    loadbalancer.ovhcloud.com/class: "octavia"    //not required for clusters running kubernetes versions >= 1.31
spec:
  loadBalancerSourceRanges:
  - 1.2.3.4/32
  - 5.6.7.0/24
  type: LoadBalancer

Si aucune valeur n'est attribuée à ce spec, aucune restriction ne sera appliquée.

Partager un LoadBalancer Octavia entre plusieurs Services LoadBalancer Kubernetes

Vous pouvez partager un LoadBalancer Octavia entre jusqu'à deux Services Kubernetes. Ces Services peuvent être déployés sur différents clusters MKS (les clusters doivent être dans le même réseau).

Les services K8S doivent exposer des protocoles/ports différents (vous ne pouvez pas définir le même protocole/port sur les deux Services K8S). Partager un load balancer entre plusieurs Services (GitHub)

Pour autoriser un autre Service LoadBalancer K8S à utiliser un Octavia existant (créé via MKS ou via OpenStack), utilisez l'annotation loadbalancer.openstack.org/load-balancer-id :

apiVersion: v1
kind: Service
metadata:
  name: octavia-basic-shared
  annotations:
    loadbalancer.ovhcloud.com/class: "octavia"    //not required for clusters running kubernetes versions >= 1.31
    loadbalancer.openstack.org/load-balancer-id: "<existing-octavia-uuid>"
spec:
  type: LoadBalancer

Problèmes courants lors du déploiement d'un nouveau LoadBalancer

Network is not matching requirements for Public LoadBalancer: No GatewayIP

Lorsque vous essayez de déployer un LoadBalancer public, vous devez disposer d'un GatewayIP attribué à votre Subnet pour autoriser une FloatingIP dans votre subnet. Une fois le paramètre GatewayIP défini avec une IP valide, un routeur OpenStack sera déployé pour attacher une IP publique à votre LoadBalancer Octavia.

Error syncing load balancer: failed to ensure load balancer: Network is not matching requirement for Public LoadBalancer (no GatewayIP)

Consultez le guide : Comment définir un GatewayIP sur un Subnet OpenStack.

Si vous ne souhaitez pas déployer de routeur OpenStack dans votre subnet (par exemple, si vous gérez votre propre routeur), vous devez configurer le LoadBalancerSubnetId de votre cluster MKS. Plus d'informations ici.

Network is not matching requirements for Public LoadBalancer: Cannot deploy an OpenStack Router

Lorsque vous essayez de déployer un LoadBalancer public, vous devez disposer d'un GatewayIP attribué à votre Subnet pour autoriser une FloatingIP dans votre subnet, et ce GatewayIP doit être disponible ou attaché à un routeur OpenStack.

Error syncing load balancer: failed to ensure load balancer: Network is not matching requirement for Public LoadBalancer (cannot deploy an OpenStack Router)

Dans votre cas, le GatewayIP est déjà utilisé par autre chose et nous ne pouvons pas déployer de routeur OpenStack pour votre LoadBalancer public. Si vous n'êtes pas en mesure de libérer l'IP (par exemple, si elle est utilisée par un routeur que vous avez déployé), vous devez configurer le LoadBalancerSubnetId de votre cluster MKS. Plus d'informations ici

Convention de nommage des ressources

Lors du déploiement d'un LoadBalancer via un Service Kubernetes de type LoadBalancer, l'implémentation du Cloud Controller Manager (CCM) créera automatiquement les ressources Public Cloud (LoadBalancer, Listener, Pool, Health-monitor, Gateway, Network, Subnet, etc.). Afin d'identifier facilement ces ressources, voici les modèles de nommage :

Ressources complémentaires

• Exposer des applications à l'aide de services de type LoadBalancer
• Utiliser l'Octavia Ingress Controller
• Concepts du Load Balancer OVHcloud
• Comment surveiller votre Load Balancer Public Cloud avec Prometheus

Aller plus loin

Visitez le dépôt d'exemples Github.

Visitez notre canal Discord dédié : https://discord.gg/ovhcloud. Posez vos questions, donnez votre avis et échangez directement avec l'équipe qui développe nos services de Containers et d'Orchestration.

Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

Échangez avec notre communauté d'utilisateurs.