Questa pagina è stata tradotta dall'API Cloud Translation.

Configura i bilanciatori del carico esterni

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

Gli indirizzi IP virtuali (VIP) ELB non sono in conflitto tra le organizzazioni e sono univoci in tutte le organizzazioni. Per questo motivo, devi utilizzare i servizi ELB solo per i servizi a cui i client esterni all'organizzazione devono necessariamente accedere.

I carichi di lavoro in esecuzione all'interno dell'organizzazione possono accedere ai servizi ELB a condizione che consenti ai carichi di lavoro di uscire dall'organizzazione. Questo pattern di traffico richiede effettivamente il traffico in uscita dall'organizzazione prima di tornare al servizio interno.

Prima di iniziare

Per configurare i servizi ELB, devi disporre di quanto segue:

Essere proprietario del progetto per cui stai configurando il bilanciatore del carico. Per saperne di più, consulta Creare un progetto.
Un criterio di ingresso ProjectNetworkPolicy (PNP) personalizzato per consentire il traffico a questo servizio ELB. Per ulteriori informazioni, consulta Configurare PNP per consentire il traffico verso ELB.
I ruoli di identità e accesso necessari:
- Amministratore NetworkPolicy del progetto: ha accesso alla gestione dei criteri di rete del progetto nello spazio dei nomi del progetto. Chiedi all'amministratore IAM dell'organizzazione di concederti il ruolo Amministratore NetworkPolicy del progetto (project-networkpolicy-admin).
- Amministratore del bilanciatore del carico: chiedi all'amministratore IAM dell'organizzazione di concederti il ruolo Amministratore del bilanciatore del carico (load-balancer-admin).
- Amministratore bilanciatore del carico globale: per i bilanciatori del carico elastico globali, chiedi all'amministratore IAM dell'organizzazione di concederti il ruolo Amministratore bilanciatore del carico globale (global-load-balancer-admin). Per ulteriori informazioni, consulta Descrizioni dei ruoli predefiniti.

Configura PNP per consentire il traffico verso ELB

Per il funzionamento dei servizi ELB, devi configurare e applicare il tuo criterio di ingresso ProjectNetworkPolicy personalizzato per consentire il traffico verso i 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 MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.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:

MANAGEMENT_API_SERVER: il percorso kubeconfig del server API Management. Se non hai ancora generato un file kubeconfig per il server API nella zona di destinazione, consulta Accedi per maggiori dettagli.
PROJECT: il nome del tuo progetto GDC.
CIDR: il CIDR esterno da cui deve essere accessibile l'ELB. Questa policy è necessaria 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 maggiori 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[].targetPort del manifest per la risorsa Service. Questo campo è facoltativo.

Crea un bilanciatore del carico esterno

Puoi creare ELB globali o di zona. L'ambito dei progetti ELB globali si estende a un universo GDC. L'ambito dei bilanciatori del carico elastici zonali è limitato alla zona specificata al momento della creazione. Per saperne di più, vedi Bilanciatori del carico globali e zonali.

Crea ELB utilizzando tre metodi diversi in GDC:

Utilizza gcloud CLI per creare bilanciatori del carico ELB globali o a livello di zona.
Utilizza l'API Networking Kubernetes Resource Model (KRM) per creare ELB globali o a livello di zona.
Utilizza il servizio Kubernetes direttamente nel cluster Kubernetes. Questo metodo è disponibile solo per i bilanciatori del carico elastici zonali.

Puoi scegliere come target i carichi di lavoro dei pod o delle VM utilizzando l'API KRM e gcloud CLI. Puoi scegliere come target solo i workload nel cluster in cui viene creato l'oggetto Service quando utilizzi il servizio Kubernetes direttamente nel cluster Kubernetes.

Crea un bilanciamento del carico ELB di zona

Crea un ELB zonale utilizzando gcloud CLI, l'API KRM o il servizio Kubernetes nel cluster Kubernetes:

gdcloud

Crea un ELB che ha come target carichi di lavoro di pod o VM utilizzando gcloud CLI.

Questo ELB ha come target tutti i carichi di lavoro nel progetto che corrispondono all'etichetta definita nell'oggetto Backend.

Per creare un ELB utilizzando gcloud CLI, segui questi passaggi:

Crea una risorsa Backend per definire l'endpoint per ELB:
```
gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster=CLUSTER_NAME
```
Sostituisci quanto segue:
- BACKEND_NAME: il nome che hai scelto per la risorsa di backend, ad esempio my-backend.
- LABELS: un selettore che definisce quali endpoint tra pod e VM utilizzare per questa risorsa di backend. Ad esempio, app=web.
- PROJECT_NAME: 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.
- CLUSTER_NAME: il cluster 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.
Salta questo passaggio se questo ELB è per i workload dei pod. Se stai configurando un ELB per i carichi di lavoro delle VM, definisci un controllo di integrità per l'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 \
  --zone=ZONE
```
Sostituisci quanto segue:
- HEALTH_CHECK_NAME: il nome che hai scelto per la risorsa di controllo di integrità#39;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: il tempo di attesa in secondi 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.
- ZONE: la zona in cui stai creando questo ELB.
Crea una risorsa BackendService e aggiungici la risorsa Backend creata in precedenza:
```
gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME
```
Sostituisci quanto segue:
- BACKEND_SERVICE_NAME: il nome scelto per questo servizio di backend.
- TARGET_PORT: 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. Includi questo campo solo se stai configurando un ELB per i carichi di lavoro delle VM.

Aggiungi la risorsa BackendService alla risorsa Backend creata in precedenza:

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

(Facoltativo) Utilizza l'affinità sessione per gli ELB per garantire che le richieste dello stesso client vengano indirizzate in modo coerente allo stesso backend. Per abilitare l&#39affinità sessionee per i bilanciatori del carico, crea una policy del servizio di backend utilizzando il comando gdcloud compute load-balancer-policy create:
```
 gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL
```
Sostituisci quanto segue:
- POLICY_NAME: il nome che hai scelto per la policy del servizio di backend.
- MODE: la modalità di affinità sessione. Sono supportate due modalità:
  - NONE: l'affinità sessione è disattivata. Le richieste vengono instradate a qualsiasi backend disponibile. Si tratta della modalità predefinita.
  - CLIENT_IP_DST_PORT_PROTO: le richieste dalla stessa quadrupla (indirizzo IP di origine, indirizzo IP di destinazione, porta di destinazione e protocollo) vengono instradate allo stesso backend.
- RESOURCE_LABEL: il selettore di etichette che seleziona a quale servizio di backend viene applicata la risorsa BackendServicePolicy nello spazio dei nomi del progetto. Se più risorse BackendServicePolicy corrispondono allo stesso servizio di backend e almeno uno di questi criteri ha l'affinità sessione abilitata, l'affinità sessione per questa risorsa BackendService viene abilitata.
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 \
  --zone=ZONE \
  --project=PROJECT_NAME
```
Sostituisci quanto segue:
- BACKEND_SERVICE_NAME: il nome del servizio di backend.
- FORWARDING_RULE_EXTERNAL_NAME: il nome che hai scelto per la regola di forwarding.
- CIDR: questo campo è facoltativo. Se non specificato, un CIDR IPv4/32 viene riservato automaticamente dal pool IP zonale. Specifica il nome di una risorsa Subnet nello stesso spazio dei nomi di questa regola di forwarding. Una risorsa Subnet rappresenta le informazioni di richiesta e allocazione di una subnet di zona. Per saperne di più sulle risorse Subnet, consulta Risorse personalizzate di esempio.
- 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.
Per verificare l'ELB configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Per ottenere l'indirizzo IP assegnato del bilanciatore del carico, descrivi la regola di forwarding:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
```
Per convalidare l'ELB configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Verifica il traffico con una richiesta curl all'indirizzo 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 forwarding.
  - 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 o delle VM utilizzando l'API KRM. Questo ELB ha come target tutti i carichi di lavoro nel progetto che corrispondono all'etichetta definita nell'oggetto Backend.

Per creare un ELB a livello di zona utilizzando l'API KRM:

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
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF
```
Sostituisci quanto segue:
- MANAGEMENT_API_SERVER: il percorso kubeconfig del server API Management zonale. Per ulteriori informazioni, vedi Passare a un contesto zonale.
- PROJECT_NAME: il nome del progetto.
- BACKEND_NAME: il nome della risorsa Backend.
- CLUSTER_NAME: questo è un campo facoltativo. Questo campo specifica il cluster a cui è limitato l'ambito dei selettori definiti. Questo campo non si applica ai carichi di lavoro delle VM. Se una risorsa Backend non include il campo clusterName, le etichette specificate vengono applicate a tutti i carichi di lavoro nel progetto.
Salta questo passaggio se questo ELB è per i workload dei pod. Se stai configurando un ELB per i carichi di lavoro delle VM, definisci un controllo di integrità per l'ELB:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF
```
Sostituisci quanto segue:
- HEALTH_CHECK_NAME: il nome che hai scelto per la risorsa di controllo di integrità#39;integrità, ad esempio my-health-check.
- PORT: la porta su cui viene eseguito 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: 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 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.
Crea un oggetto BackendService utilizzando la risorsa Backend creata in precedenza. Se stai configurando un ELB per i carichi di lavoro delle VM, includi la risorsa HealthCheck.
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
  healthCheckName: HEALTH_CHECK_NAME
EOF
```
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 carichi di lavoro dei pod.
(Facoltativo) Utilizza l'affinità sessione per gli ELB per garantire che le richieste dello stesso client vengano indirizzate in modo coerente allo stesso backend. Per abilitare l&#39affinità sessionee per i bilanciatori del carico, crea una risorsa BackendServicePolicy. Questa risorsa definisce le impostazioni di affinità sessione e applica la risorsa BackendServicePolicy alla risorsa BackendService. Crea e applica la risorsa BackendServicePolicy:
```
 kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL
```
Sostituisci quanto segue:
- POLICY_NAME: il nome che hai scelto per la policy del servizio di backend.
- MODE: la modalità di affinità sessione. Sono supportate due modalità:
  - NONE: l'affinità sessione è disattivata. Le richieste vengono instradate a qualsiasi backend disponibile. Si tratta della modalità predefinita.
  - CLIENT_IP_DST_PORT_PROTO: le richieste dalla stessa quadrupla (indirizzo IP di origine, indirizzo IP di destinazione, porta di destinazione e protocollo) vengono instradate allo stesso backend.
- RESOURCE_LABEL: il selettore di etichette che seleziona a quale servizio di backend viene applicata la risorsa BackendServicePolicy nello spazio dei nomi del progetto. Se più risorse BackendServicePolicy corrispondono allo stesso servizio di backend e almeno uno di questi criteri ha l'affinità sessione abilitata, l'affinità sessione per questa risorsa BackendService viene abilitata.
Crea una risorsa ForwardingRule esterna che definisca l'IP virtuale a cui è disponibile il servizio.
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  Name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF
```
Sostituisci quanto segue:
- BACKEND_SERVICE_NAME: il nome della risorsa BackendService.
- FORWARDING_RULE_EXTERNAL_NAME: il nome che hai scelto per la risorsa ForwardingRuleExternal.
- CIDR: questo campo è facoltativo. Se non specificato, viene riservato automaticamente un CIDR IPv4/32 dal pool IP zonale. Specifica il nome di una risorsa Subnet nello stesso spazio dei nomi di questa regola di inoltro. Una risorsa Subnet rappresenta le informazioni di richiesta e allocazione di una subnet zonale. Per saperne di più sulle risorse Subnet, consulta Esempio di risorse personalizzate.
- PORT: 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
```
Per convalidare l'ELB configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Verifica il traffico con una richiesta curl all'indirizzo VIP:
1. Per ottenere il VIP, utilizza kubectl get:
```
kubectl get forwardingruleexternal -n PROJECT_NAME
```
  L'output è simile al seguente:
```
NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/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 con il VIP della regola di forwarding.

Servizio Kubernetes

Puoi creare ELB in GDC creando un Service Kubernetes di tipo LoadBalancer in un cluster Kubernetes.

Per creare un servizio ELB:

Crea un file YAML per la definizione Service del tipo LoadBalancer.

Nota: contrariamente alla procedura per i bilanciatori del carico interni, non aggiungere annotazioni al file. Se non specifichi l'annotazione internal, il servizio è rivolto all'esterno per impostazione predefinita.

Il seguente oggetto Service è un esempio di servizio ELB:
```
apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1235
    protocol: TCP
    targetPort: 1235
  selector:
    k8s-app: my-app
  type: LoadBalancer
```
Sostituisci quanto segue:
- ELB_SERVICE_NAME: il nome del servizio ELB.
- PROJECT_NAME: lo spazio dei nomi del progetto che contiene i carichi di lavoro di backend.
Il campo port configura la porta frontend che esponi sull'indirizzo VIP. Il campo targetPort configura la porta di backend a cui vuoi inoltrare il traffico sui workload di backend. Il bilanciatore del carico supporta Network Address Translation (NAT). Le porte frontend e backend possono essere diverse.
Nel campo selector della definizione Service, specifica i pod o le macchine virtuali come carichi di lavoro di backend.

Il selettore definisce quali carichi di lavoro considerare come carichi di lavoro di backend per questo servizio, in base alla corrispondenza tra le etichette specificate e quelle dei carichi di lavoro. Service può selezionare solo i workload di backend nello stesso progetto e nello stesso cluster in cui definisci Service.

Per saperne di più sulla selezione dei servizi, visita https://kubernetes.io/docs/concepts/services-networking/service/.
Salva il file di definizione Service nello stesso progetto dei carichi di lavoro di backend.
Applica il file di definizione Service al cluster:
```
kubectl apply -f ELB_FILE
```
Sostituisci ELB_FILE con il nome del file di definizione Service per il servizio ELB.

Quando crei un ELB, il servizio riceve due indirizzi IP. Uno è un indirizzo IP interno accessibile solo dall'interno dello stesso cluster. L'altro è l'indirizzo IP esterno, accessibile dall'interno e dall'esterno dell'organizzazione. Puoi ottenere gli indirizzi IP del servizio ELB visualizzando lo stato del servizio:
```
kubectl -n PROJECT_NAME get svc ELB_SERVICE_NAME
```
Sostituisci quanto segue:
- PROJECT_NAME: lo spazio dei nomi del progetto che contiene i carichi di lavoro di backend.
- ELB_SERVICE_NAME: il nome del servizio ELB.
Devi ottenere un output simile al seguente esempio:
```
NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      20.12.1.11      1235:31931/TCP   22h
```
EXTERNAL-IP è l'indirizzo IP del servizio accessibile dall'esterno dell'organizzazione.

Se non ottieni un output, assicurati di aver creato il servizio ELB correttamente.

Crea un ELB globale

Crea un ELB globale utilizzando gcloud CLI o l'API KRM.

gdcloud

Crea un ELB che ha come target carichi di lavoro di pod o VM utilizzando gcloud CLI.

Questo ELB 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 ELB utilizzando gcloud CLI, segui questi passaggi:

Crea una risorsa Backend per definire l'endpoint per ELB:
```
gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster=CLUSTER_NAME \
  --zone=ZONE
```
Sostituisci quanto segue:
- BACKEND_NAME: il nome che hai scelto per la risorsa di backend, ad esempio my-backend.
- LABELS: un selettore che definisce quali endpoint tra pod e VM utilizzare per questa risorsa di backend. Ad esempio, app=web.
- PROJECT_NAME: il nome del progetto.
- CLUSTER_NAME: il cluster 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.
Salta questo passaggio se questo ELB è per i workload dei pod. Se stai configurando un ELB per i carichi di lavoro delle VM, definisci un controllo di integrità per l'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 che hai scelto per la risorsa di controllo di integrità#39;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: il tempo di attesa in secondi 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.
Crea una risorsa BackendService e aggiungici la risorsa Backend creata in precedenza:
```
gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --health-check=HEALTH_CHECK_NAME \
  --global
```
Sostituisci quanto segue:
- BACKEND_SERVICE_NAME: il nome scelto per questo servizio di backend.
- 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. Includi questo campo solo se stai configurando un ELB per i carichi di lavoro delle VM.

Aggiungi la risorsa BackendService alla risorsa Backend creata in precedenza:

gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --backend-zone BACKEND_ZONE \
  --project=PROJECT_NAME \
  --global

(Facoltativo) Utilizza l'affinità sessione per gli ELB per garantire che le richieste dello stesso client vengano indirizzate in modo coerente allo stesso backend. Per abilitare l&#39affinità sessionee per i bilanciatori del carico, crea una policy del servizio di backend utilizzando il comando gdcloud compute load-balancer-policy create:
```
 gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL
```
Sostituisci quanto segue:
- POLICY_NAME: il nome che hai scelto per la policy del servizio di backend.
- MODE: la modalità di affinità sessione. Sono supportate due modalità:
  - NONE: l'affinità sessione è disattivata. Le richieste vengono instradate a qualsiasi backend disponibile. Si tratta della modalità predefinita.
  - CLIENT_IP_DST_PORT_PROTO: le richieste dalla stessa quadrupla (indirizzo IP di origine, indirizzo IP di destinazione, porta di destinazione e protocollo) vengono instradate allo stesso backend.
- RESOURCE_LABEL: il selettore di etichette che seleziona a quale servizio di backend viene applicata la risorsa BackendServicePolicy nello spazio dei nomi del progetto. Se più risorse BackendServicePolicy corrispondono allo stesso servizio di backend e almeno uno di questi criteri ha l'affinità sessione abilitata, l'affinità sessione per questa risorsa BackendService viene abilitata.
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_NAME \
  --global
```
Sostituisci quanto segue:
- BACKEND_SERVICE_NAME: il nome del servizio di backend.
- FORWARDING_RULE_EXTERNAL_NAME: il nome che hai scelto per la regola di forwarding.
- CIDR: questo campo è facoltativo. Se non specificato, viene riservato automaticamente un CIDR IPv4/32 dal pool IP globale. Specifica il nome di una risorsa Subnet nello stesso spazio dei nomi di questa regola di forwarding. Una risorsa Subnet rappresenta la richiesta e le informazioni di allocazione di una subnet globale. Per saperne di più sulle risorse Subnet, consulta Esempio di risorse personalizzate.
- 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.
Per verificare l'ELB configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Per ottenere l'indirizzo IP assegnato del bilanciatore del carico, descrivi la regola di forwarding:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
```
Per convalidare l'ELB configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Verifica il traffico con una richiesta curl all'indirizzo VIP:
1. Per ottenere il VIP assegnato, descrivi la regola di forwarding:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME --global
```
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 forwarding.
  - 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 o 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:

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
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF
```
Sostituisci quanto segue:
- MANAGEMENT_API_SERVER: il percorso kubeconfig del server API di gestione globale. Per ulteriori informazioni, vedi Passare al contesto globale.
- PROJECT_NAME: il nome del progetto.
- BACKEND_NAME: il nome della risorsa Backend.
- CLUSTER_NAME: questo è un campo facoltativo. Questo campo specifica il cluster a cui è limitato l'ambito dei selettori definiti. Questo campo non si applica ai carichi di lavoro delle VM. Se una risorsa Backend non include il campo clusterName, le etichette specificate vengono applicate a tutti i carichi di lavoro nel progetto.
Salta questo passaggio se questo ELB è per i workload dei pod. Se stai configurando un ELB per i carichi di lavoro delle VM, definisci un controllo di integrità per l'ELB:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF
```
Sostituisci quanto segue:
- HEALTH_CHECK_NAME: il nome che hai scelto per la risorsa di controllo di integrità#39;integrità, ad esempio my-health-check.
- PORT: la porta su cui viene eseguito 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: 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 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.
Poiché si tratta di un ELB globale, crea il controllo di integrità nell'API globale.
Crea un oggetto BackendService utilizzando la risorsa Backend creata in precedenza. Se stai configurando un ELB per i carichi di lavoro delle VM, includi la risorsa HealthCheck.
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
  targetPorts:
  - port: PORT
    protocol: PROTOCOL
    targetPort: TARGET_PORT
EOF
```
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 viene creata la risorsa Backend. Puoi specificare più backend nel campo backendRefs. Ad esempio:
```
- name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-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 PORT, ad esempio 8080. Il valore di TARGET_PORT non può essere ripetuto in un determinato oggetto. Un esempio per targetPorts potrebbe avere il seguente aspetto:
```
targetPorts:
- port: 80
  protocol: TCP
  targetPort: 8080
```
(Facoltativo) Utilizza l'affinità sessione per gli ELB per garantire che le richieste dello stesso client vengano indirizzate in modo coerente allo stesso backend. Per abilitare l&#39affinità sessionee per i bilanciatori del carico, crea una risorsa BackendServicePolicy. Questa risorsa definisce le impostazioni di affinità sessione e applica la risorsa BackendServicePolicy alla risorsa BackendService. Crea e applica la risorsa BackendServicePolicy:
```
 kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL
```
Sostituisci quanto segue:
- POLICY_NAME: il nome che hai scelto per la policy del servizio di backend.
- MODE: la modalità di affinità sessione. Sono supportate due modalità:
  - NONE: l'affinità sessione è disattivata. Le richieste vengono instradate a qualsiasi backend disponibile. Si tratta della modalità predefinita.
  - CLIENT_IP_DST_PORT_PROTO: le richieste dalla stessa quadrupla (indirizzo IP di origine, indirizzo IP di destinazione, porta di destinazione e protocollo) vengono instradate allo stesso backend.
- RESOURCE_LABEL: il selettore di etichette che seleziona a quale servizio di backend viene applicata la risorsa BackendServicePolicy nello spazio dei nomi del progetto. Se più risorse BackendServicePolicy corrispondono allo stesso servizio di backend e almeno uno di questi criteri ha l'affinità sessione abilitata, l'affinità sessione per questa risorsa BackendService viene abilitata.
Crea una risorsa ForwardingRule esterna che definisca l'IP virtuale a cui è disponibile il servizio.
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  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: questo campo è facoltativo. Se non specificato, viene riservato automaticamente un CIDR IPv4/32 dal pool IP globale. Specifica il nome di una risorsa Subnet nello stesso spazio dei nomi di questa regola di forwarding. Una risorsa Subnet rappresenta la richiesta e le informazioni di allocazione di una subnet globale. Per saperne di più sulle risorse Subnet, consulta Esempio di risorse personalizzate.
- PORT: 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
```
Per convalidare l'ELB configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Verifica il traffico con una richiesta curl all'indirizzo VIP:
1. Per ottenere il VIP, utilizza kubectl get:
```
kubectl get forwardingruleexternal -n PROJECT_NAME
```
  L'output è simile al seguente:
```
NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/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 con il VIP della regola di forwarding.

Configura i bilanciatori del carico esterni Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Prima di iniziare

Configura PNP per consentire il traffico verso ELB

Crea un bilanciatore del carico esterno

Crea un bilanciamento del carico ELB di zona

gdcloud

API

Servizio Kubernetes

Crea un ELB globale

gdcloud

API

Configura i bilanciatori del carico esterni