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

Questa pagina fornisce la strategia di deployment consigliata per creare un'applicazione di macchina virtuale (VM) solida e a disponibilità elevata (HA) in Google Distributed Cloud (GDC) air-gapped. Devi eseguire il deployment dell'applicazione VM in più zone GDC e configurare la replica asincrona dell'archiviazione in modo che l'applicazione e i relativi dati siano recuperabili in caso di downtime imprevisto o disastro locale.

Questa pagina è rivolta agli sviluppatori del gruppo di operatori di applicazioni, che sono responsabili della creazione dei carichi di lavoro delle applicazioni per la propria organizzazione. Per saperne di più, consulta la documentazione sulle audience per GDC air-gapped.

Obiettivi

  • Crea un'istanza VM con dischi di avvio collegati in due o più zone del tuo universo GDC.
  • Configura il bilanciamento del carico globale.
  • Configura la replica asincrona dello spazio di archiviazione utilizzando lo spazio di archiviazione a blocchi o lo spazio di archiviazione di oggetti.

Prima di iniziare

  • Verifica di lavorare in un universo GDC con più zone disponibili. Esegui gdcloud zones list per elencare le zone disponibili nel tuo universo. Per maggiori informazioni, vedi Elenca le zone in un universo.

  • Chiedi all'amministratore IAM dell'organizzazione di concederti i seguenti ruoli:

    • I ruoli VM per creare e gestire i carichi di lavoro delle VM.
    • I ruoli Amministratore bilanciatore del carico (load-balancer-admin) e Amministratore bilanciatore del carico globale (global-load-balancer-admin). Per creare e gestire i bilanciatori del carico, devi disporre di questi ruoli.
    • Il ruolo Amministratore globale della replica dei volumi (app-volume-replication-admin-global). Devi disporre di questo ruolo per amministrare la replica dei volumi.
    • Il ruolo Amministratore PNP globale (global-project-networkpolicy-admin). Devi disporre di questo ruolo per creare e gestire i criteri di rete del progetto tra le zone.
    • Il ruolo Amministratore globale della replica dei volumi (app-volume-replication-admin-global) per amministrare la relazione di replica dei volumi per le risorse di archiviazione a blocchi.
    • I ruoli Amministratore oggetti bucket progetto (project-bucket-object-admin) e Amministratore bucket progetto (project-bucket-admin) per creare e gestire bucket di archiviazione.

    Per ulteriori informazioni, consulta le descrizioni dei ruoli.

  • Installa e configura gcloud CLI e configura i contesti globali e di zona. Per saperne di più, vedi Gestire le risorse tra le zone.

  • Installa e configura la CLI kubectl, con i file kubeconfig appropriati impostati per il server API globale e il server API di gestione. Per saperne di più, consulta Generare manualmente il file kubeconfig.

Crea un'istanza VM in più zone

Un'istanza VM è una risorsa di zona, quindi devi creare una VM separatamente in ogni zona. Per questo esempio, creerai un'istanza VM utilizzando un'immagine del sistema operativo fornita da GDC e collegherai un disco di avvio alla VM. Per saperne di più sulla creazione di istanze VM e sull'utilizzo di immagini personalizzate, consulta Crea e avvia una VM.

Per impostazione predefinita, tutti i progetti GDC possono creare VM da immagini sistema operativo fornite da GDC.

Console

  1. Nel menu di navigazione, seleziona Virtual Machines > Instances.
  2. Fai clic su Crea istanza.
  3. Nel campo Nome, specifica un nome per la VM.
  4. Seleziona la zona in cui creare la VM.
  5. Fai clic su Aggiungi etichette per assegnare etichette alla VM per organizzare le istanze VM.
  6. Seleziona la configurazione della macchina da utilizzare per la VM. Verifica che il tipo di macchina sia in linea con il tuo carico di lavoro, in base ai requisiti.
  7. Fai clic su Avanti.
  8. Abilita l'accesso esterno per l'istanza VM.
  9. Fai clic su Avanti.
  10. Seleziona Aggiungi nuovo disco.
  11. Assegna un nome al disco della VM.
  12. Configura le dimensioni del disco e le impostazioni degli allegati.
  13. Fai clic su Salva.
  14. Fai clic su Crea per creare l'istanza VM.
  15. Ripeti i passaggi precedenti per ogni zona del tuo universo GDC. Assicurati che un'istanza VM si trovi in ogni zona che vuoi per la tua strategia di alta disponibilità.

gdcloud

  1. Accedi alla zona in cui vuoi ospitare l'istanza VM:

    gdcloud config set core/zone ZONE

  2. Crea l'istanza VM nella zona utilizzando un'immagine fornita da 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

    Sostituisci quanto segue:

    • VM_NAME: il nome della nuova VM. Il nome deve contenere solo caratteri alfanumerici e trattini e non deve superare i 53 caratteri.
    • MACHINE_TYPE: il tipo di macchina predefinita per la nuova VM. Per selezionare un tipo di macchina disponibile, esegui gdcloud compute machine-types list.
    • BOOT_DISK_IMAGE_NAME: il nome dell'immagine da utilizzare per il disco di avvio della nuova VM.
    • BOOT_DISK_SIZE: le dimensioni del disco di avvio, ad esempio 20GB. Questo valore deve essere sempre maggiore o uguale a minimumDiskSize dell'immagine del disco di avvio.
    • NO_BOOT_DISK_AUTO_DELETE: indica se il disco di avvio viene eliminato automaticamente quando viene eliminata l'istanza VM.

  3. Ripeti i passaggi precedenti per ogni zona del tuo universo GDC. Assicurati che in ogni zona che vuoi utilizzare per la tua strategia di alta disponibilità sia presente un'istanza VM.

API

  1. Crea l'istanza VM nella zona utilizzando un'immagine fornita da 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

    Sostituisci quanto segue:

    • MANAGEMENT_API_SERVER: il file kubeconfig del server Management API per la zona in cui creare l'istanza VM. Se non hai ancora generato un file kubeconfig per il server API di gestione, consulta Generare manualmente il file kubeconfig per maggiori dettagli.
    • VM_BOOT_DISK_NAME: il nome del nuovo disco di avvio della VM.
    • PROJECT: il progetto GDC in cui creare la VM.
    • BOOT_DISK_IMAGE_NAME: il nome dell'immagine da utilizzare per il disco di avvio della nuova VM.
    • BOOT_DISK_SIZE: le dimensioni del disco di avvio, ad esempio 20Gi. Questo valore deve essere sempre maggiore o uguale a minimumDiskSize dell'immagine del disco di avvio.
    • VM_NAME: il nome della nuova VM. Il nome deve contenere solo caratteri alfanumerici e trattini e non deve superare i 53 caratteri.
    • MACHINE_TYPE: il tipo di macchina predefinita per la nuova VM. Per selezionare un tipo di macchina disponibile, esegui gdcloud compute machine-types list.
    • BOOT_DISK_AUTO_DELETE: indica se il disco di avvio viene eliminato automaticamente quando viene eliminata l'istanza VM.

  2. Verifica che la VM sia disponibile e attendi che mostri lo stato Running. Lo stato Running non indica che il sistema operativo è completamente pronto e accessibile.

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

    Sostituisci VM_NAME e PROJECT con il nome e il progetto della VM.

  3. Ripeti i passaggi precedenti per ogni zona del tuo universo GDC. Assicurati che in ogni zona che vuoi utilizzare per la tua strategia di alta disponibilità sia presente un'istanza VM.

Configura i bilanciatori del carico

Per distribuire il traffico tra le VM in zone diverse, crea bilanciatori del carico. Hai la possibilità di creare bilanciatori del carico esterni (ELB) e bilanciatori del carico interni (ILB), entrambi configurabili a livello di zona o globale. Per questo esempio, configura un bilanciatore del carico interno globale e un bilanciatore del carico esterno globale per l'applicazione VM.

Crea un bilanciatore del carico interno globale

I bilanciatori del carico interni (ILB) espongono i servizi all'interno dell'organizzazione da un pool di indirizzi IP interni assegnato all'organizzazione. Un servizio ILB non è mai accessibile da qualsiasi endpoint al di fuori dell'organizzazione.

Completa i seguenti passaggi per creare un bilanciamento del carico interno globale per i tuoi carichi di lavoro VM.

gdcloud

Crea un bilanciamento del carico interno che ha come target i carichi di lavoro delle VM 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 di zona in ogni zona in cui vengono eseguite le VM per definire l'endpoint per il bilanciamento del carico interno:

    gdcloud compute backends create BACKEND_NAME \
    --labels=LABELS \
    --project=PROJECT \
    --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 le VM utilizzare per questa risorsa di backend, ad esempio app=web.
    • PROJECT: il nome del progetto.
    • 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. Definisci un controllo di integrità globale per il bilanciatore del carico interno:

    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

    Sostituisci quanto segue:

    • HEALTH_CHECK_NAME: il nome della risorsa di controllo dell'integrità, ad esempio my-health-check.
    • CHECK_INTERVAL: l'intervallo di tempo in secondi dall'inizio di un probe all'inizio di quello successivo. Il valore predefinito è 5. Questo campo è facoltativo.
    • HEALTHY_THRESHOLD: il tempo di attesa prima di dichiarare l'errore. Il valore predefinito è 5. Questo campo è facoltativo.
    • TIMEOUT: la quantità di tempo in secondi da attendere prima di dichiarare l'errore. Il valore predefinito è 5. Questo campo è facoltativo.
    • UNHEALTHY_THRESHOLD: il numero di probe sequenziali che non devono riuscire affinché l'endpoint sia considerato non integro. Il valore predefinito è 2. Questo campo è facoltativo.
    • PORT: la porta su cui viene eseguito il controllo di integrità. Il valore predefinito è 80. Questo campo è facoltativo.

  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 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.
    • HEALTH_CHECK_NAME: il nome della risorsa di controllo dell'integrità. Questo campo è facoltativo.

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

  5. 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 che l'applicazione effettiva espone all'interno della VM.

  6. 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 bilanciamento del carico interno che ha come target i carichi di lavoro delle VM 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 delle VM:

    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

    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.
    • APP_NAME: il nome dell'applicazione VM.

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

  2. Definisci un controllo di integrità globale per il bilanciatore del carico interno:

    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

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del percorso kubeconfig del server API globale. Per ulteriori informazioni, vedi Passare a un contesto globale.
    • PROJECT: il nome del progetto.
    • HEALTH_CHECK_NAME: il nome della risorsa di controllo di integrità, ad esempio my-health-check.
    • PORT: la porta su cui eseguire il controllo di integrità. Il valore predefinito è 80.
    • TIMEOUT: il tempo di attesa in secondi prima di dichiarare l'errore. Il valore predefinito è 5.
    • CHECK_INTERVAL: il tempo in secondi dall'inizio di un probe all'inizio di quello successivo. Il valore predefinito è 5.
    • HEALTHY_THRESHOLD: il numero di probe sequenziali che devono superare il test affinché l'endpoint sia considerato integro. Il valore predefinito è 2.
    • UNHEALTHY_THRESHOLD: il numero di probe sequenziali che non devono riuscire affinché l'endpoint sia considerato non integro. Il valore predefinito è 2.

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

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

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

Crea un bilanciatore del carico esterno globale

I bilanciatori del carico esterni (ELB) espongono i servizi per l'accesso dall'esterno dell'organizzazione da un pool di indirizzi IP assegnati all'organizzazione dal pool di indirizzi IP esterni delle istanze più grande.

Completa i seguenti passaggi per creare un ELB globale per i carichi di lavoro delle VM.

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

    Sostituisci quanto segue:

    • BACKEND_NAME: il nome della risorsa di backend, ad esempio my-backend.
    • LABELS: un selettore che definisce quali endpoint tra le VM utilizzare per questa risorsa di backend, ad esempio app=web.
    • PROJECT: il nome del progetto.

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

  3. Definisci un controllo di integrità globale per 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

    Sostituisci quanto segue:

    • HEALTH_CHECK_NAME: il nome della risorsa di controllo di integrità'integrità, ad esempio my-health-check.
    • CHECK_INTERVAL: l'intervallo di tempo in secondi dall'inizio di un probe all'inizio di quello successivo. Il valore predefinito è 5. Questo campo è facoltativo.
    • HEALTHY_THRESHOLD: il tempo di attesa prima di dichiarare l'errore. Il valore predefinito è 5. Questo campo è facoltativo.
    • TIMEOUT: la quantità di tempo in secondi da attendere prima di dichiarare l'errore. Il valore predefinito è 5. Questo campo è facoltativo.
    • UNHEALTHY_THRESHOLD: il numero di probe sequenziali che non devono riuscire affinché l'endpoint sia considerato in stato non integro. Il valore predefinito è 2. Questo campo è facoltativo.
    • PORT: la porta su cui eseguire il controllo di integrità. Il valore predefinito è 80. Questo campo è facoltativo.

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

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

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

  6. 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 della VM.
    • PROJECT: il nome del progetto.

  7. 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 delle VM 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 sulle VM dietro il bilanciamento 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:
  endpointsLabels:
    matchLabels:
      app: server
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.

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

  3. Definisci un controllo di integrità globale per 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

    Sostituisci quanto segue:

    • HEALTH_CHECK_NAME: il nome della risorsa di controllo di integrità'integrità, ad esempio my-health-check.
    • PORT: la porta su cui eseguire il controllo di integrità. Il valore predefinito è 80.
    • TIMEOUT: la quantità di tempo in secondi da attendere prima di dichiarare l'errore. Il valore predefinito è 5.
    • CHECK_INTERVAL: l'intervallo di tempo in secondi dall'inizio di un probe all'inizio di quello successivo. Il valore predefinito è 5.
    • HEALTHY_THRESHOLD: il numero di probe sequenziali che devono superare il controllo affinché l'endpoint sia considerato integro. Il valore predefinito è 2.
    • UNHEALTHY_THRESHOLD: il numero di probe sequenziali che non devono riuscire affinché l'endpoint sia considerato in stato non integro. Il valore predefinito è 2.

    Poiché si tratta di un ELB globale, crea il controllo di integrità nell'API globale.

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

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

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

Configura la replica asincrona dell'archiviazione

Gli universi multizona GDC offrono l'utilizzo di risorse di archiviazione replicate come volumi e bucket in modalità asincrona per scenari di ripristino di emergenza. Queste opzioni di risorse di archiviazione forniscono la replica asincrona dei dati tra due zone qualsiasi nella stessa regione. La replica asincrona viene eseguita in background, fornendo un RPO (Recovery Point Objective) basso, ma diverso da zero, in caso di emergenza. Tutti i dati replicati sono online e immediatamente accessibili, ma potrebbe essere necessaria una procedura di failover manuale per abilitare la scrittura nella zona secondaria.

Puoi scegliere uno dei seguenti tipi di replica asincrona dell'archiviazione per l'applicazione VM:

Crea un bucket dual-zone per l'archiviazione degli oggetti

I dati di archiviazione di oggetti vengono scritti in un singolo bucket i cui dati vengono archiviati in entrambe le zone. Poiché i dati vengono copiati in modo asincrono tra le zone, queste potrebbero non contenere le stesse versioni degli oggetti in un determinato momento, ma alla fine diventeranno equivalenti se non vengono apportate ulteriori modifiche. A differenza della replica dei volumi, i bucket replicati sono scrivibili durante le partizioni di zona. Ogni scrittura in un oggetto produce una versione diversa e l'ultima versione in una zona sarà lo stato finale dopo il ripristino della connettività.

  1. Verifica che l'operatore dell'infrastruttura (IO) abbia creato la risorsa personalizzata BucketLocationConfig, necessaria per la replica asincrona tra zone per l'archiviazione di oggetti. Questa risorsa deve essere implementata nel server API globale principale.

  2. Crea la risorsa personalizzata Bucket a doppia zona:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: object.global.gdc.goog/v1
kind: Bucket
metadata:
  name: BUCKET_NAME
  namespace: PROJECT
spec:
  location: LOCATION_NAME
  description: Sample DZ Bucket
  storageClass: Standard
EOF

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il file kubeconfig per il server API globale.
    • BUCKET_NAME: il nome del bucket di archiviazione.
    • PROJECT: il nome del progetto in cui si trova il bucket.
    • LOCATION_NAME: il luogo fisico in cui risiedono i dati degli oggetti nel bucket. Deve corrispondere al nome di una risorsa BucketLocation esistente. Per eseguire query sul server API globale della tua organizzazione per un elenco di risorse BucketLocation disponibili, esegui kubectl --kubeconfig GLOBAL_API_SERVER bucketlocations. Se non sono presenti risorse BucketLocation, contatta il tuo IO per verificare che abbia attivato la replica asincrona.

Configura la replica asincrona dell'archiviazione a blocchi tra zone

L'archiviazione a blocchi replicata fornisce volumi (PV) replicati in modo asincrono, che mantengono l'equivalenza dei blocchi tra i volumi primario e secondario. A causa della natura asincrona, il volume secondario riflette lo stato della zona primaria in un momento del passato (RPO diverso da zero). Il volume secondario non è montabile finché rimane la destinazione della replica, il che richiede un intervento manuale per terminare la relazione e consentire le scritture.

Devi eseguire il deployment di una risorsa personalizzata VolumeReplicationRelationship sul server API globale per creare dati replicati disponibili per il failover se i dati della zona di origine non sono più disponibili.

Prima di iniziare, verifica che l'operatore dell'infrastruttura (IO) abbia creato e configurato le risorse personalizzate StorageClusterPeering e StorageVirtualMachinePeering per consentire la replica dell'archiviazione a blocchi tra le zone. Questa risorsa deve essere implementata nel server API globale principale.

gdcloud

  1. Imposta la relazione tra i volumi di replica asincrona tra la zona primaria e le zone secondarie:

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

    Sostituisci quanto segue:

    • PRIMARY_DISK_NAME: il nome del disco di origine in fase di replica.
    • PROJECT: il progetto GDC del disco primario.
    • PRIMARY_ZONE: la zona in cui risiede il disco primario.
    • SECONDARY_DISK_NAME: il nome del disco di destinazione in cui eseguire la replica.
    • SECONDARY_ZONE: la zona in cui deve risiedere il disco secondario.

  2. Crea una risorsa personalizzata VolumeFailover nella zona di destinazione, che interrompe la replica nella zona di destinazione se la zona di origine non è disponibile per qualsiasi motivo:

    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

    Sostituisci quanto segue:

    • MANAGEMENT_API_SERVER: il file kubeconfig per il server dell'API Management.
    • FAILOVER_NAME: il nome del failover.
    • PROJECT: il progetto in cui risiede l'infrastruttura di archiviazione.
    • REPL_NAME: il nome della relazione di replica del volume.

    Per saperne di più sulla gestione della replica asincrona per i workload delle VM, vedi Replica asincrona dei volumi.

API

  1. Crea un file YAML della risorsa personalizzata VolumeReplicationRelationship e deployalo sul server API globale:

    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

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il file kubeconfig per il server API di gestione globale.
    • VRR_NAME: il nome della relazione di replica del volume. Deve essere utilizzato lo stesso nome quando si interrompe la replica asincrona.
    • PROJECT: il progetto GDC del disco principale.
    • PRIMARY_DISK_NAME: il nome del disco di origine in fase di replica.
    • PRIMARY_ZONE: la zona in cui risiede il disco primario.
    • SECONDARY_DISK_NAME: il nome del disco di destinazione in cui eseguire la replica.
    • SECONDARY_ZONE: la zona in cui deve risiedere il disco secondario.

  2. Crea una risorsa personalizzata VolumeFailover nella zona di destinazione, che interrompe la replica nella zona di destinazione se la zona di origine non è disponibile per qualsiasi motivo:

    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

    Sostituisci quanto segue:

    • MANAGEMENT_API_SERVER: il file kubeconfig per il server dell'API Management.
    • FAILOVER_NAME: il nome del failover.
    • PROJECT: il progetto in cui risiede l'infrastruttura di archiviazione.
    • REPL_NAME: il nome della relazione di replica del volume.

Per saperne di più sulla gestione della replica asincrona per i workload delle VM, vedi Replica asincrona dei volumi.

Passaggi successivi