Configurer des équilibreurs de charge externes

Les équilibreurs de charge externes (ELB) exposent les services pour qu'ils soient accessibles depuis l'extérieur de l'organisation à partir des adresses IP d'un pool attribuées à l'organisation à partir du pool d'adresses IP externes de l'instance.

Les adresses IP virtuelles (VIP) ELB n'entrent pas en conflit entre les organisations et sont uniques pour toutes les organisations. C'est pourquoi vous ne devez utiliser les services ELB que pour les services auxquels les clients extérieurs à l'organisation doivent accéder.

Les charges de travail exécutées au sein de l'organisation peuvent accéder aux services ELB tant que vous autorisez les charges de travail à quitter l'organisation. Ce modèle de trafic nécessite effectivement un trafic sortant de l'organisation avant de revenir au service interne.

Les instructions de configuration des ELB sont différentes pour les clusters partagés et standards.

Créer un équilibreur de charge externe pour les clusters partagés

Vous pouvez créer des ELB globaux ou zonaux. Le champ d'application des ELB globaux s'étend à un univers GDC. Le champ d'application des ELB zonaux est limité à la zone spécifiée au moment de la création. Pour en savoir plus, consultez Équilibreurs de charge globaux et zonaux.

Avant de commencer

Pour configurer les services ELB, vous devez :

• Être propriétaire du projet pour lequel vous configurez l'équilibreur de charge. Pour en savoir plus, consultez Créer un projet.
• Disposer d'une règle d'entrée ProjectNetworkPolicy (PNP) personnalisée pour autoriser le trafic vers ce service ELB. Pour en savoir plus, consultez Configurer PNP pour autoriser le trafic vers ELB.

• Disposer des rôles d'identité et d'accès nécessaires :

  • Administrateur NetworkPolicy du projet : dispose d'un accès pour gérer les règles de réseau du projet dans l'espace de noms du projet. Demandez à votre administrateur IAM de l'organisation de vous attribuer le rôle d'administrateur NetworkPolicy de projet (project-networkpolicy-admin).
  • Administrateur de l'équilibreur de charge : demandez à l'administrateur de l'organisation IAM de vous attribuer le rôle d'administrateur de l'équilibreur de charge (load-balancer-admin).
  • Administrateur d'équilibreur de charge mondial : pour les équilibreurs de charge élastiques mondiaux, demandez à l'administrateur de l'organisation IAM de vous attribuer le rôle d'administrateur d'équilibreur de charge mondial (global-load-balancer-admin). Pour en savoir plus, consultez Descriptions des rôles prédéfinis.

Configurer PNP pour autoriser le trafic vers ELB

Pour que les services ELB fonctionnent, vous devez configurer et appliquer votre propre règle d'entrée ProjectNetworkPolicy personnalisée afin d'autoriser le trafic vers les charges de travail de ce service ELB. Les règles de réseau contrôlent l'accès à vos charges de travail, et non à l'équilibreur de charge lui-même. Les ELB exposent les charges de travail à votre réseau client, ce qui nécessite des règles de réseau explicites pour autoriser le trafic externe vers le port de la charge de travail, tel que 8080.

Spécifiez l'adresse CIDR externe pour autoriser le trafic vers les charges de travail de cet ELB :

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

Remplacez les éléments suivants :

• MANAGEMENT_API_SERVER : chemin d'accès kubeconfig du serveur d'API Management. Si vous n'avez pas encore généré de fichier kubeconfig pour le serveur d'API dans votre zone cible, consultez Se connecter pour en savoir plus.
• PROJECT : nom de votre projet GDC.
• CIDR : CIDR externe à partir duquel l'ELB doit être accessible. Cette règle est requise, car l'équilibreur de charge externe utilise le retour serveur direct (DSR), qui préserve l'adresse IP externe source et contourne l'équilibreur de charge sur le chemin de retour. Pour en savoir plus, consultez Créer une règle de pare-feu d'entrée globale pour le trafic externe à l'organisation.
• PORT : port de backend sur les pods derrière l'équilibreur de charge. Cette valeur se trouve dans le champ .spec.ports[].targetPort du fichier manifeste de la ressource Service. Ce champ est facultatif.

Remarque : Cette configuration permet à toutes les ressources des projets d'accéder à la plage CIDR spécifiée.

Créez des ELB à l'aide de trois méthodes différentes dans GDC :

• Utilisez la CLI gdcloud pour créer des ELB globaux ou zonaux.
• Utilisez l'API Networking Kubernetes Resource Model (KRM) pour créer des ELB globaux ou zonaux.
• Utilisez le service Kubernetes directement dans le cluster Kubernetes. Cette méthode n'est disponible que pour les ELB zonaux.

Vous pouvez cibler des charges de travail de pods ou de VM à l'aide de l'API KRM et de la CLI gdcloud. Vous ne pouvez cibler que les charges de travail du cluster dans lequel l'objet Service est créé lorsque vous utilisez le service Kubernetes directement dans le cluster Kubernetes.

Créer un ELB zonal

Créez un ELB zonal à l'aide de la CLI gdcloud, de l'API KRM ou du service Kubernetes dans le cluster Kubernetes :

gdcloud

Créez un ELB qui cible des charges de travail de pods ou de VM à l'aide de la CLI gdcloud.

Cet ELB cible toutes les charges de travail du projet correspondant au libellé défini dans l'objet Backend.

Pour créer un ELB à l'aide de la CLI gdcloud, procédez comme suit :

1. Créez une ressource Backend pour définir le point de terminaison de l'ELB :

   gdcloud compute backends create BACKEND_NAME \
     --labels=LABELS \
     --project=PROJECT_NAME \
     --zone=ZONE \
     --cluster-name=CLUSTER_NAME
   

   Remplacez les éléments suivants :

   • BACKEND_NAME : nom que vous avez choisi pour la ressource de backend, par exemple my-backend.
   • LABELS : sélecteur définissant les points de terminaison entre les pods et les VM à utiliser pour cette ressource de backend. Exemple :app=web
   • PROJECT_NAME : nom de votre projet.
   • ZONE : zone à utiliser pour cet appel. Pour prédéfinir l'option de zone pour toutes les commandes qui l'exigent, exécutez : gdcloud config set core/zone ZONE. L'option de zone n'est disponible que dans les environnements multizones. Ce champ est facultatif.
   • CLUSTER_NAME : cluster auquel la portée des sélecteurs définis est limitée. Si ce champ n'est pas spécifié, tous les points de terminaison portant l'étiquette donnée sont sélectionnés. Ce champ est facultatif.

2. Ignorez cette étape si cet ELB est destiné aux charges de travail de pods. Si vous configurez un ELB pour des charges de travail de VM, définissez le type de vérification d'état pour l'ELB. Par exemple, pour créer une vérification d'état TCP, définissez-la comme suit :

   gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
     --check-interval=CHECK_INTERVAL \
     --healthy-threshold=HEALTHY_THRESHOLD \
     --timeout=TIMEOUT \
     --unhealthy-threshold=UNHEALTHY_THRESHOLD \
     --port=PORT \
     --zone=ZONE
   

   Remplacez les éléments suivants :

   • HEALTH_CHECK_NAME : nom que vous avez choisi pour la ressource de vérification de l'état;état, par exemple my-health-check.
   • CHECK_INTERVAL : durée en secondes entre le début d'une vérification et le début de la suivante. La valeur par défaut est 5 lorsqu'elle est omise ou définie sur 0. Il est déconseillé de définir un délai avant expiration supérieur à checkInterval.
   • HEALTHY_THRESHOLD : nombre de vérifications séquentielles qui doivent réussir pour que le point de terminaison soit considéré comme opérationnel. La valeur par défaut est 5 lorsqu'elle est omise ou définie sur 0.
   • TIMEOUT : délai d'attente en secondes avant de déclarer un échec. La valeur par défaut est 5 lorsqu'elle est omise ou définie sur 0. Il est déconseillé de définir un délai avant expiration supérieur à checkInterval.
   • UNHEALTHY_THRESHOLD : nombre de vérifications séquentielles qui doivent échouer pour que le point de terminaison soit considéré comme non opérationnel. La valeur par défaut est 2 lorsqu'elle est omise ou définie sur 0.
   • PORT : port sur lequel la vérification de l'état est effectuée. La valeur par défaut est 80. Ce champ est facultatif.
   • ZONE : zone dans laquelle vous créez cet ELB.

3. Créez une ressource BackendService et ajoutez-y la ressource Backend créée précédemment :

   gdcloud compute backend-services create BACKEND_SERVICE_NAME \
     --project=PROJECT_NAME \
     --target-ports=TARGET_PORTS \
     --zone=ZONE \
     --health-check=HEALTH_CHECK_NAME
   

   Remplacez les éléments suivants :

   • BACKEND_SERVICE_NAME : nom choisi pour ce service de backend.
   • TARGET_PORT : liste de ports cibles séparés par une virgule que ce service de backend traduit, où chaque port cible spécifie le protocole, le port sur la règle de transfert et le port sur l'instance de backend. Vous pouvez spécifier plusieurs ports cibles. Ce champ doit être au format protocol:port:targetport, par exemple TCP:80:8080. Ce champ est facultatif.
   • HEALTH_CHECK_NAME : nom de la ressource de vérification de l'état. Ce champ est facultatif. N'incluez ce champ que si vous configurez un ELB pour des charges de travail de VM.

4. Ajoutez la ressource BackendService à la ressource Backend créée précédemment :

   gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --backend=BACKEND_NAME \
     --project=PROJECT_NAME \
     --zone=ZONE
   

5. Facultatif : Utilisez l'affinité de session pour les ELB afin de vous assurer que les requêtes d'un même client sont systématiquement acheminées vers le même backend. Pour activer l'affinité de session pour les équilibreurs de charge, créez une règle de service de backend à l'aide de la commande gdcloud compute load-balancer-policy create :

    gdcloud compute load-balancer-policy create POLICY_NAME
    --session-affinity=MODE
    --selectors=RESOURCE_LABEL
   

   Remplacez les éléments suivants :

   • POLICY_NAME : nom que vous avez choisi pour la règle de service de backend.

   • MODE : mode d'affinité de session. Deux modes sont acceptés :

     • NONE : l'affinité de session est désactivée. Les requêtes sont acheminées vers n'importe quel backend disponible. Il s'agit du mode par défaut.
     • CLIENT_IP_DST_PORT_PROTO : les requêtes provenant du même tuple à quatre éléments (adresse IP source, adresse IP de destination, port de destination et protocole) sont acheminées vers le même backend.

   • RESOURCE_LABEL : sélecteur d'étiquettes qui sélectionne le service de backend auquel la ressource BackendServicePolicy est appliquée dans l'espace de noms du projet. Si plusieurs ressources BackendServicePolicy correspondent au même service de backend et qu'au moins l'une de ces règles a activé l'affinité de session, l'affinité de session pour cette ressource BackendService est activée.

6. Créez une ressource ForwardingRule externe qui définit l'adresse IP virtuelle à laquelle le service est disponible :

   gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
     --backend-service=BACKEND_SERVICE_NAME \
     --cidr=CIDR \
     --ip-protocol-port=PROTOCOL_PORT \
     --load-balancing-scheme=EXTERNAL \
     --zone=ZONE \
     --project=PROJECT_NAME
   

   Remplacez les éléments suivants :

   • BACKEND_SERVICE_NAME : nom de votre service de backend.
   • FORWARDING_RULE_EXTERNAL_NAME : nom que vous avez choisi pour la règle de transfert.
   • CIDR : ce champ est facultatif. Si aucune valeur n'est spécifiée, un CIDR IPv4/32 est automatiquement réservé à partir du pool d'adresses IP zonal. Spécifiez le nom d'une ressource Subnet dans le même espace de noms que cette règle de transfert. Une ressource Subnet représente les informations de requête et d'allocation d'un sous-réseau zonal. Pour en savoir plus sur les ressources Subnet, consultez Exemples de ressources personnalisées.
   • PROTOCOL_PORT : protocole et port à exposer sur la règle de transfert. Ce champ doit être au format ip-protocol=TCP:80. Le port exposé doit être le même que celui exposé par l'application réelle dans le conteneur.

7. Pour vérifier l'ELB configuré, confirmez la condition Ready sur chacun des objets créés. Pour obtenir l'adresse IP attribuée à l'équilibreur de charge, décrivez la règle de transfert :

   gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
   

8. Pour valider l'ELB configuré, confirmez la condition Ready sur chacun des objets créés. Vérifiez le trafic avec une requête curl vers l'adresse IPV :

   1. Pour obtenir l'adresse IP virtuelle attribuée, décrivez la règle de transfert :

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
      

   2. Vérifiez le trafic en envoyant une requête curl à l'adresse IP virtuelle sur le port spécifié dans le champ PROTOCOL_PORT de la règle de transfert :

      curl http://FORWARDING_RULE_VIP:PORT
      

      Remplacez les éléments suivants :

      • FORWARDING_RULE_VIP : adresse IP virtuelle de la règle de transfert.
      • PORT : numéro de port du champ PROTOCOL_PORT dans la règle de transfert.

API

Créez un ELB qui cible des charges de travail de pods ou de VM à l'aide de l'API KRM. Cet ELB cible toutes les charges de travail du projet correspondant au libellé défini dans l'objet Backend.

Pour créer un ELB zonal à l'aide de l'API KRM, procédez comme suit :

1. Créez une ressource Backend pour définir les points de terminaison de l'ELB. Créez des ressources Backend pour chaque zone dans laquelle les charges de travail sont placées :

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: Backend
   metadata:
     namespace: PROJECT_NAME
     name: BACKEND_NAME
   spec:
     clusterName: CLUSTER_NAME
     endpointsLabels:
       matchLabels:
         app: server
   EOF
   

   Remplacez les éléments suivants :

   • MANAGEMENT_API_SERVER : chemin d'accès kubeconfig du serveur d'API Management zonal. Pour en savoir plus, consultez Passer à un contexte zonal.
   • PROJECT_NAME : nom de votre projet.
   • BACKEND_NAME : le nom de la ressource Backend.
   • CLUSTER_NAME : ce champ est facultatif. Ce champ spécifie le cluster auquel la portée des sélecteurs définis est limitée. Ce champ ne s'applique pas aux charges de travail de VM. Si une ressource Backend n'inclut pas le champ clusterName, les libellés spécifiés s'appliquent à toutes les charges de travail du projet.

2. Ignorez cette étape si cet ELB est destiné aux charges de travail de pods. Si vous configurez un ELB pour des charges de travail de VM, définissez une vérification de l'état'état pour l'ELB :

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: HealthCheck
   metadata:
     namespace: PROJECT_NAME
     name: HEALTH_CHECK_NAME
   spec:
     tcpHealthCheck:
       port: PORT
     timeoutSec: TIMEOUT
     checkIntervalSec: CHECK_INTERVAL
     healthyThreshold: HEALTHY_THRESHOLD
     unhealthyThreshold: UNHEALTHY_THRESHOLD
   EOF
   

   Remplacez les éléments suivants :

   • HEALTH_CHECK_NAME : nom que vous avez choisi pour la ressource de vérification de l'état;état, par exemple my-health-check.
   • PORT : port sur lequel la vérification de l'état est effectuée. La valeur par défaut est 80.
   • TIMEOUT : délai d'attente en secondes avant de déclarer un échec. La valeur par défaut est 5 lorsqu'elle est omise ou définie sur 0. Il est déconseillé de définir un délai avant expiration supérieur à checkInterval.
   • CHECK_INTERVAL : durée en secondes entre le début d'une vérification et le début de la suivante. La valeur par défaut est 5 lorsqu'elle est omise ou définie sur 0. Il est déconseillé de définir un délai avant expiration supérieur à checkInterval.
   • HEALTHY_THRESHOLD : nombre de vérifications séquentielles qui doivent réussir pour que le point de terminaison soit considéré comme opérationnel. La valeur par défaut est 2 lorsqu'elle est omise ou définie sur 0.
   • UNHEALTHY_THRESHOLD : nombre de vérifications séquentielles qui doivent échouer pour que le point de terminaison soit considéré comme non opérationnel. La valeur par défaut est 2 lorsqu'elle est omise ou définie sur 0.

3. Créez un objet BackendService à l'aide de la ressource Backend créée précédemment. Si vous configurez un ELB pour des charges de travail de VM, incluez la ressource HealthCheck.

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: BackendService
   metadata:
     namespace: PROJECT_NAME
     name: BACKEND_SERVICE_NAME
   spec:
     backendRefs:
     - name: BACKEND_NAME
     healthCheckName: HEALTH_CHECK_NAME
   EOF
   

   Remplacez les éléments suivants :

   • BACKEND_SERVICE_NAME : nom choisi pour votre ressource BackendService.
   • HEALTH_CHECK_NAME : nom de la ressource HealthCheck que vous avez créée précédemment. N'incluez pas ce champ si vous configurez un ELB pour les charges de travail de pod.

4. Facultatif : Utilisez l'affinité de session pour les ELB afin de vous assurer que les requêtes d'un même client sont systématiquement acheminées vers le même backend. Pour activer l'affinité de session pour les équilibreurs de charge, créez une ressource BackendServicePolicy. Cette ressource définit les paramètres d'affinité de session et applique la ressource BackendServicePolicy à la ressource BackendService. Créez et appliquez la ressource BackendServicePolicy :

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
    apiVersion: networking.global.gdc.goog/v1
    kind: BackendServicePolicy
    metadata:
        namespace: PROJECT_NAME
        name: POLICY_NAME
    spec:
        sessionAffinity: MODE
        selector:
            matchLabels:
              RESOURCE_LABEL
   

   Remplacez les éléments suivants :

   • POLICY_NAME : nom que vous avez choisi pour la règle de service de backend.

   • MODE : mode d'affinité de session. Deux modes sont acceptés :

     • NONE : l'affinité de session est désactivée. Les requêtes sont acheminées vers n'importe quel backend disponible. Il s'agit du mode par défaut.
     • CLIENT_IP_DST_PORT_PROTO : les requêtes provenant du même tuple à quatre éléments (adresse IP source, adresse IP de destination, port de destination et protocole) sont acheminées vers le même backend.

   • RESOURCE_LABEL : sélecteur d'étiquettes qui sélectionne le service de backend auquel la ressource BackendServicePolicy est appliquée dans l'espace de noms du projet. Si plusieurs ressources BackendServicePolicy correspondent au même service de backend et qu'au moins l'une de ces règles a activé l'affinité de session, l'affinité de session pour cette ressource BackendService est activée.

5. Créez une ressource ForwardingRule externe définissant l'adresse IP virtuelle à laquelle le service est disponible.

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: ForwardingRuleExternal
   metadata:
     namespace: PROJECT_NAME
     name: FORWARDING_RULE_EXTERNAL_NAME
   spec:
     cidrRef:
       name: CIDR_NAME
     ports:
     - port: PORT
       protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

   Remplacez les éléments suivants :

   • BACKEND_SERVICE_NAME : nom de votre ressource BackendService.
   • FORWARDING_RULE_EXTERNAL_NAME : nom que vous avez choisi pour votre ressource ForwardingRuleExternal.
   • CIDR_NAME : le champ cidrRef est facultatif. Si aucune valeur n'est spécifiée, un CIDR IPv4/32 est automatiquement réservé à partir du pool d'adresses IP zonal. Spécifiez le nom d'une ressource Subnet dans le même espace de noms que cette règle de transfert. Une ressource Subnet représente les informations de requête et d'allocation d'un sous-réseau zonal. Pour en savoir plus sur les ressources Subnet, consultez Exemples de ressources personnalisées.
   • PORT : utilisez le champ ports pour spécifier un tableau de ports L4 pour lesquels les paquets sont transférés vers les backends configurés avec cette règle de transfert. Vous devez spécifier au moins un port. Utilisez le champ port pour spécifier un numéro de port. Le port exposé doit être le même que celui exposé par l'application réelle dans le conteneur.

   • PROTOCOL : protocole à utiliser pour la règle de transfert, tel que TCP. Une entrée du tableau ports doit se présenter comme suit :

     ports:
     - port: 80
       protocol: TCP
     

6. Pour valider l'ELB configuré, confirmez la condition Ready sur chacun des objets créés. Vérifiez le trafic avec une requête curl vers l'adresse IPV :

   1. Pour obtenir l'adresse IP virtuelle, utilisez kubectl get :

      kubectl get forwardingruleexternal -n PROJECT_NAME
      

      La sortie ressemble à ceci :

      NAME           BACKENDSERVICE                               CIDR              READY
      elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True
      

   2. Vérifiez le trafic en envoyant une requête curl à l'adresse IP virtuelle sur le port spécifié dans le champ PORT de la règle de transfert :

      curl http://FORWARDING_RULE_VIP:PORT
      

      Remplacez FORWARDING_RULE_VIP par l'adresse IP virtuelle de la règle de transfert.

Service Kubernetes

Vous pouvez créer des ELB dans GDC en créant un Service Kubernetes de type LoadBalancer dans un cluster Kubernetes.

Pour créer un service ELB, procédez comme suit :

1. Créez un fichier YAML pour la définition Service de type LoadBalancer.

   Remarque : Contrairement au processus pour les équilibreurs de charge internes, n'ajoutez pas d'annotations au fichier. Si vous ne spécifiez pas l'annotation internal, le service est accessible de l'extérieur par défaut.

   L'objet Service suivant est un exemple de service ELB :

   apiVersion: v1
   kind: Service
   metadata:
     name: ELB_SERVICE_NAME
     namespace: PROJECT_NAME
   spec:
     ports:
     - port: 1235
       protocol: TCP
       targetPort: 1235
     selector:
       k8s-app: my-app
     type: LoadBalancer
   

   Remplacez les éléments suivants :

   • ELB_SERVICE_NAME : nom du service ELB.
   • PROJECT_NAME : espace de noms de votre projet contenant les charges de travail de backend.

   Le champ port configure le port d'interface que vous exposez sur l'adresse IP virtuelle. Le champ targetPort configure le port de backend vers lequel vous souhaitez transférer le trafic sur les charges de travail de backend. L'équilibreur de charge est compatible avec la traduction d'adresse réseau (NAT). Les ports d'interface et de backend peuvent être différents.

2. Dans le champ selector de la définition Service, spécifiez des pods ou des machines virtuelles comme charges de travail de backend.

   Le sélecteur définit les charges de travail à utiliser comme charges de travail de backend pour ce service, en fonction de la correspondance entre les étiquettes que vous spécifiez et celles des charges de travail. Le Service ne peut sélectionner que des charges de travail de backend dans le même projet et le même cluster que ceux où vous définissez le Service.

   Pour en savoir plus sur la sélection des services, consultez https://kubernetes.io/docs/concepts/services-networking/service/.

3. Enregistrez le fichier de définition Service dans le même projet que les charges de travail de backend.

4. Appliquez le fichier de définition Service au cluster :

   kubectl apply -f ELB_FILE
   

   Remplacez ELB_FILE par le nom du fichier de définition Service pour le service ELB.

   Lorsque vous créez un ELB, le service obtient deux adresses IP. L'une est une adresse IP interne accessible uniquement depuis le même cluster. L'autre est l'adresse IP externe, accessible depuis l'intérieur et l'extérieur de l'organisation. Vous pouvez obtenir les adresses IP du service ELB en consultant l'état du service :

   kubectl -n PROJECT_NAME get svc ELB_SERVICE_NAME
   

   Remplacez les éléments suivants :

   • PROJECT_NAME : espace de noms de votre projet contenant les charges de travail de backend.
   • ELB_SERVICE_NAME : nom du service ELB.

   Vous devez obtenir un résultat semblable à l'exemple suivant :

   NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
   elb-service             LoadBalancer   10.0.0.1      20.12.1.11      1235:31931/TCP   22h
   

   EXTERNAL-IP est l'adresse IP du service accessible depuis l'extérieur de l'organisation.

   Si vous n'obtenez pas de résultat, assurez-vous d'avoir bien créé le service ELB.

Créer un ELB global

Créez un ELB global à l'aide de la CLI gdcloud ou de l'API KRM.

gdcloud

Créez un ELB qui cible des charges de travail de pods ou de VM à l'aide de la CLI gdcloud.

Cet ELB cible toutes les charges de travail du projet correspondant au libellé défini dans l'objet Backend. La ressource personnalisée Backend doit être limitée à une zone.

Pour créer un ELB à l'aide de la CLI gdcloud, procédez comme suit :

1. Créez une ressource Backend pour définir le point de terminaison de l'ELB :

   gdcloud compute backends create BACKEND_NAME \
     --labels=LABELS \
     --project=PROJECT_NAME \
     --cluster-name=CLUSTER_NAME \
     --zone=ZONE
   

   Remplacez les éléments suivants :

   • BACKEND_NAME : nom que vous avez choisi pour la ressource de backend, par exemple my-backend.
   • LABELS : sélecteur définissant les points de terminaison entre les pods et les VM à utiliser pour cette ressource de backend. Exemple :app=web
   • PROJECT_NAME : nom de votre projet.
   • CLUSTER_NAME : cluster auquel la portée des sélecteurs définis est limitée. Si ce champ n'est pas spécifié, tous les points de terminaison portant l'étiquette donnée sont sélectionnés. Ce champ est facultatif.
   • ZONE : zone à utiliser pour cet appel. Pour prédéfinir l'option de zone pour toutes les commandes qui l'exigent, exécutez : gdcloud config set core/zone ZONE. L'option de zone n'est disponible que dans les environnements multizones. Ce champ est facultatif.

2. Ignorez cette étape si cet ELB est destiné aux charges de travail de pods. Si vous configurez un ELB pour des charges de travail de VM, définissez une vérification de l'état'état pour l'ELB :

   gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
     --check-interval=CHECK_INTERVAL \
     --healthy-threshold=HEALTHY_THRESHOLD \
     --timeout=TIMEOUT \
     --unhealthy-threshold=UNHEALTHY_THRESHOLD \
     --port=PORT \
     --global
   

   Remplacez les éléments suivants :

   • HEALTH_CHECK_NAME : nom que vous avez choisi pour la ressource de vérification de l'état;état, par exemple my-health-check.
   • CHECK_INTERVAL : durée en secondes entre le début d'une vérification et le début de la suivante. La valeur par défaut est 5 lorsqu'elle est omise ou définie sur 0. Il est déconseillé de définir un délai avant expiration supérieur à checkInterval.
   • HEALTHY_THRESHOLD : délai d'attente avant de déclarer un échec. La valeur par défaut est 5 lorsqu'elle est omise ou définie sur 0.
   • TIMEOUT : délai d'attente en secondes avant de déclarer un échec. La valeur par défaut est 5 lorsqu'elle est omise ou définie sur 0. Il est déconseillé de définir un délai avant expiration supérieur à checkInterval.
   • UNHEALTHY_THRESHOLD : nombre de vérifications séquentielles qui doivent échouer pour que le point de terminaison soit considéré comme non opérationnel. La valeur par défaut est 2 lorsqu'elle est omise ou définie sur 0.
   • PORT : port sur lequel la vérification de l'état est effectuée. La valeur par défaut est 80. Ce champ est facultatif.

3. Créez une ressource BackendService et ajoutez-y la ressource Backend créée précédemment :

   gdcloud compute backend-services create BACKEND_SERVICE_NAME \
     --project=PROJECT_NAME \
     --target-ports=TARGET_PORTS \
     --health-check=HEALTH_CHECK_NAME \
     --global
   

   Remplacez les éléments suivants :

   • BACKEND_SERVICE_NAME : nom choisi pour ce service de backend.
   • TARGET_PORTS : liste de ports cibles séparés par une virgule que ce service de backend traduit, où chaque port cible spécifie le protocole, le port sur la règle de transfert et le port sur l'instance de backend. Vous pouvez spécifier plusieurs ports cibles. Ce champ doit être au format protocol:port:targetport, par exemple TCP:80:8080. Ce champ est facultatif.
   • HEALTH_CHECK_NAME : nom de la ressource de vérification de l'état. Ce champ est facultatif. N'incluez ce champ que si vous configurez un ELB pour des charges de travail de VM.

4. Ajoutez la ressource BackendService à la ressource Backend créée précédemment :

   gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --backend=BACKEND_NAME \
     --backend-zone BACKEND_ZONE \
     --project=PROJECT_NAME \
     --global
   

5. Facultatif : Utilisez l'affinité de session pour les ELB afin de vous assurer que les requêtes d'un même client sont systématiquement acheminées vers le même backend. Pour activer l'affinité de session pour les équilibreurs de charge, créez une règle de service de backend à l'aide de la commande gdcloud compute load-balancer-policy create :

    gdcloud compute load-balancer-policy create POLICY_NAME
    --session-affinity=MODE
    --selectors=RESOURCE_LABEL
   

   Remplacez les éléments suivants :

   • POLICY_NAME : nom que vous avez choisi pour la règle de service de backend.

   • MODE : mode d'affinité de session. Deux modes sont acceptés :

     • NONE : l'affinité de session est désactivée. Les requêtes sont acheminées vers n'importe quel backend disponible. Il s'agit du mode par défaut.
     • CLIENT_IP_DST_PORT_PROTO : les requêtes provenant du même tuple à quatre éléments (adresse IP source, adresse IP de destination, port de destination et protocole) sont acheminées vers le même backend.

   • RESOURCE_LABEL : sélecteur d'étiquettes qui sélectionne le service de backend auquel la ressource BackendServicePolicy est appliquée dans l'espace de noms du projet. Si plusieurs ressources BackendServicePolicy correspondent au même service de backend et qu'au moins l'une de ces règles a activé l'affinité de session, l'affinité de session pour cette ressource BackendService est activée.

6. Créez une ressource ForwardingRule externe qui définit l'adresse IP virtuelle à laquelle le service est disponible :

   gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
     --backend-service=BACKEND_SERVICE_NAME \
     --cidr=CIDR \
     --ip-protocol-port=PROTOCOL_PORT \
     --load-balancing-scheme=EXTERNAL \
     --project=PROJECT_NAME \
     --global
   

   Remplacez les éléments suivants :

   • BACKEND_SERVICE_NAME : nom de votre service de backend.
   • FORWARDING_RULE_EXTERNAL_NAME : nom que vous avez choisi pour la règle de transfert.
   • CIDR : ce champ est facultatif. Si aucune valeur n'est spécifiée, un CIDR IPv4/32 est automatiquement réservé à partir du pool d'adresses IP global. Spécifiez le nom d'une ressource Subnet dans le même espace de noms que cette règle de transfert. Une ressource Subnet représente les informations de requête et d'allocation d'un sous-réseau global. Pour en savoir plus sur les ressources Subnet, consultez Exemples de ressources personnalisées.
   • PROTOCOL_PORT : protocole et port à exposer sur la règle de transfert. Ce champ doit être au format ip-protocol=TCP:80. Le port exposé doit être le même que celui exposé par l'application réelle dans le conteneur.

7. Pour vérifier l'ELB configuré, confirmez la condition Ready sur chacun des objets créés. Pour obtenir l'adresse IP attribuée à l'équilibreur de charge, décrivez la règle de transfert :

   gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
   

8. Pour valider l'ELB configuré, confirmez la condition Ready sur chacun des objets créés. Vérifiez le trafic avec une requête curl vers l'adresse IPV :

   1. Pour obtenir l'adresse IP virtuelle attribuée, décrivez la règle de transfert :

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME --global
      

   2. Vérifiez le trafic en envoyant une requête curl à l'adresse IP virtuelle sur le port spécifié dans le champ PROTOCOL_PORT de la règle de transfert :

      curl http://FORWARDING_RULE_VIP:PORT
      

      Remplacez les éléments suivants :

      • FORWARDING_RULE_VIP : adresse IP virtuelle de la règle de transfert.
      • PORT : numéro de port du champ PROTOCOL_PORT dans la règle de transfert.

API

Créez un ELB qui cible des charges de travail de pods ou de VM à l'aide de l'API KRM. Cet ELB cible toutes les charges de travail du projet correspondant au libellé défini dans l'objet Backend. Pour créer un ELB zonal à l'aide de l'API KRM, procédez comme suit :

1. Créez une ressource Backend pour définir les points de terminaison de l'ELB. Créez des ressources Backend pour chaque zone dans laquelle les charges de travail sont placées :

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: Backend
   metadata:
     namespace: PROJECT_NAME
     name: BACKEND_NAME
   spec:
     clusterName: CLUSTER_NAME
     endpointsLabels:
       matchLabels:
         app: server
   EOF
   

   Remplacez les éléments suivants :

   • MANAGEMENT_API_SERVER : chemin d'accès kubeconfig du serveur d'API Management global. Pour en savoir plus, consultez Passer au contexte global.
   • PROJECT_NAME : nom de votre projet.
   • BACKEND_NAME : le nom de la ressource Backend.
   • CLUSTER_NAME : ce champ est facultatif. Ce champ spécifie le cluster auquel la portée des sélecteurs définis est limitée. Ce champ ne s'applique pas aux charges de travail de VM. Si une ressource Backend n'inclut pas le champ clusterName, les libellés spécifiés s'appliquent à toutes les charges de travail du projet.

2. Ignorez cette étape si cet ELB est destiné aux charges de travail de pods. Si vous configurez un ELB pour des charges de travail de VM, définissez une vérification de l'état'état pour l'ELB :

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: HealthCheck
   metadata:
     namespace: PROJECT_NAME
     name: HEALTH_CHECK_NAME
   spec:
     tcpHealthCheck:
       port: PORT
     timeoutSec: TIMEOUT
     checkIntervalSec: CHECK_INTERVAL
     healthyThreshold: HEALTHY_THRESHOLD
     unhealthyThreshold: UNHEALTHY_THRESHOLD
   EOF
   

   Remplacez les éléments suivants :

   • HEALTH_CHECK_NAME : nom que vous avez choisi pour la ressource de vérification de l'état;état, par exemple my-health-check.
   • PORT : port sur lequel la vérification de l'état est effectuée. La valeur par défaut est 80.
   • TIMEOUT : délai d'attente en secondes avant de déclarer un échec. La valeur par défaut est 5 lorsqu'elle est omise ou définie sur 0. Il est déconseillé de définir un délai avant expiration supérieur à checkInterval.
   • CHECK_INTERVAL : durée en secondes entre le début d'une vérification et le début de la suivante. La valeur par défaut est 5 lorsqu'elle est omise ou définie sur 0. Il est déconseillé de définir un délai avant expiration supérieur à checkInterval.
   • HEALTHY_THRESHOLD : nombre de vérifications séquentielles qui doivent réussir pour que le point de terminaison soit considéré comme opérationnel. La valeur par défaut est 2 lorsqu'elle est omise ou définie sur 0.
   • UNHEALTHY_THRESHOLD : nombre de vérifications séquentielles qui doivent échouer pour que le point de terminaison soit considéré comme non opérationnel. La valeur par défaut est 2 lorsqu'elle est omise ou définie sur 0.

   Comme il s'agit d'un ELB global, créez la vérification de l'état dans l'API globale.

3. Créez un objet BackendService à l'aide de la ressource Backend créée précédemment. Si vous configurez un ELB pour des charges de travail de VM, incluez la ressource HealthCheck.

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: BackendService
   metadata:
     namespace: PROJECT_NAME
     name: BACKEND_SERVICE_NAME
   spec:
     backendRefs:
     - name: BACKEND_NAME
       zone: ZONE
     healthCheckName: HEALTH_CHECK_NAME
     targetPorts:
     - port: PORT
       protocol: PROTOCOL
       targetPort: TARGET_PORT
   EOF
   

   Remplacez les éléments suivants :

   • BACKEND_SERVICE_NAME : nom choisi pour votre ressource BackendService.
   • HEALTH_CHECK_NAME : nom de la ressource HealthCheck que vous avez créée précédemment. N'incluez pas ce champ si vous configurez un ELB pour les charges de travail de pod.

   • ZONE : zone dans laquelle la ressource Backend est créée. Vous pouvez spécifier plusieurs backends dans le champ backendRefs. Exemple :

     - name: my-be
       zone: Zone-A
     - name: my-be
       zone: Zone-B
     

   • Le champ targetPorts est facultatif. Cette ressource liste les ports que cette ressource BackendService traduit. Si vous utilisez cet objet, indiquez des valeurs pour les éléments suivants :

     • PORT : port exposé par le service.
     • PROTOCOL : protocole de couche 4 auquel le trafic doit correspondre. Seuls les protocoles TCP et UDP sont acceptés.

     • TARGET_PORT : port vers lequel la valeur PORT est traduite, par exemple 8080. La valeur de TARGET_PORT ne peut pas être répétée dans un objet donné. Voici un exemple pour targetPorts :

       targetPorts:
       - port: 80
         protocol: TCP
         targetPort: 8080
       

4. Facultatif : Utilisez l'affinité de session pour les ELB afin de vous assurer que les requêtes d'un même client sont systématiquement acheminées vers le même backend. Pour activer l'affinité de session pour les équilibreurs de charge, créez une ressource BackendServicePolicy. Cette ressource définit les paramètres d'affinité de session et applique la ressource BackendServicePolicy à la ressource BackendService. Créez et appliquez la ressource BackendServicePolicy :

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
    apiVersion: networking.global.gdc.goog/v1
    kind: BackendServicePolicy
    metadata:
        namespace: PROJECT_NAME
        name: POLICY_NAME
    spec:
        sessionAffinity: MODE
        selector:
            matchLabels:
              RESOURCE_LABEL
   

   Remplacez les éléments suivants :

   • POLICY_NAME : nom que vous avez choisi pour la règle de service de backend.

   • MODE : mode d'affinité de session. Deux modes sont acceptés :

     • NONE : l'affinité de session est désactivée. Les requêtes sont acheminées vers n'importe quel backend disponible. Il s'agit du mode par défaut.
     • CLIENT_IP_DST_PORT_PROTO : les requêtes provenant du même tuple à quatre éléments (adresse IP source, adresse IP de destination, port de destination et protocole) sont acheminées vers le même backend.

   • RESOURCE_LABEL : sélecteur d'étiquettes qui sélectionne le service de backend auquel la ressource BackendServicePolicy est appliquée dans l'espace de noms du projet. Si plusieurs ressources BackendServicePolicy correspondent au même service de backend et qu'au moins l'une de ces règles a activé l'affinité de session, l'affinité de session pour cette ressource BackendService est activée.

5. Créez une ressource ForwardingRule externe définissant l'adresse IP virtuelle à laquelle le service est disponible.

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ForwardingRuleExternal
   metadata:
     namespace: PROJECT_NAME
     name: FORWARDING_RULE_EXTERNAL_NAME
   spec:
     cidrRef:
       name: CIDR_NAME
     ports:
     - port: PORT
       protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

   Remplacez les éléments suivants :

   • FORWARDING_RULE_EXTERNAL_NAME : nom choisi pour votre ressource ForwardingRuleExternal.
   • CIDR_NAME : le champ cidrRef est facultatif. Si aucune valeur n'est spécifiée, un CIDR IPv4/32 est automatiquement réservé à partir du pool d'adresses IP global. Spécifiez le nom d'une ressource Subnet dans le même espace de noms que cette règle de transfert. Une ressource Subnet représente les informations de requête et d'allocation d'un sous-réseau global. Pour en savoir plus sur les ressources Subnet, consultez Exemples de ressources personnalisées.
   • PORT : utilisez le champ ports pour spécifier un tableau de ports L4 pour lesquels les paquets sont transférés vers les backends configurés avec cette règle de transfert. Vous devez spécifier au moins un port. Utilisez le champ port pour spécifier un numéro de port. Le port exposé doit être le même que celui exposé par l'application réelle dans le conteneur.

   • PROTOCOL : protocole à utiliser pour la règle de transfert, tel que TCP. Une entrée du tableau ports doit se présenter comme suit :

     ports:
     - port: 80
       protocol: TCP
     

6. Pour valider l'ELB configuré, confirmez la condition Ready sur chacun des objets créés. Vérifiez le trafic avec une requête curl vers l'adresse IPV :

   1. Pour obtenir l'adresse IP virtuelle, utilisez kubectl get :

      kubectl get forwardingruleexternal -n PROJECT_NAME
      

      La sortie ressemble à ceci :

      NAME           BACKENDSERVICE                               CIDR              READY
      elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True
      

   2. Vérifiez le trafic en envoyant une requête curl à l'adresse IP virtuelle sur le port spécifié dans le champ PORT de la règle de transfert :

      curl http://FORWARDING_RULE_VIP:PORT
      

      Remplacez FORWARDING_RULE_VIP par l'adresse IP virtuelle de la règle de transfert.

Créer un équilibreur de charge externe pour les clusters standards

Un propriétaire d'application peut créer un service Kubernetes de type LoadBalancer pour exposer des services en externe. Ce service ne peut sélectionner que les backends du cluster standard dans lequel il est créé. Cela équivaut à un ELB zonal limité au cluster. L'équilibrage de charge externe global n'est pas compatible avec les clusters standards. Pour en savoir plus, consultez Équilibreurs de charge globaux et zonaux.

Avant de commencer

Pour configurer les services ELB, vous devez :

• Être propriétaire du projet pour lequel vous configurez l'équilibreur de charge. Pour en savoir plus, consultez Créer un projet.
• Disposer d'une règle d'entrée ProjectNetworkPolicy (PNP) personnalisée pour autoriser le trafic vers ce service ELB. Pour en savoir plus, consultez Configurer PNP pour autoriser le trafic vers ELB pour les clusters standards.

• Disposer des rôles d'identité et d'accès nécessaires :

  • Administrateur de NetworkPolicy de projet : dispose d'un accès pour gérer les règles de réseau de projet dans l'espace de noms du projet. Demandez à l'administrateur de l'organisation IAM de vous accorder le rôle d'administrateur de NetworkPolicy de projet (project-networkpolicy-admin).
  • Administrateur de l'équilibreur de charge : demandez à l'administrateur de l'organisation IAM de vous attribuer le rôle d'administrateur de l'équilibreur de charge (load-balancer-admin).

Configurer PNP pour autoriser le trafic vers ELB pour les clusters standards

Pour que les services ELB fonctionnent, vous devez configurer et appliquer votre propre règle d'entrée ProjectNetworkPolicy personnalisée afin d'autoriser le trafic vers les charges de travail de ce service ELB. Les règles de réseau contrôlent l'accès à vos charges de travail, et non à l'équilibreur de charge lui-même. Les ELB exposent les charges de travail à votre réseau client, ce qui nécessite des règles de réseau explicites pour autoriser le trafic externe vers le port de la charge de travail, tel que 8080.

L'exemple de fichier YAML de règle de réseau de projet suivant autorise le trafic d'une charge de travail d'un autre projet à accéder à une charge de travail du projet actuel via l'ELB.

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-from-client-to-server
  namespace: ${VANILLA_CLUSTER_PROJECT}
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: my-sc-1
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: my-app-ns
        workloads:
          matchLabels:
            app: my-internal-app
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - "$PROJECT_2"
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: my-client
    ports:
    - protocol: TCP
      port: 8080

Créer un ELB zonal pour les clusters standards

Vous pouvez créer des ELB dans GDC en créant un Service Kubernetes de type LoadBalancer dans le cluster Kubernetes standard.

Pour créer un service ELB, procédez comme suit :

1. Créez un fichier YAML pour la définition Service de type LoadBalancer.

   Remarque : Contrairement au processus pour les équilibreurs de charge internes, n'ajoutez pas d'annotations au fichier. Si vous ne spécifiez pas l'annotation internal, le service est accessible de l'extérieur par défaut.

   L'objet Service suivant est un exemple de service ELB :

   apiVersion: v1
   kind: Service
   metadata:
     name: ELB_SERVICE_NAME
     namespace: ELB_SERVICE_NAMESPACE
   spec:
     ports:
     - port: PORT
       protocol: TCP
       targetPort: TARGET_PORT
     selector:
       k8s-app: my-app # Example selector, replace with your workload's labels
     type: LoadBalancer
   

   Remplacez les éléments suivants :

   • ELB_SERVICE_NAME : nom du service ELB.
   • ELB_SERVICE_NAMESPACE : espace de noms de votre cluster standard qui contient les charges de travail de backend.
   • PORT : port exposé par le service Kubernetes lui-même. Les autres services ou clients externes du cluster se connecteront à ce port sur l'adresse IP du service.
   • TARGET_PORT : port à l'intérieur du conteneur de votre pod où votre application s'exécute activement et écoute les connexions entrantes. Il peut s'agir d'un port numérique ou d'un port nommé défini dans la spécification du conteneur du pod.

   Le champ port configure le port d'interface que vous exposez sur l'adresse IP virtuelle. Le champ targetPort configure le port de backend vers lequel vous souhaitez transférer le trafic sur les charges de travail de backend. L'équilibreur de charge est compatible avec la traduction d'adresse réseau (NAT). Les ports d'interface et de backend peuvent être différents.

2. Dans le champ selector de la définition Service, spécifiez des paires clé/valeur correspondant aux charges de travail de backend. Pour les clusters standards, seuls les pods sont acceptés en tant que charges de travail.

   que vous définissez, en fonction de la correspondance entre les étiquettes que vous spécifiez et les étiquettes des charges de travail. Le Service ne peut sélectionner que des charges de travail de backend dans le même projet et le même cluster que ceux où vous définissez le Service.

   Pour en savoir plus sur la sélection des services, consultez https://kubernetes.io/docs/concepts/services-networking/service/.

3. Enregistrez la spécification Service dans un fichier YAML. Remplacez le nom de fichier par ELB_FILE dans la commande suivante.

4. Appliquez le fichier de définition Service au cluster :

   export KUBECONFIG=KUBECONFIG_PATH
   kubectl apply -f ELB_FILE
   

   Remplacez les éléments suivants :

   • ELB_FILE : nom du fichier de définition Service pour le service ELB.
   • KUBECONFIG_PATH : chemin d'accès au fichier kubeconfig pour le cluster standard.

   Vous pouvez obtenir les adresses IP du service ELB en consultant l'état du service :

   kubectl -n ELB_SERVICE_NAMESPACE get svc ELB_SERVICE_NAME
   

   Remplacez les éléments suivants :

   • ELB_SERVICE_NAMESPACE : espace de noms contenant les charges de travail de backend.
   • ELB_SERVICE_NAME : nom du service ELB.

   Vous devez obtenir un résultat semblable à l'exemple suivant :

   NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
   elb-service             LoadBalancer   10.0.0.1      203.0.1.11      1235:31931/TCP   22h
   

   EXTERNAL-IP est l'adresse IP du service accessible depuis l'extérieur de l'organisation.

Sélectionner une VM comme backend pour un équilibreur de charge

Pour associer une VM à l'équilibreur de charge :

1. Assurez-vous que la VM possède un libellé correspondant au sélecteur de libellé utilisé dans la configuration de l'équilibreur de charge.

   Par exemple, si votre VM ne dispose pas d'une étiquette appropriée, vous pouvez ajouter à la VM l'étiquette spécifiée à partir de l'objet de backend de la zone correspondante :

   kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL
   

   Remplacez les éléments suivants :

   • LABEL : étiquette correspondant à LabelSelector dans la configuration de l'équilibreur de charge, par exemple app=server.
   • VM_NAME : nom de la machine virtuelle associée.
   • PROJECT_NAME : nom de votre projet.

2. Assurez-vous que le serveur écoute sur le même port que celui spécifié dans l'objet HealthCheck.