Esegui il deployment di un'applicazione containerizzata ad alta disponibilità

Console

1. Nel menu di navigazione, seleziona Kubernetes Engine > Cluster.

2. Fai clic su Crea cluster.

3. Nel campo Nome, specifica un nome per il cluster.

4. Seleziona la versione di Kubernetes per il cluster.

5. Seleziona la zona in cui creare il cluster.

6. Fai clic su Collega progetto e seleziona un progetto esistente da collegare al cluster. Quindi, fai clic su Salva. Puoi collegare o scollegare i progetti dopo aver creato il cluster dalla pagina Dettagli progetto. Prima di eseguire il deployment dei carichi di lavoro dei container, devi collegare un progetto al cluster.

7. Fai clic su Avanti.

8. Configura le impostazioni di rete per il cluster. Non puoi modificare queste impostazioni di rete dopo aver creato il cluster. Il protocollo Internet predefinito e unico supportato per i cluster Kubernetes è Internet Protocol versione 4 (IPv4).

   1. Specifica le dimensioni del pool di indirizzi IP del bilanciatore del carico, ad esempio 20.

   2. Seleziona il CIDR (Classless Inter-Domain Routing) del servizio da utilizzare. Ai tuoi servizi di cui è stato eseguito il deployment, come i bilanciatori del carico, vengono allocati indirizzi IP da questo intervallo.

   3. Seleziona il CIDR del pod da utilizzare. Il cluster alloca indirizzi IP da questo intervallo ai tuoi pod e alle tue VM.

   4. Fai clic su Avanti.

9. Rivedi i dettagli del pool di nodi predefinito generato automaticamente per il cluster. Fai clic su edit Modifica per modificare il pool di nodi predefinito.

10. Per creare altri node pool, seleziona Aggiungi node pool. Quando modifichi il pool di nodil predefinito o aggiungi un nuovopool di nodil, lo personalizzi con le seguenti opzioni:

    1. Assegna un nome al pool di nodi. Non puoi modificare il nome dopo aver creato il pool di nodi.
    2. Specifica il numero di nodi worker da creare nel pool di nodi.

    3. Seleziona la classe di macchine più adatta ai requisiti del tuo workload. Visualizza l'elenco delle seguenti impostazioni:

       • Tipo di macchina
       • CPU
       • Memoria

    4. Fai clic su Salva.

    5. Fai clic su Crea per creare il cluster.

11. Ripeti questi passaggi per ogni zona del tuo universo GDC. Assicurati che in ogni zona che vuoi utilizzare per la tua strategia HA sia presente un cluster Kubernetes.

API

Per creare un nuovo cluster Kubernetes utilizzando direttamente l'API, applica una risorsa personalizzata a ogni zona GDC.

1. Crea una risorsa personalizzata Cluster e implementala sul server dell'API Management per la tua zona:

   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
   

   Sostituisci quanto segue:

   • MANAGEMENT_API_SERVER: il percorso kubeconfig del server API Management zonale. Per ulteriori informazioni, vedi Passare al contesto zonale.
   • CLUSTER_NAME: il nome del cluster. Il nome del cluster non deve terminare con -system. Il suffisso -system è riservato ai cluster creati da GDC.
   • POD_CIDR: la dimensione degli intervalli di rete da cui vengono allocati gli indirizzi IP virtuali (VIP) dei pod. Se non viene configurato, viene utilizzato <x0A>il valore predefinito 21.
   • SERVICE_CIDR: la dimensione degli intervalli di rete da cui vengono allocati i VIP del servizio. Se non viene configurato, viene utilizzato il valore predefinito 23.
   • KUBERNETES_VERSION: la versione di Kubernetes del cluster, ad esempio 1.26.5-gke.2100. Per elencare le versioni di Kubernetes disponibili da configurare, consulta Elenca le versioni di Kubernetes disponibili per un cluster.
   • LOAD_BALANCER_POOL_SIZE: la dimensione dei pool di indirizzi IP non sovrapposti utilizzati dai servizi di bilanciamento del carico. Se non impostato, viene utilizzato il valore predefinito 20.
   • MACHINE_TYPE: il tipo di macchina per i nodi worker delpool di nodil. Visualizza i tipi di macchina disponibili per ciò che è disponibile per la configurazione.
   • NODE_POOL_NAME: il nome del pool di nodi.
   • NUMBER_OF_WORKER_NODES: il numero di nodi di lavoro di cui eseguire il provisioning nelpool di nodil.
   • TAINTS: le incompatibilità da applicare ai nodi di questo pool di nodi. Questo è un campo facoltativo.
   • LABELS: le etichette da applicare ai nodi di questopool di nodil. Contiene un elenco di coppie chiave-valore. Questo è un campo facoltativo.
   • GPU_PARTITION_SCHEME: lo schema di partizionamento della GPU, se esegui carichi di lavoro GPU, ad esempio mixed-2. La GPU non è partizionata se questo campo non è impostato. Per i profili GPU multi-istanza (MIG) disponibili, vedi Profili MIG supportati.

2. Ripeti il passaggio precedente per ogni zona in cui vuoi ospitare l'applicazione container per la tua strategia HA.

gdcloud

Crea un bilanciatore del carico interno che ha come target i carichi di lavoro dei pod utilizzando gcloud CLI.

Questo bilanciatore del carico interno ha come target tutti i carichi di lavoro nel progetto che corrispondono all'etichetta definita nell'oggetto Backend. La risorsa personalizzata Backend deve essere limitata a una zona.

Per creare un bilanciamento del carico interno utilizzando gcloud CLI:

1. Crea una risorsa Backend zonale in ogni zona in cui vengono eseguiti i pod per definire l'endpoint per il bilanciamento del carico interno:

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

   Sostituisci quanto segue:

   • BACKEND_NAME: il nome scelto per la risorsa di backend, ad esempio my-backend.
   • LABELS: il selettore che definisce quali endpoint tra i pod utilizzare per questa risorsa di backend, ad esempio app=web.
   • PROJECT: il nome del progetto.
   • CLUSTER_NAME: il cluster Kubernetes a cui è limitato l'ambito dei selettori definiti. Se questo campo non viene specificato, vengono selezionati tutti gli endpoint con l'etichetta indicata. Questo campo è facoltativo.
   • ZONE: la zona da utilizzare per questa chiamata. Per preimpostare il flag di zona per tutti i comandi che lo richiedono, esegui gdcloud config set core/zone ZONE. Il flag di zona è disponibile solo negli ambienti multizona. Questo campo è facoltativo.

   Ripeti questo passaggio per ogni zona del tuo universo GDC.

2. Crea una risorsa BackendService globale:

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

   Sostituisci quanto segue:

   • BACKEND_SERVICE_NAME: il nome del servizio di backend.
   • PROJECT: il nome del progetto.
   • TARGET_PORTS: un elenco separato da virgole di porte di destinazione che questo servizio di backend traduce, in cui ogni porta di destinazione specifica il protocollo, la porta nella regola di forwarding e la porta nell'istanza di backend. Puoi specificare più porte di destinazione. Questo campo deve essere nel formato protocol:port:targetport, ad esempio TCP:80:8080. Questo campo è facoltativo.

3. Aggiungi la risorsa BackendService alla risorsa Backend creata in precedenza in ogni zona:

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

   Sostituisci quanto segue:

   • BACKEND_SERVICE_NAME: il nome del servizio di backend globale.
   • ZONE: la zona del backend.
   • BACKEND_NAME: il nome del backend zonale.
   • PROJECT: il nome del progetto.

   Completa questo passaggio per ogni backend di zona che hai creato in precedenza.

4. Crea una risorsa ForwardingRule interna che definisca l'indirizzo IP virtuale (VIP) in cui è disponibile il servizio:

   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
   

   Sostituisci quanto segue:

   • FORWARDING_RULE_INTERNAL_NAME: il nome della regola di forwarding.
   • CIDR: il CIDR da utilizzare per la regola di forwarding. Questo campo è facoltativo. Se non specificato, un CIDR IPv4/32 viene riservato automaticamente dal pool di indirizzi IP globali. Specifica il nome di una risorsa Subnet nello stesso spazio dei nomi di questa regola di forwarding. Una risorsa Subnet rappresenta le informazioni su richiesta e allocazione di una subnet globale. Per ulteriori informazioni sulle risorse Subnet, vedi Gestire le subnet.
   • PROTOCOL_PORT: il protocollo e la porta da esporre nella regola di forwarding. Questo campo deve essere nel formato ip-protocol=TCP:80. La porta esposta deve essere la stessa di quella esposta dall'applicazione effettiva all'interno del container.

5. Per convalidare il bilanciamento del carico interno configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Verifica il traffico con una richiesta curl al VIP:

   1. Per ottenere il VIP assegnato, descrivi la regola di forwarding:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global
      

   2. Verifica il traffico con una richiesta curl al VIP sulla porta specificata nel campo della regola di forwarding:

      curl http://FORWARDING_RULE_VIP:PORT
      

   Sostituisci quanto segue:

   • FORWARDING_RULE_VIP: il VIP della regola di forwarding.
   • PORT: il numero di porta della regola di inoltro.

API

Crea un bilanciatore del carico interno che ha come target i carichi di lavoro dei container utilizzando l'API KRM. Questo bilanciamento del carico interno ha come target tutti i workload nel progetto che corrispondono all'etichetta definita nell'oggetto Backend. Per creare un bilanciamento del carico interno globale utilizzando l'API KRM:

1. Crea una risorsa Backend per definire gli endpoint per il bilanciamento del carico interno. Crea risorse Backend per ogni zona in cui vengono inseriti i carichi di lavoro dei container:

   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
   

   Sostituisci quanto segue:

   • MANAGEMENT_API_SERVER: il percorso kubeconfig del server API Management zonale. Per maggiori informazioni, vedi Passare a un contesto zonale.
   • PROJECT: il nome del progetto.
   • BACKEND_NAME: il nome della risorsa Backend.
   • CLUSTER_NAME: il cluster Kubernetes a cui è limitato l'ambito dei selettori definiti. Se questo campo non viene specificato, vengono selezionati tutti gli endpoint con l'etichetta indicata. Questo campo è facoltativo.
   • APP_NAME: il nome dell'applicazione container.

   Puoi utilizzare la stessa risorsa Backend per ogni zona o creare risorse Backend con set di etichette diversi per ogni zona.

2. Crea un oggetto BackendService utilizzando la risorsa Backend creata in precedenza. Assicurati di includere la risorsa 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
   

   Sostituisci quanto segue:

   • GLOBAL_API_SERVER: il percorso kubeconfig del percorso kubeconfig del server API globale.
   • PROJECT: il nome del progetto.
   • BACKEND_SERVICE_NAME: il nome scelto per la risorsa BackendService.
   • HEALTH_CHECK_NAME: il nome della risorsa HealthCheck creata in precedenza.
   • BACKEND_NAME: il nome della risorsa Backend zonale.

   • ZONE: la zona in cui risiede la risorsa Backend. Puoi specificare più backend nel campo backendRefs. Ad esempio:

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

     Il campo targetPorts è facoltativo. Questa risorsa elenca le porte che questa risorsa BackendService traduce. Se utilizzi questo oggetto, fornisci i valori per quanto segue:

   • PORT: la porta esposta dal servizio.

   • PROTOCOL: il protocollo di livello 4 a cui deve corrispondere il traffico. Sono supportati solo TCP e UDP.

   • TARGET_PORT: la porta a cui viene tradotto il valore, ad esempio 8080. Il valore non può essere ripetuto in un determinato oggetto.

     Un esempio per targetPorts potrebbe avere il seguente aspetto:

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

3. Crea una risorsa ForwardingRule interna che definisca l'indirizzo IP virtuale (VIP) in cui è disponibile il servizio.

   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
   

   Sostituisci quanto segue:

   • GLOBAL_API_SERVER: il percorso kubeconfig del percorso kubeconfig del server API globale.
   • PROJECT: il nome del progetto.
   • FORWARDING_RULE_INTERNAL_NAME: il nome scelto per la risorsa ForwardingRuleInternal.
   • CIDR: il CIDR da utilizzare per la regola di forwarding. Questo campo è facoltativo. Se non specificato, un CIDR IPv4/32 viene riservato automaticamente dal pool di indirizzi IP globali. Specifica il nome di una risorsa Subnet nello stesso spazio dei nomi di questa regola di forwarding. Una risorsa Subnet rappresenta le informazioni su richiesta e allocazione di una subnet globale. Per ulteriori informazioni sulle risorse Subnet, vedi Gestire le subnet.
   • PORT: la porta da esporre nella regola di inoltro. Utilizza il campo ports per specificare un array di porte L4 per le quali i pacchetti vengono inoltrati ai backend configurati con questa regola di inoltro. È necessario specificare almeno una porta. Utilizza il campo port per specificare un numero di porta. La porta esposta deve essere la stessa che l'applicazione effettiva espone all'interno del container.

   • PROTOCOL: il protocollo da utilizzare per la regola di forwarding, ad esempio TCP. Una voce nell'array ports deve avere il seguente aspetto:

     ports:
     - port: 80
       protocol: TCP
     

4. Per convalidare il bilanciamento del carico interno configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Verifica il traffico con una richiesta curl al VIP:

   1. Recupera il VIP:

      kubectl get forwardingruleinternal -n PROJECT
      

      L'output è simile al seguente:

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

   2. Testa il traffico con una richiesta curl al VIP sulla porta specificata nel campo della regola di forwarding:

      curl http://FORWARDING_RULE_VIP:PORT
      

      Sostituisci quanto segue:

      • FORWARDING_RULE_VIP: il VIP della regola di forwarding.
      • PORT: il numero di porta del campo nella regola di forwarding.

gdcloud

Utilizza gcloud CLI per creare un ELB globale che abbia come target tutti i carichi di lavoro nel progetto corrispondenti all'etichetta definita nell'oggetto Backend. La risorsa personalizzata Backend deve essere limitata a una zona.

1. Affinché i servizi ELB funzionino, devi configurare e applicare il tuo trasferimento di dati ProjectNetworkPolicy personalizzato nelle norme per consentire il traffico ai carichi di lavoro di questo servizio ELB. I criteri di rete controllano l'accesso ai tuoi workload, non al bilanciatore del carico stesso. Gli ELB espongono i workload alla rete dei clienti, richiedendo policy di rete esplicite per consentire il traffico esterno alla porta del workload, ad esempio 8080.

   Specifica l'indirizzo CIDR esterno per consentire il traffico ai carichi di lavoro di questo ELB:

   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
   

   Sostituisci quanto segue:

   • GLOBAL_API_SERVER: il percorso kubeconfig del percorso kubeconfig del server API globale. Se non hai ancora generato un file kubeconfig per il server API globale, consulta Generare manualmente il file kubeconfig per maggiori dettagli.
   • PROJECT: il nome del progetto.
   • CIDR: il CIDR esterno da cui deve essere accessibile l'ELB. Questo criterio è necessario perché il bilanciatore del carico esterno utilizza il ritorno diretto del server (DSR), che conserva l'indirizzo IP esterno di origine e bypassa il bilanciatore del carico sul percorso di ritorno. Per ulteriori informazioni, vedi Creare una regola firewall in entrata globale per il traffico tra organizzazioni.
   • PORT: la porta di backend sui pod dietro il bilanciatore del carico. Questo valore si trova nel campo .spec.ports[].targetPortfield del manifest della risorsa Service. Questo campo è facoltativo.

   Questa configurazione fornisce a tutte le risorse all'interno dei progetti l'accesso all'intervallo CIDR specificato.

2. Crea una risorsa Backend in ogni zona per definire l'endpoint per ELB:

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

   Sostituisci quanto segue:

   • BACKEND_NAME: il nome della risorsa di backend, ad esempio my-backend.
   • LABELS: un selettore che definisce quali endpoint tra i pod utilizzare per questa risorsa di backend, ad esempio app=web.
   • PROJECT: il nome del progetto.
   • CLUSTER_NAME: il cluster Kubernetes a cui è limitato l'ambito dei selettori definiti. Se questo campo non viene specificato, vengono selezionati tutti gli endpoint con l'etichetta indicata. Questo campo è facoltativo.
   • ZONE: la zona da utilizzare per questa chiamata. Per preimpostare il flag di zona per tutti i comandi che lo richiedono, esegui gdcloud config set core/zone ZONE. Il flag di zona è disponibile solo negli ambienti multizona. Questo campo è facoltativo.

   Puoi utilizzare la stessa risorsa Backend per ogni zona o creare risorse Backend con set di etichette diversi per ogni zona.

3. Crea una risorsa BackendService globale:

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

   Sostituisci quanto segue:

   • BACKEND_SERVICE_NAME: il nome scelto per questo servizio di backend.
   • PROJECT: il nome del progetto.
   • TARGET_PORTS: un elenco separato da virgole di porte di destinazione che questo servizio di backend traduce, dove ogni porta di destinazione specifica il protocollo, la porta nella regola di forwarding e la porta nell'istanza di backend. Puoi specificare più porte di destinazione. Questo campo deve essere nel formato protocol:port:targetport, ad esempio TCP:80:8080. Questo campo è facoltativo.
   • HEALTH_CHECK_NAME: il nome della risorsa di controllo di integrità. Questo campo è facoltativo.

4. Aggiungi la risorsa globale BackendService alla risorsa di zona Backend creata in precedenza:

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

   Completa questo passaggio per ogni backend di zona che hai creato in precedenza.

5. Crea una risorsa ForwardingRule esterna che definisce il VIP in cui è disponibile il servizio:

   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
   

   Sostituisci quanto segue:

   • FORWARDING_RULE_EXTERNAL_NAME: il nome della regola di forwardingo.
   • CIDR: il CIDR da utilizzare per la regola di forwarding. Questo campo è facoltativo. Se non specificato, un CIDR IPv4/32 viene riservato automaticamente dal pool di indirizzi IP globali. Specifica il nome di una risorsa Subnet nello stesso spazio dei nomi di questa regola di forwarding. Una risorsa Subnet rappresenta le informazioni su richiesta e allocazione di una subnet globale. Per ulteriori informazioni sulle risorse Subnet, consulta Gestire le subnet.
   • PROTOCOL_PORT: il protocollo e la porta da esporre nella regola di forwarding. Questo campo deve essere nel formato ip-protocol=TCP:80. La porta esposta deve essere la stessa che l'applicazione effettiva espone all'interno del container.
   • PROJECT: il nome del progetto.

6. Per convalidare l'ELB configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Verifica il traffico con una richiesta curl al VIP:

   1. Per ottenere il VIP assegnato, descrivi la regola di forwarding:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
      

   2. Verifica il traffico con una richiesta curl al VIP sulla porta specificata nel campo PROTOCOL_PORT della regola di forwarding:

      curl http://FORWARDING_RULE_VIP:PORT
      

      Sostituisci quanto segue:

      • FORWARDING_RULE_VIP: il VIP della regola di inoltro.
      • PORT: il numero di porta del campo PROTOCOL_PORT nella regola di forwarding.

API

Crea un ELB che abbia come target i carichi di lavoro dei pod utilizzando l'API KRM. Questo ELB ha come target tutti i workload nel progetto che corrispondono all'etichetta definita nell'oggetto Backend. Per creare un ELB a livello di zona utilizzando l'API KRM:

1. Affinché i servizi ELB funzionino, devi configurare e applicare il tuo trasferimento di dati ProjectNetworkPolicy personalizzato nelle norme per consentire il traffico ai carichi di lavoro di questo servizio ELB. I criteri di rete controllano l'accesso ai tuoi workload, non al bilanciatore del carico stesso. Gli ELB espongono i workload alla rete dei clienti, richiedendo policy di rete esplicite per consentire il traffico esterno alla porta del workload, ad esempio 8080.

   Specifica l'indirizzo CIDR esterno per consentire il traffico ai carichi di lavoro di questo ELB:

   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
   

   Sostituisci quanto segue:

   • GLOBAL_API_SERVER: il percorso kubeconfig del percorso kubeconfig del server API globale. Se non hai ancora generato un file kubeconfig per il server API globale, consulta Generare manualmente il file kubeconfig per maggiori dettagli.
   • PROJECT: il nome del progetto.
   • CIDR: il CIDR esterno da cui deve essere accessibile l'ELB. Questo criterio è necessario perché il bilanciatore del carico esterno utilizza il ritorno diretto del server (DSR), che conserva l'indirizzo IP esterno di origine e bypassa il bilanciatore del carico sul percorso di ritorno. Per ulteriori informazioni, vedi Creare una regola firewall in entrata globale per il traffico tra organizzazioni.
   • PORT: la porta di backend sui pod dietro il bilanciatore del carico. Questo valore si trova nel campo .spec.ports[].targetPortfield del manifest della risorsa Service. Questo campo è facoltativo.

2. Crea una risorsa Backend per definire gli endpoint per ELB. Crea risorse Backend per ogni zona in cui vengono inseriti i carichi di lavoro:

   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
   

   Sostituisci quanto segue:

   • MANAGEMENT_API_SERVER: il percorso kubeconfig del server API Management zonale. Se non hai ancora generato un file kubeconfig per il server API nella zona di destinazione, consulta Generare manualmente il file kubeconfig per maggiori dettagli.
   • PROJECT: il nome del progetto.
   • BACKEND_NAME: il nome della risorsa Backend.
   • CLUSTER_NAME: il cluster Kubernetes a cui è limitato l'ambito dei selettori definiti. Se questo campo non viene specificato, vengono selezionati tutti gli endpoint con l'etichetta indicata. Questo campo è facoltativo.
   • APP_NAME: il nome dell'applicazione container.

   Puoi utilizzare la stessa risorsa Backend per ogni zona o creare risorse Backend con set di etichette diversi per ogni zona.

3. Crea un oggetto BackendService utilizzando la risorsa Backend creata in precedenza:

   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
   

   Sostituisci quanto segue:

   • BACKEND_SERVICE_NAME: il nome scelto per la risorsa BackendService.
   • HEALTH_CHECK_NAME: il nome della risorsa HealthCheck creata in precedenza. Non includere questo campo se stai configurando un ELB per i workload dei pod.
   • ZONE: la zona in cui risiede la risorsa Backend. Puoi specificare più backend nel campo backendRefs. Ad esempio:

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

4. Crea una risorsa ForwardingRule esterna che definisca l'IP virtuale a cui è disponibile il servizio.

   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
   

   Sostituisci quanto segue:

   • FORWARDING_RULE_EXTERNAL_NAME: il nome scelto per la risorsa ForwardingRuleExternal.
   • CIDR: il CIDR da utilizzare per la regola di forwarding. Questo campo è facoltativo. Se non specificato, un CIDR IPv4/32 viene riservato automaticamente dal pool di indirizzi IP globali. Specifica il nome di una risorsa Subnet nello stesso spazio dei nomi di questa regola di forwarding. Una risorsa Subnet rappresenta le informazioni su richiesta e allocazione di una subnet globale. Per ulteriori informazioni sulle risorse Subnet, consulta Gestire le subnet.
   • PORT: la porta da esporre nella regola di forwarding. Utilizza il campo ports per specificare un array di porte L4 per le quali i pacchetti vengono inoltrati ai backend configurati con questa regola di forwarding. È necessario specificare almeno una porta. Utilizza il campo port per specificare un numero di porta. La porta esposta deve essere la stessa che l'applicazione effettiva espone all'interno del container.
   • PROTOCOL: il protocollo da utilizzare per la regola di forwarding, ad esempio TCP. Una voce nell'array ports deve avere il seguente aspetto:

   ports:
   - port: 80
     protocol: TCP
   

5. Per convalidare l'ELB configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Prova e testa il traffico con una richiesta curl al VIP.

   1. Recupera il VIP per il progetto:

      kubectl get forwardingruleexternal -n PROJECT
      

      L'output è simile al seguente:

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

   2. Verifica il traffico con una richiesta curl al VIP sulla porta specificata nel campo PORT della regola di forwarding:

      curl http://FORWARDING_RULE_VIP:PORT
      

      Sostituisci FORWARDING_RULE_VIP:PORT con l'indirizzo VIP e la porta della regola di forwarding, ad esempio 192.0.2.0:80.