Configurer les é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 en dehors de l'organisation.

Par défaut, vous pouvez accéder aux services ILB dans le même projet depuis n'importe quel cluster de l'organisation. La stratégie réseau du projet par défaut ne vous permet pas d'accéder aux ressources du projet depuis l'extérieur. Cette restriction s'applique également aux services ILB. Si l'administrateur de plate-forme (PA) 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 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ôles d'identité et d'accès nécessaires :

    • Demandez à votre administrateur IAM de l'organisation de vous attribuer le rôle Administrateur de l'équilibreur de charge (load-balancer-admin).
    • Pour les équilibreurs de charge internes mondiaux, demandez à votre administrateur IAM de l'organisation de vous attribuer le rôle d'administrateur de l'équilibreur de charge mondial (global-load-balancer-admin). Pour en savoir plus, consultez Descriptions des rôles prédéfinis.

Créer un équilibreur de charge interne

Vous pouvez créer des équilibreurs de charge internes globaux ou zonaux. La portée des équilibreurs de charge internes mondiaux s'étend à l'ensemble de l'univers GDC. La portée des équilibreurs de charge internes 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 équilibreurs de charge internes à l'aide de trois méthodes différentes dans GDC :

  • Utilisez la gcloud CLI pour créer des équilibreurs de charge internes zonaux ou mondiaux.
  • Utilisez l'API Networking Kubernetes Resource Model (KRM) pour créer des équilibreurs de charge internes mondiaux ou zonaux.
  • Utilisez le service Kubernetes directement dans le cluster Kubernetes. Cette méthode n'est disponible que pour les équilibreurs de charge internes 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 à partir du cluster Kubernetes, vous ne pouvez cibler que les charges de travail du cluster dans lequel l'objet Service est créé.

Créer un équilibreur de charge interne zonal

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

gdcloud

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

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

Pour créer un équilibreur de charge interne à 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'équilibreur de charge interne :

    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 équilibreur de charge interne est destiné aux charges de travail de pod. Si vous configurez un équilibreur de charge interne pour les charges de travail des VM, définissez une vérification de l'état de l'état pour l'équilibreur de charge interne :

    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 équilibreur de charge interne.

  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. 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 équilibreur de charge interne 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. 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 de votre choix 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.

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

Pour créer un équilibreur de charge interne 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'équilibreur de charge interne. 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.

    Vous pouvez utiliser la même ressource Backend pour chaque zone ou créer des ressources Backend avec des ensembles de libellés différents pour chaque zone.

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

    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 équilibreur de charge interne pour les 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 équilibreur de charge interne 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: CIDR
  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 : 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 expose réellement 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é, 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 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 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 internes dans GDC en créant un objet Service Kubernetes de type LoadBalancer dans un cluster Kubernetes. Cet équilibreur de charge interne ne cible que les charges de travail du cluster dans lequel l'objet Service est créé.

Pour créer un équilibreur de charge interne 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 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. 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 pour le 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, à savoir l'adresse IP du service ILB. Cette adresse IP est désormais accessible depuis d'autres clusters de l'organisation, conformément aux stratégies réseau du projet.

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

    GDC est compatible avec les noms du système de noms de domaine (DNS) 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 équilibreur de charge interne global

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

gdcloud

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

Cet équilibreur de charge interne 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 équilibreur de charge interne à 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'équilibreur de charge interne :

    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 équilibreur de charge interne est destiné aux charges de travail de pod. Si vous configurez un équilibreur de charge interne pour les charges de travail des VM, définissez une vérification de l'état de l'état pour l'équilibreur de charge interne :

    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 équilibreur de charge interne 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-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 demande et d'allocation d'un sous-réseau mondial. 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 mondiales. 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 que l'application expose réellement dans le conteneur.

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

    Vous pouvez utiliser la même ressource Backend pour chaque zone ou créer des ressources Backend avec des ensembles de libellés différents pour chaque zone.

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

    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 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 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 équilibreur de charge interne pour les 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 équilibreur de charge interne 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 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. 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: CIDR
  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 : 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. Si aucune valeur n'est spécifiée, un CIDR IPv4/32 est automatiquement réservé à partir du pool d'adresses IP mondiales. Ce champ est facultatif.
    • 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

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