Déployer une application de conteneur à disponibilité élevée

Console

1. Dans le menu de navigation, sélectionnez Kubernetes Engine > Clusters.

2. Cliquez sur Créer un cluster.

3. Dans le champ Nom, spécifiez un nom pour le cluster.

4. Sélectionnez la version de Kubernetes pour le cluster.

5. Sélectionnez la zone dans laquelle créer le cluster.

6. Cliquez sur Associer un projet, puis sélectionnez un projet existant à associer à votre cluster. Cliquez ensuite sur Enregistrer. Vous pouvez associer ou dissocier des projets après avoir créé le cluster à partir de la page Détails du projet. Vous devez associer un projet à votre cluster avant de déployer des charges de travail de conteneur.

7. Cliquez sur Suivant.

8. Configurez les paramètres réseau de votre cluster. Vous ne pouvez pas modifier ces paramètres réseau après avoir créé le cluster. Le protocole Internet par défaut et unique compatible avec les clusters Kubernetes est le protocole Internet version 4 (IPv4).

   1. Spécifiez la taille du pool d'adresses IP de l'équilibreur de charge, par exemple 20.

   2. Sélectionnez le CIDR (Classless Inter-Domain Routing) du service à utiliser. Les adresses IP de vos services déployés, tels que les équilibreurs de charge, sont allouées à partir de cette plage.

   3. Sélectionnez le CIDR du pod à utiliser. Le cluster alloue des adresses IP de cette plage à vos pods et VM.

   4. Cliquez sur Suivant.

9. Consultez les détails du pool de nœuds par défaut généré automatiquement pour le cluster. Cliquez sur edit Modifier pour modifier le pool de nœuds par défaut.

10. Pour créer d'autres pools de nœuds, sélectionnez Ajouter un pool de nœuds. Lorsque vous modifiez le pool de nœuds par défaut ou que vous en ajoutez un, vous pouvez le personnaliser à l'aide des options suivantes :

    1. Attribuez un nom au pool de nœuds. Vous ne pouvez pas modifier le nom après avoir créé le pool de nœuds.
    2. Spécifiez le nombre de nœuds de calcul à créer dans le pool de nœuds.

    3. Sélectionnez la classe de machine qui correspond le mieux aux exigences de votre charge de travail. Consultez la liste des paramètres suivants :

       • Type de machine
       • Processeur
       • Mémoire

    4. Cliquez sur Enregistrer.

    5. Cliquez sur Créer pour créer le cluster.

11. Répétez ces étapes pour chaque zone de votre univers GDC. Assurez-vous qu'un cluster Kubernetes réside dans chaque zone que vous souhaitez utiliser pour votre stratégie HA.

API

Pour créer un cluster Kubernetes à l'aide de l'API, appliquez une ressource personnalisée à chaque zone GDC.

1. Créez une ressource personnalisée Cluster et déployez-la sur le serveur de l'API Management pour votre zone :

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF \
   apiVersion: cluster.gdc.goog/v1
   kind: Cluster
   metadata:
     name: CLUSTER_NAME
     namespace: platform
   spec:
     clusterNetwork:
       podCIDRSize: POD_CIDR
       serviceCIDRSize: SERVICE_CIDR
     initialVersion:
       kubernetesVersion: KUBERNETES_VERSION
     loadBalancer:
       ingressServiceIPSize: LOAD_BALANCER_POOL_SIZE
     nodePools:
     - machineTypeName: MACHINE_TYPE
       name: NODE_POOL_NAME
       nodeCount: NUMBER_OF_WORKER_NODES
       taints: TAINTS
       labels: LABELS
       acceleratorOptions:
         gpuPartitionScheme: GPU_PARTITION_SCHEME
     releaseChannel:
       channel: UNSPECIFIED
   EOF
   

   Remplacez les éléments suivants :

   • MANAGEMENT_API_SERVER : chemin kubeconfig du serveur de l'API Management zonale. Pour en savoir plus, consultez Passer au contexte zonal.
   • CLUSTER_NAME : nom du cluster. Le nom du cluster ne doit pas se terminer par -system. Le suffixe -system est réservé aux clusters créés par GDC.
   • POD_CIDR : taille des plages de réseau à partir desquelles les adresses IP virtuelles (VIP) des pods sont allouées. Si elle n'est pas définie, la valeur par défaut 21 est utilisée.
   • SERVICE_CIDR : taille des plages de réseau à partir desquelles les adresses IP virtuelles de service sont allouées. Si elle n'est pas définie, la valeur par défaut 23 est utilisée.
   • KUBERNETES_VERSION : version Kubernetes du cluster, par exemple 1.26.5-gke.2100. Pour lister les versions Kubernetes disponibles à configurer, consultez Lister les versions Kubernetes disponibles pour un cluster.
   • LOAD_BALANCER_POOL_SIZE : taille des pools d'adresses IP non chevauchants utilisés par les services d'équilibrage de charge. Si elle n'est pas définie, la valeur par défaut 20 est utilisée.
   • MACHINE_TYPE : type de machine pour les nœuds de calcul du pool de nœuds. Consultez les types de machines disponibles pour connaître les configurations possibles.
   • NODE_POOL_NAME : nom du pool de nœuds.
   • NUMBER_OF_WORKER_NODES : nombre de nœuds de calcul à provisionner dans le pool de nœuds.
   • TAINTS : rejets à appliquer aux nœuds de ce pool de nœuds. Ce champ est facultatif.
   • LABELS : libellés à appliquer aux nœuds de ce pool de nœuds. Il contient une liste de paires clé/valeur. Ce champ est facultatif.
   • GPU_PARTITION_SCHEME : schéma de partitionnement du GPU si vous exécutez des charges de travail de GPU, par exemple mixed-2. Le GPU n'est pas partitionné si ce champ n'est pas défini. Pour connaître les profils MIG (Multi-Instance GPU) disponibles, consultez Profils MIG compatibles.

2. Répétez l'étape précédente pour chaque zone dans laquelle vous souhaitez héberger votre application de conteneur pour votre stratégie de haute disponibilité.

gdcloud

Créez un équilibreur de charge interne qui cible les charges de travail de pod à 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 zonale dans chaque zone où vos pods sont en cours d'exécution pour définir le point de terminaison de l'ILB :

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

   Remplacez les éléments suivants :

   • BACKEND_NAME : nom choisi pour la ressource de backend, par exemple my-backend.
   • LABELS : sélecteur définissant les points de terminaison entre les pods à utiliser pour cette ressource de backend, par exemple app=web.
   • PROJECT : nom de votre projet.
   • CLUSTER_NAME : cluster Kubernetes 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 l'exigent, exécutez gdcloud config set core/zone ZONE. L'indicateur de zone n'est disponible que dans les environnements multizones. Ce champ est facultatif.

   Répétez cette étape pour chaque zone de votre univers GDC.

2. Créez une ressource BackendService globale :

   gdcloud compute backend-services create BACKEND_SERVICE_NAME \
       --project=PROJECT \
       --target-ports=TARGET_PORTS \
       --global
   

   Remplacez les éléments suivants :

   • BACKEND_SERVICE_NAME : nom du service de backend.
   • PROJECT : nom de votre projet.
   • 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.

3. Ajoutez la ressource BackendService à la ressource Backend précédemment créée dans chaque zone :

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

   Remplacez les éléments suivants :

   • BACKEND_SERVICE_NAME : nom du service de backend global.
   • ZONE : zone du backend.
   • BACKEND_NAME : nom du backend zonal.
   • PROJECT : nom de votre projet.

   Effectuez cette étape pour chaque backend zonal que vous avez créé précédemment.

4. Créez une ressource ForwardingRule interne qui définit l'adresse IP virtuelle (VIP) à 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 \
       --global
   

   Remplacez les éléments suivants :

   • FORWARDING_RULE_INTERNAL_NAME : nom de la règle de transfert.
   • CIDR : CIDR à utiliser pour votre règle de transfert. 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 Gérer les sous-réseaux.
   • 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 réelle expose à l'intérieur du conteneur.

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 adressée à 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 avec une requête curl à l'adresse IPV au port spécifié dans le champ 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 de la règle de transfert.

API

Créez un équilibreur de charge interne qui cible les charges de travail de conteneur à 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 mondial à 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 de conteneur sont placées :

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: Backend
   metadata:
     namespace: PROJECT
     name: BACKEND_NAME
   spec:
     clusterName: CLUSTER_NAME
     endpointsLabels:
       matchLabels:
         app: APP_NAME
   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 : nom de votre projet.
   • BACKEND_NAME : nom de la ressource Backend.
   • CLUSTER_NAME : cluster Kubernetes 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.
   • APP_NAME : nom de votre application de conteneur.

   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. Créez un objet BackendService à l'aide de la ressource Backend créée précédemment. Veillez à inclure la ressource HealthCheck :

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: BackendService
   metadata:
     namespace: PROJECT
     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 :

   • GLOBAL_API_SERVER : chemin d'accès kubeconfig du serveur d'API global.
   • PROJECT : nom de votre projet.
   • 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.
   • BACKEND_NAME : nom de la ressource Backend zonale.

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

     - name: my-backend-1
       zone: us-east1-a
     - name: my-backend-2
       zone: us-east1-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 vers lequel la valeur est traduite, par exemple 8080. La valeur 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
     

3. Créez une ressource ForwardingRule interne définissant l'adresse IP virtuelle (VIP) à laquelle le service est disponible.

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ForwardingRuleInternal
   metadata:
     namespace: PROJECT
     name: FORWARDING_RULE_INTERNAL_NAME
   spec:
     cidrRef: CIDR
     ports:
     - port: PORT
       protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

   Remplacez les éléments suivants :

   • GLOBAL_API_SERVER : chemin d'accès kubeconfig du serveur d'API global.
   • PROJECT : nom de votre projet.
   • FORWARDING_RULE_INTERNAL_NAME : nom choisi pour votre ressource ForwardingRuleInternal.
   • CIDR : CIDR à utiliser pour votre règle de transfert. 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 Gérer les sous-réseaux.
   • PORT : port à exposer sur la règle de transfert. 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
     

4. 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 adressée à l'adresse IPV :

   1. Récupérez l'adresse IP virtuelle :

      kubectl get forwardingruleinternal -n PROJECT
      

      La sortie ressemble à ceci :

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

   2. Testez le trafic avec une requête curl à l'adresse IP virtuelle au port spécifié dans le champ 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 dans la règle de transfert.

gdcloud

Utilisez la gcloud CLI pour créer un équilibreur de charge externe global qui 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.

1. Pour que les services ELB fonctionnent, vous devez configurer et appliquer votre propre transfert de données ProjectNetworkPolicy personnalisé dans la règle 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 équilibreur de charge externe :

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.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 :

   • GLOBAL_API_SERVER : chemin d'accès kubeconfig du serveur d'API global. Si vous n'avez pas encore généré de fichier kubeconfig pour le serveur d'API global, consultez Générer manuellement un fichier kubeconfig pour en savoir plus.
   • PROJECT : nom de votre projet.
   • 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), 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-organisation.
   • PORT : port de backend sur les pods situés derrière l'équilibreur de charge. Cette valeur se trouve dans le champ .spec.ports[].targetPortfield du fichier manifeste de la ressource Service. Ce champ est facultatif.

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

2. Créez une ressource Backend dans chaque zone pour définir le point de terminaison du CLB :

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

   Remplacez les éléments suivants :

   • BACKEND_NAME : nom de la ressource de backend, par exemple my-backend.
   • LABELS : sélecteur définissant les points de terminaison entre les pods à utiliser pour cette ressource de backend, par exemple app=web.
   • PROJECT : nom de votre projet.
   • CLUSTER_NAME : cluster Kubernetes 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 l'exigent, exécutez gdcloud config set core/zone ZONE. L'indicateur de zone n'est disponible que dans les environnements multizones. Ce champ est facultatif.

   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.

3. Créez une ressource BackendService globale :

   gdcloud compute backend-services create BACKEND_SERVICE_NAME \
     --project=PROJECT \
     --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.
   • PROJECT : nom de votre projet.
   • 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.

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

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

   Effectuez cette étape pour chaque backend zonal que vous avez créé précédemment.

5. 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 \
     --global
   

   Remplacez les éléments suivants :

   • FORWARDING_RULE_EXTERNAL_NAME : nom de la règle de transfert.
   • CIDR : CIDR à utiliser pour votre règle de transfert. 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 Gérer les sous-réseaux.
   • 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.
   • PROJECT : nom de votre projet.

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 à 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 des pods à 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. Pour que les services ELB fonctionnent, vous devez configurer et appliquer votre propre transfert de données ProjectNetworkPolicy personnalisé dans la règle 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 équilibreur de charge externe :

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.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 :

   • GLOBAL_API_SERVER : chemin d'accès kubeconfig du serveur d'API global. Si vous n'avez pas encore généré de fichier kubeconfig pour le serveur d'API global, consultez Générer manuellement un fichier kubeconfig pour en savoir plus.
   • PROJECT : nom de votre projet.
   • 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), 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-organisation.
   • PORT : port de backend sur les pods situés derrière l'équilibreur de charge. Cette valeur se trouve dans le champ .spec.ports[].targetPortfield du fichier manifeste de la ressource Service. Ce champ est facultatif.

2. 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: BACKEND_NAME
   spec:
     clusterName: CLUSTER_NAME
     endpointsLabels:
       matchLabels:
         app: APP_NAME
   EOF
   

   Remplacez les éléments suivants :

   • MANAGEMENT_API_SERVER : chemin d'accès kubeconfig du serveur kubeconfig de l'API Management zonale. Si vous n'avez pas encore généré de fichier kubeconfig pour le serveur d'API dans votre zone cible, consultez Générer manuellement un fichier kubeconfig pour en savoir plus.
   • PROJECT : nom de votre projet.
   • BACKEND_NAME : le nom de la ressource Backend.
   • CLUSTER_NAME : cluster Kubernetes 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.
   • APP_NAME : nom de votre application de conteneur.

   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.

3. Créez un objet BackendService à l'aide de la ressource Backend créée précédemment :

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: BackendService
   metadata:
     namespace: PROJECT
     name: BACKEND_SERVICE_NAME
   spec:
     backendRefs:
     - name: BACKEND_NAME
       zone: ZONE
     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 des charges de travail de pod.
   • ZONE : zone dans laquelle réside la ressource Backend. Vous pouvez spécifier plusieurs backends dans le champ backendRefs. Exemple :

   - name: my-backend-1
     zone: us-east1-a
   - name: my-backend-2
     zone: us-east1-b
   

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

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ForwardingRuleExternal
   metadata:
     namespace: PROJECT
     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 : CIDR à utiliser pour votre règle de transfert. 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 Gérer les sous-réseaux.
   • PORT : port à exposer sur la règle de transfert. 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'ELB configuré, vérifiez la condition Ready sur chacun des objets créés. Essayez de tester le trafic avec une requête curl adressée à l'adresse IP virtuelle.

   1. Récupérez l'adresse IP virtuelle du projet :

      kubectl get forwardingruleexternal -n PROJECT
      

      La sortie ressemble à ceci :

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

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

      curl http://FORWARDING_RULE_VIP:PORT
      

      Remplacez FORWARDING_RULE_VIP:PORT par l'adresse IP virtuelle et le port de la règle de transfert, par exemple 192.0.2.0:80.