Configurer des équilibreurs de charge internes

Les équilibreurs de charge internes (ILB) exposent les services au sein de l'organisation à partir d'un pool d'adresses IP internes attribué à l'organisation. Un service ILB n'est jamais accessible depuis un point de terminaison situé en dehors de l'organisation.

Par défaut, vous pouvez accéder aux services ILB du même projet à partir de n'importe quel cluster de l'organisation. La règle de réseau de projet par défaut ne vous permet pas d'accéder aux ressources du projet depuis l'extérieur du projet. Cette restriction s'applique également aux services ILB. Si l'administrateur de la plate-forme configure des règles de réseau de projet qui autorisent l'accès à votre projet depuis d'autres projets, le service ILB est également accessible depuis ces autres projets de la même organisation.

Avant de commencer

Pour configurer des équilibreurs de charge internes, 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 des rôles d'identité et d'accès nécessaires :

    • Demandez à l'administrateur de l'organisation IAM de vous attribuer le rôle d'administrateur de l'équilibreur de charge (load-balancer-admin).
    • Pour les ILB mondiaux, demandez à votre administrateur d'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.

  • Connaître le type de cluster hébergeant vos charges de travail. Les instructions de configuration des ILB sont différentes pour les clusters partagés et standards.

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

Vous pouvez créer des équilibreurs de charge internes globaux ou zonaux pour les clusters partagés. La portée des ILB globaux s'étend à l'ensemble d'un univers GDC. Le champ d'application des ILB 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.

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

  • Utilisez la CLI gdcloud pour créer des équilibreurs de charge internes globaux ou zonaux.
  • Utilisez l'API Networking Kubernetes Resource Model (KRM) pour créer des ILB mondiaux ou zonaux.
  • Utilisez le service Kubernetes directement dans le cluster Kubernetes. Cette méthode n'est disponible que pour les ILB 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 depuis le cluster Kubernetes.

Créer un équilibreur de charge interne zonal

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

gdcloud

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

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

Pour créer un ILB à 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'ILB :

    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 ILB est destiné à des charges de travail de pods. Si vous configurez un équilibreur de charge interne pour des charges de travail de VM, définissez le type de vérification d'état pour l'équilibreur de charge interne. 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 ILB.

  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_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 ILB 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. Créez une ressource ForwardingRule interne qui définit l'adresse IP virtuelle à laquelle le service est disponible :

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

    Remplacez les éléments suivants :

    • BACKEND_SERVICE_NAME : nom de votre service de backend.
    • FORWARDING_RULE_INTERNAL_NAME par le 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.

  6. Pour valider l'équilibreur de charge interne 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_INTERNAL_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 ILB qui cible des charges de travail de pods ou de VM à l'aide de l'API KRM. Cet ILB cible toutes les charges de travail du projet correspondant au libellé défini dans l'objet Backend.

Pour créer un ILB 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'ILB. 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.

    Vous pouvez utiliser la même ressource Backend pour chaque zone ou créer des ressources Backend avec des ensembles d'étiquettes différents pour chaque zone.

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

    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 ILB 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 ILB pour les charges de travail de pod.

  4. Créez une ressource ForwardingRule interne 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: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    Remplacez les éléments suivants :

    • FORWARDING_RULE_INTERNAL_NAME : nom choisi pour votre ressource ForwardingRuleInternal.
    • 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

  5. Pour valider l'équilibreur de charge interne 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 forwardingruleinternal -n PROJECT_NAME

      La sortie ressemble à ceci :

      NAME           BACKENDSERVICE                               CIDR              READY
ilb-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 ILB dans GDC en créant un objet Kubernetes Service de type LoadBalancer dans un cluster Kubernetes. Cet ILB ne cible que les charges de travail du cluster dans lequel l'objet Service est créé.

Pour créer un ILB avec l'objet Service, procédez comme suit :

  1. Créez un fichier YAML pour la définition Service de type LoadBalancer. Vous devez concevoir le service ILB comme interne à l'aide de l'annotation networking.gke.io/load-balancer-type: internal.

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

    apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

    Remplacez les éléments suivants :

    • ILB_SERVICE_NAME : nom du service ILB.
    • 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. Le service ILB ne peut sélectionner que les charges de travail qui se trouvent dans le même cluster que la définition Service.

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

    kubectl apply -f ILB_FILE

    Remplacez ILB_FILE par le nom du fichier de définition Service du service ILB.

    Lorsque vous créez un service ILB, il reçoit une adresse IP. Vous pouvez obtenir l'adresse IP du service ILB en consultant l'état du service :

    kubectl -n PROJECT_NAME get svc ILB_SERVICE_NAME

    Remplacez les éléments suivants :

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

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

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      10.0.0.1        1234:31930/TCP   22h

    Les champs CLUSTER-IP et EXTERNAL-IP doivent afficher la même valeur, qui correspond à l'adresse IP du service ILB. Cette adresse IP est désormais accessible depuis d'autres clusters de l'organisation, conformément aux règles de réseau de projet du projet.

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

    GDC accepte les noms DNS (Domain Name System) pour les services. Toutefois, ces noms ne fonctionnent que dans le même cluster pour les services ILB. Depuis d'autres clusters, vous devez utiliser l'adresse IP pour accéder au service ILB.

Créer un ILB global

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

gdcloud

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

Cet ILB 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 ILB à 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'ILB :

    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 ILB est destiné à des charges de travail de pods. Si vous configurez un ILB pour des charges de travail de VM, définissez une vérification de l'état'état pour l'ILB :

    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 ILB 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-zone BACKEND_ZONE \
  --backend=BACKEND_NAME \
  --project=PROJECT_NAME \
  --global

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

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

    Remplacez les éléments suivants :

    • FORWARDING_RULE_INTERNAL_NAME : nom que vous avez choisi pour la règle de transfert.
    • CIDR : 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. Si aucune valeur n'est spécifiée, un CIDR IPv4/32 est automatiquement réservé à partir du pool d'adresses IP global. Ce champ est facultatif.
    • 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.

  6. Pour valider l'équilibreur de charge interne 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_INTERNAL_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 ILB qui cible des charges de travail de pods ou de VM à l'aide de l'API KRM. Cet ILB cible toutes les charges de travail du projet correspondant au libellé défini dans l'objet Backend. Pour créer un ILB 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'ILB. 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.global.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.

    Vous pouvez utiliser la même ressource Backend pour chaque zone ou créer des ressources Backend avec des ensembles d'étiquettes différents pour chaque zone.

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

    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

    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 équilibreur de charge interne 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 ILB 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 ILB 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. Créez une ressource ForwardingRule interne 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: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    Remplacez les éléments suivants :

    • FORWARDING_RULE_INTERNAL_NAME : nom choisi pour votre ressource ForwardingRuleInternal.
    • CIDR_NAME : 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. Si aucune valeur n'est spécifiée, un CIDR IPv4/32 est automatiquement réservé à partir du pool d'adresses IP global. Ce champ est facultatif.
    • 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

  5. Pour valider l'équilibreur de charge interne 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 forwardingruleinternal -n PROJECT_NAME

      La sortie ressemble à ceci :

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

    2. Testez le trafic avec une requête curl vers 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 interne pour les clusters standards

Vous pouvez créer des ILB zonaux pour les clusters standards. Les ILB globaux ne sont pas compatibles. Le champ d'application des ILB 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.

Créez des ILB zonaux pour les clusters standards en utilisant 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éé lorsque vous utilisez le service Kubernetes directement depuis le cluster Kubernetes.

Créer un ILB zonal pour les clusters standards

Vous pouvez créer des ILB dans GDC en créant un objet Kubernetes Service de type LoadBalancer dans un cluster Kubernetes. Cet ILB ne cible que les charges de travail du cluster dans lequel l'objet Service est créé.

Pour créer un ILB avec l'objet Service, procédez comme suit :

  1. Créez un fichier YAML pour la définition Service de type LoadBalancer. Vous devez concevoir le service ILB comme interne à l'aide de l'annotation networking.gke.io/load-balancer-type: internal.

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

    apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: ILB_SERVICE_NAMESPACE
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

    Remplacez les éléments suivants :

    • ILB_SERVICE_NAME : nom du service ILB.
    • ILB_SERVICE_NAMESPACE : espace de noms 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 les pods qui serviront de 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 la spécification Service dans un fichier YAML. Remplacez le nom de fichier par ILB_FILE dans la commande suivante. Le service ILB ne peut sélectionner que les charges de travail qui se trouvent dans le même cluster que la définition Service.

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

    export KUBECONFIG=KUBECONFIG_PATH
kubectl apply -f ILB_FILE

    Remplacez les éléments suivants :

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

    Lorsque vous créez un service ILB, il reçoit une adresse IP. Vous pouvez obtenir l'adresse IP du service ILB en consultant l'état du service :

    kubectl -n ILB_SERVICE_NAMESPACE get svc ILB_SERVICE_NAME

    Remplacez les éléments suivants :

    • ILB_SERVICE_NAMESPACE : espace de noms contenant les charges de travail de backend.
    • ILB_SERVICE_NAME : nom du service ILB.
    • KUBECONFIG_PATH : chemin d'accès au fichier kubeconfig pour le cluster standard.

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

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      198.51.0.1        1234:31930/TCP   22h

    Cette adresse IP est désormais accessible depuis d'autres clusters de l'organisation, conformément aux règles de réseau du projet.

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.