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

Console

1. Dans le menu de navigation, sélectionnez Machines virtuelles > Instances.
2. Cliquez sur Créer une instance.
3. Dans le champ Nom, spécifiez un nom pour la VM.
4. Sélectionnez la zone dans laquelle créer la VM.
5. Cliquez sur Ajouter des libellés pour attribuer des libellés à la VM et organiser ainsi vos instances de VM.
6. Sélectionnez la configuration de la machine à utiliser pour la VM. Vérifiez que le type de machine correspond à votre charge de travail, en fonction de vos besoins.
7. Cliquez sur Suivant.
8. Activez l'accès externe pour votre instance de VM.
9. Cliquez sur Suivant.
10. Sélectionnez Ajouter un disque.
11. Attribuez un nom au disque de votre VM.
12. Configurez la taille de votre disque et les paramètres de pièces jointes.
13. Cliquez sur Enregistrer.
14. Cliquez sur Créer pour créer l'instance de VM.
15. Répétez les étapes précédentes pour chaque zone de votre univers GDC. Assurez-vous qu'une instance de VM réside dans chaque zone que vous souhaitez utiliser pour votre stratégie de haute disponibilité.

gdcloud

1. Connectez-vous à la zone dans laquelle vous souhaitez héberger votre instance de VM :

   gdcloud config set core/zone ZONE
   

2. Créez l'instance de VM dans la zone à l'aide d'une image fournie par GDC :

   gdcloud compute instances create VM_NAME \
       --machine-type=MACHINE_TYPE \
       --image=BOOT_DISK_IMAGE_NAME
       --image-project=vm-system \
       --boot-disk-size=BOOT_DISK_SIZE \
       --no-boot-disk-auto-delete=NO_BOOT_DISK_AUTO_DELETE
   

   Remplacez les éléments suivants :

   • VM_NAME : nom de la nouvelle VM. Le nom ne doit contenir que des caractères alphanumériques et des tirets, et ne doit pas dépasser 53 caractères.
   • MACHINE_TYPE : type de machine prédéfini pour la nouvelle VM. Pour sélectionner un type de machine disponible, exécutez gdcloud compute machine-types list.
   • BOOT_DISK_IMAGE_NAME : nom de l'image à utiliser pour le nouveau disque de démarrage de la VM.
   • BOOT_DISK_SIZE : taille du disque de démarrage, par exemple 20GB. Cette valeur doit toujours être supérieure ou égale à la valeur minimumDiskSize de l'image de disque de démarrage.
   • NO_BOOT_DISK_AUTO_DELETE : indique si le disque de démarrage est automatiquement supprimé lorsque l'instance de VM est supprimée.

3. Répétez les étapes précédentes pour chaque zone de votre univers GDC. Assurez-vous qu'une instance de VM réside dans chaque zone que vous souhaitez utiliser pour votre stratégie de haute disponibilité.

API

1. Créez l'instance de VM dans la zone à l'aide d'une image fournie par GDC :

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: virtualmachine.gdc.goog/v1
   kind: VirtualMachineDisk
   metadata:
     name: VM_BOOT_DISK_NAME
     namespace: PROJECT
   spec:
     source:
       image:
         name: BOOT_DISK_IMAGE_NAME
         namespace: vm-system
     size: BOOT_DISK_SIZE
   ---
   apiVersion: virtualmachine.gdc.goog/v1
   kind: VirtualMachine
   metadata:
     name: VM_NAME
     namespace: PROJECT
   spec:
     compute:
       virtualMachineType: MACHINE_TYPE
     disks:
       - virtualMachineDiskRef:
           name: VM_BOOT_DISK_NAME
         boot: true
         autoDelete: BOOT_DISK_AUTO_DELETE
   ---
   apiVersion: virtualmachine.gdc.goog/v1
   kind: VirtualMachineExternalAccess
   metadata:
     name: VM_NAME
     namespace: PROJECT
   spec:
     enabled: true
     ports:
     - name: port-80
       port: 80
       protocol: TCP
   EOF
   

   Remplacez les éléments suivants :

   • MANAGEMENT_API_SERVER : fichier kubeconfig du serveur de l'API Management pour la zone dans laquelle créer l'instance de VM. Si vous n'avez pas encore généré de fichier kubeconfig pour le serveur de l'API Management, consultez Générer manuellement un fichier kubeconfig pour en savoir plus.
   • VM_BOOT_DISK_NAME : nom du nouveau disque de démarrage de la VM.
   • PROJECT : projet GDC dans lequel créer la VM.
   • BOOT_DISK_IMAGE_NAME : nom de l'image à utiliser pour le nouveau disque de démarrage de la VM.
   • BOOT_DISK_SIZE : taille du disque de démarrage, par exemple 20Gi. Cette valeur doit toujours être supérieure ou égale à la valeur minimumDiskSize de l'image de disque de démarrage.
   • VM_NAME : nom de la nouvelle VM. Le nom ne doit contenir que des caractères alphanumériques et des tirets, et ne doit pas dépasser 53 caractères.
   • MACHINE_TYPE : type de machine prédéfini pour la nouvelle VM. Pour sélectionner un type de machine disponible, exécutez gdcloud compute machine-types list.
   • BOOT_DISK_AUTO_DELETE : indique si le disque de démarrage est automatiquement supprimé lorsque l'instance de VM est supprimée.

2. Vérifiez que la VM est disponible et attendez qu'elle affiche l'état Running. L'état Running n'indique pas que l'OS est entièrement prêt et accessible.

   kubectl --kubeconfig MANAGEMENT_API_SERVER \
       get virtualmachine.virtualmachine.gdc.goog VM_NAME -n PROJECT
   

   Remplacez VM_NAME et PROJECT par le nom et le projet de la VM.

3. Répétez les étapes précédentes pour chaque zone de votre univers GDC. Assurez-vous qu'une instance de VM réside dans chaque zone que vous souhaitez utiliser pour votre stratégie de haute disponibilité.

gdcloud

Créez un équilibreur de charge interne ciblant les charges de travail 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 zonale dans chaque zone où vos VM 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 \
       --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 VM à utiliser pour cette ressource de backend, par exemple app=web.
   • PROJECT : nom de votre projet.
   • 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. Définissez une vérification de l'état globale 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 de la ressource de vérification de l'état de santé, 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 signaler un échec. 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 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 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.
   • HEALTH_CHECK_NAME : nom de la ressource de vérification de l'état. Ce champ est facultatif.

4. 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.

5. 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 identique à celui que l'application expose réellement dans la VM.

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 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 des 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 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 VM 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:
     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.
   • APP_NAME : nom de votre application VM.

   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. Définissez une vérification de l'état globale pour l'équilibreur de charge interne :

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

   • GLOBAL_API_SERVER : chemin d'accès kubeconfig du serveur d'API global. Pour en savoir plus, consultez Passer à un contexte global.
   • PROJECT : nom de votre projet.
   • HEALTH_CHECK_NAME : nom de la ressource de vérification de l'état, par exemple my-health-check.
   • PORT : port sur lequel effectuer la vérification de l'état. 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 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. 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
     

4. 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
     

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. 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 VM 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
   

   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 VM à utiliser pour cette ressource de backend, par exemple app=web.
   • PROJECT : nom de votre 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.

3. Définissez une vérification de l'état globale pour l'équilibreur de charge ELB :

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

   Remplacez les éléments suivants :

   • HEALTH_CHECK_NAME : nom de 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 signaler un échec. 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 effectuer la vérification de l'état. La valeur par défaut est 80. Ce champ est facultatif.

4. 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.

5. 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 BACKEND_ZONE \
     --project=PROJECT \
     --global
   

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

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

   gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
     --backend-service=BACKEND_SERVICE_NAME \
     --cidr=CIDR \
     --ip-protocol-port=PROTOCOL_PORT \
     --load-balancing-scheme=EXTERNAL \
     --project=PROJECT \
     --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 identique à celui que l'application réelle expose dans la VM.
   • PROJECT : nom de votre projet.

7. 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 ciblant les charges de travail des VM à l'aide de l'API KRM. Cet ELB cible toutes les charges de travail du projet correspondant au libellé défini dans l'objet Backend. Pour créer un ELB zonal à l'aide de l'API KRM, procédez comme suit :

1. 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 VM 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:
     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. 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.

   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. Définissez une vérification de l'état globale pour l'équilibreur de charge ELB :

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: HealthCheck
   metadata:
     namespace: PROJECT
     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 de la ressource de vérification de l'état;état, par exemple my-health-check.
   • PORT : port sur lequel effectuer la vérification de l'état. La valeur par défaut est 80.
   • TIMEOUT : délai d'attente en secondes avant de signaler un échec. La valeur par défaut est 5.
   • CHECK_INTERVAL : durée en secondes entre le début d'une vérification et le début de la vérification suivante. La valeur par défaut est 5.
   • HEALTHY_THRESHOLD : nombre de tests séquentiels qui doivent réussir pour que le point de terminaison soit considéré comme opérationnel. La valeur par défaut est 2.
   • UNHEALTHY_THRESHOLD : nombre de tests séquentiels qui doivent échouer pour que le point de terminaison soit considéré comme non opérationnel. La valeur par défaut est 2.

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

4. 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
   

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

6. 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.

gdcloud

1. Définissez la relation de volume de réplication asynchrone entre la zone principale et les zones secondaires :

   gdcloud compute disks start-async-replication PRIMARY_DISK_NAME \
       --project PROJECT \
       --zone PRIMARY_ZONE \
       --secondary-disk SECONDARY_DISK_NAME \
       --secondary-zone SECONDARY_ZONE
   

   Remplacez les éléments suivants :

   • PRIMARY_DISK_NAME : nom du disque source répliqué.
   • PROJECT : projet GDC du disque principal.
   • PRIMARY_ZONE : zone où se trouve le disque principal.
   • SECONDARY_DISK_NAME : nom du disque de destination à répliquer.
   • SECONDARY_ZONE : zone où doit se trouver le disque secondaire.

2. Créez une ressource personnalisée VolumeFailover dans la zone de destination, ce qui arrête la réplication vers la zone de destination si la zone source n'est pas disponible pour une raison quelconque :

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: storage.gdc.goog/v1
   kind: VolumeFailover
   metadata:
     name: FAILOVER_NAME
     namespace: PROJECT
   spec:
     volumeReplicationRelationshipRef: REPL_NAME
   EOF
   

   Remplacez les éléments suivants :

   • MANAGEMENT_API_SERVER : fichier kubeconfig pour le serveur de l'API Management.
   • FAILOVER_NAME : nom du basculement.
   • PROJECT : projet dans lequel réside l'infrastructure de stockage.
   • REPL_NAME : nom de la relation de réplication de volume.

   Pour en savoir plus sur la gestion de la réplication asynchrone pour les charges de travail de VM, consultez Répliquer des volumes de manière asynchrone.

API

1. Créez un fichier YAML de ressource personnalisée VolumeReplicationRelationship et déployez-le sur le serveur d'API global :

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: storage.global.gdc.goog/v1
   kind: VolumeReplicationRelationship
   metadata:
     name: VRR_NAME
     namespace: PROJECT
   spec:
     source:
       virtualMachineDisk:
         virtualMachineDiskRef: PRIMARY_DISK_NAME
       zoneRef: PRIMARY_ZONE
     destination:
       volumeOverrideName: SECONDARY_DISK_NAME
       zoneRef: SECONDARY_ZONE
   EOF
   

   Remplacez les éléments suivants :

   • GLOBAL_API_SERVER : fichier kubeconfig du serveur d'API de gestion globale.
   • VRR_NAME : nom de la relation de réplication de volume. Le même nom doit être utilisé pour arrêter la réplication asynchrone.
   • PROJECT : projet GDC du disque principal.
   • PRIMARY_DISK_NAME : nom du disque source répliqué.
   • PRIMARY_ZONE : zone où se trouve le disque principal.
   • SECONDARY_DISK_NAME : nom du disque de destination à répliquer.
   • SECONDARY_ZONE : zone dans laquelle le disque secondaire doit résider.

2. Créez une ressource personnalisée VolumeFailover dans la zone de destination, ce qui arrête la réplication vers la zone de destination si la zone source n'est pas disponible pour une raison quelconque :

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: storage.gdc.goog/v1
   kind: VolumeFailover
   metadata:
     name: FAILOVER_NAME
     namespace: PROJECT
   spec:
     volumeReplicationRelationshipRef: REPL_NAME
   EOF
   

   Remplacez les éléments suivants :

   • MANAGEMENT_API_SERVER : fichier kubeconfig pour le serveur de l'API Management.
   • FAILOVER_NAME : nom du basculement.
   • PROJECT : projet dans lequel réside l'infrastructure de stockage.
   • REPL_NAME : nom de la relation de réplication de volume.

Pour en savoir plus sur la gestion de la réplication asynchrone pour les charges de travail de VM, consultez Répliquer des volumes de manière asynchrone.