Configurer des équilibreurs de charge externes

Les équilibreurs de charge externes (ELB) exposent les services pour permettre l'accès depuis l'extérieur de l'organisation à partir des adresses IP d'un pool attribué à l'organisation à partir du pool d'adresses IP externes des instances plus vaste.

Les adresses IP virtuelles (VIP) ELB ne sont pas en conflit entre les organisations et sont uniques pour toutes les organisations. Pour cette raison, vous ne devez utiliser les services ELB que pour les services auxquels les clients externes à l'organisation doivent nécessairement accéder.

Les charges de travail exécutées au sein de l'organisation peuvent accéder aux services ELB à condition que vous autorisiez 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.

Avant de commencer

Pour configurer les services ELB, vous devez disposer des éléments suivants :

  • Être propriétaire du projet pour lequel vous configurez l'équilibreur de charge. Pour en savoir plus, consultez Créer un projet.
  • 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.

  • Rôles d'identité et d'accès nécessaires :

    • Administrateur NetworkPolicy du projet : a accès à la gestion des règles réseau du projet dans l'espace de noms du projet. Demandez à votre administrateur IAM de l'organisation de vous accorder le rôle Administrateur NetworkPolicy du projet (project-networkpolicy-admin).
    • Administrateur de l'équilibreur de charge : demandez à l'administrateur IAM de votre organisation de vous attribuer le rôle Administrateur de l'équilibreur de charge (load-balancer-admin).
    • Administrateur de l'équilibreur de charge mondial : pour les ELB mondiaux, demandez à l'administrateur IAM de votre organisation de vous attribuer le rôle Administrateur de l'é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 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 kubeconfig du serveur kubeconfig de l'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 direct du serveur (DSR, Direct Server Return), 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 inter-organisations.
  • PORT : port de backend sur les pods situés 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.

Créer un équilibreur de charge externe

Vous pouvez créer des ELB globaux ou zonaux. La portée des ELB mondiaux s'étend à l'ensemble de l'univers GDC. La portée des équilibreurs de charge ELB zonaux est limitée à la zone spécifiée au moment de la création. Pour en savoir plus, consultez Équilibreurs de charge mondiaux et zonaux.

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

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

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

Créer un ELB zonal

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

gdcloud

Créez un ELB ciblant des charges de travail de pods ou de VM à l'aide de la gcloud CLI.

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 gcloud CLI, 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=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'indicateur de zone pour toutes les commandes qui en ont besoin, exécutez gdcloud config set core/zone ZONE. L'indicateur 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 le libellé indiqué sont sélectionnés. Ce champ est facultatif.

  2. Ignorez cette étape si cet ELB est destiné aux charges de travail des pods. Si vous configurez un ELB pour des charges de travail de VM, définissez une vérification de l'état l'é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 \
  --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 vérification suivante. La valeur par défaut est 5. Ce champ est facultatif.
    • HEALTHY_THRESHOLD : délai d'attente avant de signaler un échec. La valeur par défaut est 5. Ce champ est facultatif.
    • TIMEOUT : délai d'attente en secondes avant de considérer l'opération comme ayant échoué. La valeur par défaut est 5. Ce champ est facultatif.
    • UNHEALTHY_THRESHOLD : nombre de tests séquentiels qui doivent échouer pour que le point de terminaison soit considéré comme non opérationnel. La valeur par défaut est 2. Ce champ est facultatif.
    • 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. 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 les 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 équilibreurs de charge ELB afin de vous assurer que les requêtes provenant du 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 disponibles :

      • 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 quadruple (adresse IP source, adresse IP de destination, port de destination et protocole) sont acheminées vers le même backend.

    • RESOURCE_LABEL : sélecteur de libellés 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 l'affinité de session activée, 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 zonales. 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 que l'application expose réellement 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é, vérifiez la condition Ready sur chacun des objets créés. Vérifiez le trafic avec une requête curl vers l'adresse IP virtuelle :

    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 avec une requête curl adressée à la VIP au 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 les 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 du 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 kubeconfig de l'API Management zonale. 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 des pods. Si vous configurez un ELB pour des charges de travail de VM, définissez une vérification de l'état l'é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 considérer l'opération comme ayant échoué. La valeur par défaut est 5.
    • CHECK_INTERVAL : durée en secondes entre le début d'une vérification et le début de la vérification suivante. La valeur par défaut est 5.
    • HEALTHY_THRESHOLD : nombre de tests séquentiels qui doivent réussir pour que le point de terminaison soit considéré comme opérationnel. La valeur par défaut est 2.
    • UNHEALTHY_THRESHOLD : nombre de tests séquentiels qui doivent échouer pour que le point de terminaison soit considéré comme non opérationnel. La valeur par défaut est 2.

  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 équilibreurs de charge ELB afin de vous assurer que les requêtes provenant du 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 disponibles :

      • 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 quadruple (adresse IP source, adresse IP de destination, port de destination et protocole) sont acheminées vers le même backend.

    • RESOURCE_LABEL : sélecteur de libellés 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 l'affinité de session activée, 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: CIDR
  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 de votre choix pour votre ressource ForwardingRuleExternal.
    • 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 zonales. 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 de couche 4 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 que l'application réelle expose à l'intérieur du 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é, vérifiez la condition Ready sur chacun des objets créés. Vérifiez le trafic avec une requête curl vers l'adresse IP virtuelle :

    1. Pour obtenir la VIP, 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 avec une requête curl adressée à la VIP au 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 équilibreurs de charge ELB dans GDC en créant un Service Kubernetes de type LoadBalancer dans un cluster Kubernetes.

Pour créer un service ELB :

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

    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 de l'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'adresses réseau (NAT). Les ports frontend et backend peuvent être différents.

  2. Dans le champ selector de la définition Service, spécifiez les pods ou les 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 faisant correspondre les libellés que vous spécifiez avec les libellés 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 celui dans lequel vous définissez le Service.

    Pour en savoir plus sur la sélection de 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 à partir du même cluster. L'autre est l'adresse IP externe, accessible de l'intérieur et de 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 aucun résultat, assurez-vous d'avoir créé le service ELB.

Créer un ELB global

Créez un équilibreur de charge externe mondial à l'aide de la gcloud CLI ou de l'API KRM.

gdcloud

Créez un ELB ciblant des charges de travail de pods ou de VM à l'aide de la gcloud CLI.

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 gcloud CLI, 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=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 le libellé indiqué sont sélectionnés. Ce champ est facultatif.
    • ZONE : zone à utiliser pour cet appel. Pour prédéfinir l'indicateur de zone pour toutes les commandes qui en ont besoin, exécutez : gdcloud config set core/zone ZONE. L'indicateur 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 des pods. Si vous configurez un ELB pour des charges de travail de VM, définissez une vérification de l'état l'é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 vérification suivante. La valeur par défaut est 5. Ce champ est facultatif.
    • HEALTHY_THRESHOLD : délai d'attente avant de signaler un échec. La valeur par défaut est 5. Ce champ est facultatif.
    • TIMEOUT : délai d'attente en secondes avant de considérer l'opération comme ayant échoué. La valeur par défaut est 5. Ce champ est facultatif.
    • UNHEALTHY_THRESHOLD : nombre de tests séquentiels qui doivent échouer pour que le point de terminaison soit considéré comme non opérationnel. La valeur par défaut est 2. Ce champ est facultatif.
    • 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. 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 les 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 équilibreurs de charge ELB afin de vous assurer que les requêtes provenant du 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 disponibles :

      • 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 quadruple (adresse IP source, adresse IP de destination, port de destination et protocole) sont acheminées vers le même backend.

    • RESOURCE_LABEL : sélecteur de libellés 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 l'affinité de session activée, 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 mondiales. 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 demande et d'allocation d'un sous-réseau mondial. 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 que l'application expose réellement 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é, vérifiez la condition Ready sur chacun des objets créés. Vérifiez le trafic avec une requête curl vers l'adresse IP virtuelle :

    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 avec une requête curl adressée à la VIP au 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 les 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 du 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 kubeconfig du serveur kubeconfig de l'API Management globale. 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 des pods. Si vous configurez un ELB pour des charges de travail de VM, définissez une vérification de l'état l'é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 considérer l'opération comme ayant échoué. La valeur par défaut est 5.
    • CHECK_INTERVAL : durée en secondes entre le début d'une vérification et le début de la vérification suivante. La valeur par défaut est 5.
    • HEALTHY_THRESHOLD : nombre de tests séquentiels qui doivent réussir pour que le point de terminaison soit considéré comme opérationnel. La valeur par défaut est 2.
    • UNHEALTHY_THRESHOLD : nombre de tests séquentiels qui doivent échouer pour que le point de terminaison soit considéré comme non opérationnel. La valeur par défaut est 2.

    Comme il s'agit d'un équilibreur de charge 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 des 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 les valeurs suivantes :

      • 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 auquel la valeur PORT est traduite, tel que 8080. La valeur de TARGET_PORT ne peut pas être répétée dans un objet donné. Voici un exemple de fichier targetPorts :

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

  4. Facultatif : Utilisez l'affinité de session pour les équilibreurs de charge ELB afin de vous assurer que les requêtes provenant du 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 disponibles :

      • 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 quadruple (adresse IP source, adresse IP de destination, port de destination et protocole) sont acheminées vers le même backend.

    • RESOURCE_LABEL : sélecteur de libellés 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 l'affinité de session activée, 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: CIDR
  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 : 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 mondiales. 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 demande et d'allocation d'un sous-réseau mondial. 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 de couche 4 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 que l'application réelle expose à l'intérieur du 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é, vérifiez la condition Ready sur chacun des objets créés. Vérifiez le trafic avec une requête curl vers l'adresse IP virtuelle :

    1. Pour obtenir la VIP, 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 avec une requête curl adressée à la VIP au 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.