Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

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 all'istanza più grande.

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

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

Esistono istruzioni distinte per la configurazione degli ELB per i cluster condivisi e standard.

Crea un bilanciatore del carico esterno per i cluster condivisi

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

Prima di iniziare

Per configurare i servizi ELB, devi:

Essere proprietario del progetto per cui stai configurando il bilanciatore del carico. Per saperne di più, consulta Crea un progetto.
Disporre di una policy in entrata ProjectNetworkPolicy (PNP) personalizzata per consentire il traffico verso questo servizio ELB. Per saperne di più, consulta Configura PNP per consentire il traffico verso ELB.
Disporre dei ruoli di identità e accesso necessari:
- Project NetworkPolicy Admin: ha accesso per gestire le policy di rete del progetto nello spazio dei nomi del progetto. Chiedi all'amministratore dell'organizzazione IAM di concederti il ruolo Project NetworkPolicy Admin (project-networkpolicy-admin).
- Amministratore del bilanciatore del carico: chiedi all'amministratore dell'organizzazione IAM di concederti il ruolo Amministratore del bilanciatore del carico (load-balancer-admin).
- Amministratore del bilanciatore del carico globale: per gli ELB globali, chiedi all'amministratore dell'organizzazione IAM di concederti il ruolo Amministratore del bilanciatore del carico globale (global-load-balancer-admin). Per saperne di più, consulta Descrizioni dei ruoli predefiniti.

Configura PNP per consentire il traffico verso ELB

Affinché i servizi ELB funzionino, devi configurare e applicare la tua policy in entrata ProjectNetworkPolicy personalizzata per consentire il traffico verso i workload di questo servizio ELB. Le policy di rete controllano l'accesso ai 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 verso i workload di questo bilanciatore del carico:

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 di gestione. Se non hai ancora generato un file kubeconfig per il server API nella zona di destinazione, consulta Accedi per i dettagli.
PROJECT: il nome del progetto GDC.
CIDR: il CIDR esterno da cui deve essere eseguito l'accesso all'ELB. Questa policy è obbligatoria perché il bilanciatore del carico esterno utilizza Direct Server Return (DSR), che conserva l'indirizzo IP esterno di origine e bypassa il bilanciatore del carico nel percorso di ritorno. Per saperne di più, consulta Crea una regola firewall in entrata globale per il traffico esterno all'organizzazione.
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 ELB utilizzando tre metodi diversi in GDC:

Utilizza la CLI gdcloud per creare ELB globali o a livello di zona.
Utilizza l'API Networking Kubernetes Resource Model (KRM) per creare ELB globali o di zona.
Utilizza il servizio Kubernetes direttamente nel cluster Kubernetes. Questo metodo è disponibile solo per gli ELB di zona.

Puoi scegliere come target i workload di pod o VM utilizzando l'API KRM e la CLI gdcloud. 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 ELB di zona

Crea un ELB di zona utilizzando la CLI gdcloud, l'API KRM o il servizio Kubernetes nel cluster Kubernetes:

gdcloud

Crea un ELB che ha come target i workload di pod o VM utilizzando la CLI gdcloud.

Questo bilanciatore del carico esterno ha come target tutti i workload del progetto che corrispondono all'etichetta definita nell'oggetto Backend.

Per creare un ELB utilizzando la CLI gdcloud, segui questi passaggi:

Crea una risorsa Backend per definire l'endpoint per l'ELB:
```
gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster-name=CLUSTER_NAME
```
Sostituisci quanto segue:
- BACKEND_NAME: il nome 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 della zona per tutti i comandi che lo richiedono, esegui: gdcloud config set core/zone ZONE. Il flag zone è disponibile solo in 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 specificata. Questo campo è facoltativo.
Salta questo passaggio se questo ELB è per i workload dei pod. Se stai configurando un ELB per i workload delle VM, definisci il tipo di controllo di integrità per l'ELB. Ad esempio, per creare un controllo di integrità TCP, definiscilo come segue:
```
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 scelto per la risorsa di controllo di 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 se omesso o impostato su 0. Non è consigliabile impostare un timeout più lungo di checkInterval.
- HEALTHY_THRESHOLD: il numero di probe sequenziali che devono essere superati affinché l'endpoint sia considerato integro. Il valore predefinito è 5 se omesso o impostato su 0.
- TIMEOUT: il tempo in secondi da attendere prima di dichiarare l'errore. Il valore predefinito è 5 se omesso o impostato su 0. Non è consigliabile impostare un timeout più lungo di checkInterval.
- UNHEALTHY_THRESHOLD: il numero di probe sequenziali che non devono riuscire affinché l'endpoint sia considerato non integro. Il valore predefinito è 2 se omesso o impostato su 0.
- 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 aggiungi 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 tradotte da questo servizio di backend, dove ogni porta di destinazione specifica il protocollo, la porta sulla regola di forwarding e la porta sull'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 del controllo di integrità. Questo campo è facoltativo. Includi questo campo solo se stai configurando un ELB per i workload 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 assicurarti che le richieste dello stesso client vengano instradate in modo coerente allo stesso backend. Per abilitare l'affinità sessione per i bilanciatori del carico, crea una policy 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 scelto per la policy del servizio di backend.
- MODE: la modalità di affinità sessione. Sono supportate due modalità:
  - NONE: l'affinità di sessione è disattivata. Le richieste vengono indirizzate a qualsiasi backend disponibile. Si tratta della modalità predefinita.
  - CLIENT_IP_DST_PORT_PROTO: le richieste provenienti dalla stessa tupla di quattro elementi (indirizzo IP di origine, indirizzo IP di destinazione, porta di destinazione e protocollo) vengono indirizzate allo stesso backend.
- RESOURCE_LABEL: il selettore di etichette che seleziona il servizio di backend a cui viene applicata la risorsa BackendServicePolicy nello spazio dei nomi del progetto. Se più risorse BackendServicePolicy corrispondono allo stesso servizio di backend e almeno una di queste policy 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 scelto per la regola di forwarding.
- CIDR: questo campo è facoltativo. Se non specificato, un CIDR IPv4/32 viene riservato automaticamente dal pool di IP di zona. 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 Esempi 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 esposta dall'applicazione effettiva all'interno del container.
Per verificare l'ELB configurato, controlla la condizione Ready su ciascuno degli oggetti creati. Per ottenere l'indirizzo IP assegnato al bilanciatore del carico, descrivi la regola di forwarding:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
```
Per convalidare l'ELB configurato, verifica 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 forwarding.
  - PORT: il numero di porta del campo PROTOCOL_PORT nella regola di forwarding.

API

Crea un ELB che ha come target i workload di pod o VM utilizzando l'API KRM. Questo bilanciatore del carico esterno ha come target tutti i workload del progetto che corrispondono all'etichetta definita nell'oggetto Backend.

Per creare un ELB di zona utilizzando l'API KRM, segui questi passaggi:

Crea una risorsa Backend per definire gli endpoint per l'ELB. Crea risorse Backend per ogni zona in cui si trovano i workload:
```
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 a livello di zona. Per saperne di più, consulta Passa a un contesto di zona.
- 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 workload delle VM. Se una risorsa Backend non include il campo clusterName, le etichette specificate si applicano a tutti i workload del progetto.
Salta questo passaggio se questo ELB è per i workload dei pod. Se stai configurando un ELB per i workload 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 scelto per la risorsa di controllo di integrità, ad esempio my-health-check.
- PORT: la porta su cui viene eseguito il controllo di integrità. Il valore predefinito è 80.
- TIMEOUT: il tempo in secondi da attendere prima di dichiarare l'errore. Il valore predefinito è 5 se omesso o impostato su 0. Non è consigliabile impostare un timeout più lungo di checkInterval.
- CHECK_INTERVAL: l'intervallo di tempo in secondi dall'inizio di un probe all'inizio di quello successivo. Il valore predefinito è 5 se omesso o impostato su 0. Non è consigliabile impostare un timeout più lungo di checkInterval.
- HEALTHY_THRESHOLD: il numero di probe sequenziali che devono essere superati affinché l'endpoint sia considerato integro. Il valore predefinito è 2 se omesso o impostato su 0.
- UNHEALTHY_THRESHOLD: il numero di probe sequenziali che non devono riuscire affinché l'endpoint sia considerato non integro. Il valore predefinito è 2 se omesso o impostato su 0.
Crea un oggetto BackendService utilizzando la risorsa Backend creata in precedenza. Se stai configurando un ELB per i workload 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 workload dei pod.
(Facoltativo) Utilizza l'affinità sessione per gli ELB per assicurarti che le richieste dello stesso client vengano instradate in modo coerente allo stesso backend. Per attivare l'affinità sessione 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 scelto per la policy del servizio di backend.
- MODE: la modalità di affinità sessione. Sono supportate due modalità:
  - NONE: l'affinità di sessione è disattivata. Le richieste vengono indirizzate a qualsiasi backend disponibile. Si tratta della modalità predefinita.
  - CLIENT_IP_DST_PORT_PROTO: le richieste provenienti dalla stessa tupla di quattro elementi (indirizzo IP di origine, indirizzo IP di destinazione, porta di destinazione e protocollo) vengono indirizzate allo stesso backend.
- RESOURCE_LABEL: il selettore di etichette che seleziona il servizio di backend a cui viene applicata la risorsa BackendServicePolicy nello spazio dei nomi del progetto. Se più risorse BackendServicePolicy corrispondono allo stesso servizio di backend e almeno una di queste policy ha l'affinità sessione abilitata, l'affinità sessione per questa risorsa BackendService viene abilitata.
Crea una risorsa ForwardingRule esterna che definisca il VIP in 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:
    name: CIDR_NAME
  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 scelto per la risorsa ForwardingRuleExternal.
- CIDR_NAME: il campo cidrRef è facoltativo. Se non specificato, un CIDR IPv4/32 viene riservato automaticamente dal pool di IP di zona. 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 a livello di zona. Per saperne di più sulle risorse Subnet, consulta Esempi 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 esposta dall'applicazione effettiva 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, verifica la condizione Ready su ciascuno degli oggetti creati. Verifica il traffico con una richiesta curl al 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, segui questi passaggi:

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

Nota: a differenza della 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.

L'oggetto Service seguente è 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 workload di backend.
Il campo port configura la porta di 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 di frontend e backend possono essere diverse.
Nel campo selector della definizione di Service, specifica i pod o le macchine virtuali come workload di backend.

Il selettore definisce i workload da utilizzare come workload di backend per questo servizio, in base alla corrispondenza delle etichette specificate con quelle dei workload. Service può selezionare solo i workload di backend nello stesso progetto e nello stesso cluster in cui definisci Service.

Per ulteriori informazioni sulla selezione dei servizi, consulta https://kubernetes.io/docs/concepts/services-networking/service/.
Salva il file di definizione Service nello stesso progetto dei workload 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 workload di backend.
- ELB_SERVICE_NAME: il nome del servizio ELB.
Dovresti 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 correttamente il servizio ELB.

Crea un ELB globale

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

gdcloud

Crea un ELB che ha come target i workload di pod o VM utilizzando la CLI gdcloud.

Questo bilanciatore del carico esterno ha come target tutti i workload del progetto che corrispondono all'etichetta definita nell'oggetto Backend. La risorsa personalizzata Backend deve avere come ambito una zona.

Per creare un ELB utilizzando la CLI gdcloud, segui questi passaggi:

Crea una risorsa Backend per definire l'endpoint per l'ELB:
```
gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster-name=CLUSTER_NAME \
  --zone=ZONE
```
Sostituisci quanto segue:
- BACKEND_NAME: il nome 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 specificata. Questo campo è facoltativo.
- ZONE: la zona da utilizzare per questa chiamata. Per preimpostare il flag della zona per tutti i comandi che lo richiedono, esegui: gdcloud config set core/zone ZONE. Il flag zone è disponibile solo in ambienti multizona. Questo campo è facoltativo.
Salta questo passaggio se questo ELB è per i workload dei pod. Se stai configurando un ELB per i workload 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 scelto per la risorsa di controllo di 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 se omesso o impostato su 0. Non è consigliabile impostare un timeout più lungo di checkInterval.
- HEALTHY_THRESHOLD: il tempo di attesa prima di dichiarare l'errore. Il valore predefinito è 5 se omesso o impostato su 0.
- TIMEOUT: il tempo in secondi da attendere prima di dichiarare l'errore. Il valore predefinito è 5 se omesso o impostato su 0. Non è consigliabile impostare un timeout più lungo di checkInterval.
- UNHEALTHY_THRESHOLD: il numero di probe sequenziali che non devono riuscire affinché l'endpoint sia considerato non integro. Il valore predefinito è 2 se omesso o impostato su 0.
- PORT: la porta su cui viene eseguito il controllo di integrità. Il valore predefinito è 80. Questo campo è facoltativo.
Crea una risorsa BackendService e aggiungi 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 tradotte da questo servizio di backend, dove ogni porta di destinazione specifica il protocollo, la porta sulla regola di forwarding e la porta sull'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 del controllo di integrità. Questo campo è facoltativo. Includi questo campo solo se stai configurando un ELB per i workload 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 assicurarti che le richieste dello stesso client vengano instradate in modo coerente allo stesso backend. Per abilitare l'affinità sessione per i bilanciatori del carico, crea una policy 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 scelto per la policy del servizio di backend.
- MODE: la modalità di affinità sessione. Sono supportate due modalità:
  - NONE: l'affinità di sessione è disattivata. Le richieste vengono indirizzate a qualsiasi backend disponibile. Si tratta della modalità predefinita.
  - CLIENT_IP_DST_PORT_PROTO: le richieste provenienti dalla stessa tupla di quattro elementi (indirizzo IP di origine, indirizzo IP di destinazione, porta di destinazione e protocollo) vengono indirizzate allo stesso backend.
- RESOURCE_LABEL: il selettore di etichette che seleziona il servizio di backend a cui viene applicata la risorsa BackendServicePolicy nello spazio dei nomi del progetto. Se più risorse BackendServicePolicy corrispondono allo stesso servizio di backend e almeno una di queste policy 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 scelto per la regola di forwarding.
- CIDR: questo campo è facoltativo. Se non specificato, un CIDR IPv4/32 viene riservato automaticamente dal pool di IP globale. 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 globale. 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 esposta dall'applicazione effettiva all'interno del container.
Per verificare l'ELB configurato, controlla la condizione Ready su ciascuno degli oggetti creati. Per ottenere l'indirizzo IP assegnato al bilanciatore del carico, descrivi la regola di forwarding:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
```
Per convalidare l'ELB configurato, verifica 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 --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 ha come target i workload di pod o VM utilizzando l'API KRM. Questo ELB ha come target tutti i workload del progetto che corrispondono all'etichetta definita nell'oggetto Backend. Per creare un ELB di zona utilizzando l'API KRM, segui questi passaggi:

Crea una risorsa Backend per definire gli endpoint per l'ELB. Crea risorse Backend per ogni zona in cui si trovano i workload:
```
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 saperne di più, consulta Passa 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 workload delle VM. Se una risorsa Backend non include il campo clusterName, le etichette specificate si applicano a tutti i workload del progetto.
Salta questo passaggio se questo ELB è per i workload dei pod. Se stai configurando un ELB per i workload 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 scelto per la risorsa di controllo di integrità, ad esempio my-health-check.
- PORT: la porta su cui viene eseguito il controllo di integrità. Il valore predefinito è 80.
- TIMEOUT: il tempo in secondi da attendere prima di dichiarare l'errore. Il valore predefinito è 5 se omesso o impostato su 0. Non è consigliabile impostare un timeout più lungo di checkInterval.
- CHECK_INTERVAL: l'intervallo di tempo in secondi dall'inizio di un probe all'inizio di quello successivo. Il valore predefinito è 5 se omesso o impostato su 0. Non è consigliabile impostare un timeout più lungo di checkInterval.
- HEALTHY_THRESHOLD: il numero di probe sequenziali che devono essere superati affinché l'endpoint sia considerato integro. Il valore predefinito è 2 se omesso o impostato su 0.
- UNHEALTHY_THRESHOLD: il numero di probe sequenziali che non devono riuscire affinché l'endpoint sia considerato non integro. Il valore predefinito è 2 se omesso o impostato su 0.
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 workload 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 tradotte da questa risorsa BackendService. Se utilizzi questo oggetto, fornisci i valori per i seguenti elementi:
  - PORT: la porta esposta dal servizio.
  - PROTOCOL: il protocollo di livello 4 a cui deve corrispondere il traffico. Sono supportati solo i protocolli TCP e UDP.
  - TARGET_PORT: la porta in cui viene tradotto il valore PORT, ad esempio 8080. Il valore di TARGET_PORT non può essere ripetuto in un determinato oggetto. Un esempio di targetPorts potrebbe essere il seguente:
```
targetPorts:
- port: 80
  protocol: TCP
  targetPort: 8080
```
(Facoltativo) Utilizza l'affinità sessione per gli ELB per assicurarti che le richieste dello stesso client vengano instradate in modo coerente allo stesso backend. Per attivare l'affinità sessione 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 scelto per la policy del servizio di backend.
- MODE: la modalità di affinità sessione. Sono supportate due modalità:
  - NONE: l'affinità di sessione è disattivata. Le richieste vengono indirizzate a qualsiasi backend disponibile. Si tratta della modalità predefinita.
  - CLIENT_IP_DST_PORT_PROTO: le richieste provenienti dalla stessa tupla di quattro elementi (indirizzo IP di origine, indirizzo IP di destinazione, porta di destinazione e protocollo) vengono indirizzate allo stesso backend.
- RESOURCE_LABEL: il selettore di etichette che seleziona il servizio di backend a cui viene applicata la risorsa BackendServicePolicy nello spazio dei nomi del progetto. Se più risorse BackendServicePolicy corrispondono allo stesso servizio di backend e almeno una di queste policy ha l'affinità sessione abilitata, l'affinità sessione per questa risorsa BackendService viene abilitata.
Crea una risorsa ForwardingRule esterna che definisca il VIP in 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:
    name: CIDR_NAME
  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_NAME: il campo cidrRef è facoltativo. Se non specificato, un CIDR IPv4/32 viene riservato automaticamente dal pool di IP globale. 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 globale. Per saperne di più sulle risorse Subnet, consulta Risorse personalizzate di esempio.
- 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 esposta dall'applicazione effettiva 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, verifica la condizione Ready su ciascuno degli oggetti creati. Verifica il traffico con una richiesta curl al 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.

Crea un bilanciatore del carico esterno per i cluster standard

Un Application Owner (AO) può creare un servizio Kubernetes di tipo LoadBalancer per esporre i servizi esternamente. Questo servizio può selezionare solo i backend all'interno del cluster standard in cui viene creato. Equivale a un ELB con ambito cluster a livello di zona. L'ELB globale non è supportato per i cluster standard. Per saperne di più, consulta Bilanciatori del carico globali e di zona.

Prima di iniziare

Per configurare i servizi ELB, devi:

Essere proprietario del progetto per cui stai configurando il bilanciatore del carico. Per saperne di più, consulta Crea un progetto.
Disporre di una policy in entrata ProjectNetworkPolicy (PNP) personalizzata per consentire il traffico verso questo servizio ELB. Per saperne di più, consulta Configura PNP per consentire il traffico verso ELB per i cluster standard.
Disporre dei ruoli di identità e accesso necessari:
- Project NetworkPolicy Admin: ha accesso alla gestione delle policy di rete del progetto nello spazio dei nomi del progetto. Chiedi all'amministratore dell'organizzazione IAM di concederti il ruolo Project NetworkPolicy Admin (project-networkpolicy-admin).
- Amministratore del bilanciatore del carico: chiedi all'amministratore dell'organizzazione IAM di concederti il ruolo Amministratore del bilanciatore del carico (load-balancer-admin).

Configura PNP per consentire il traffico verso ELB per i cluster standard

Il seguente file YAML di esempio della policy di rete del progetto consente al traffico proveniente da un workload in un altro progetto di accedere a un workload nel progetto attuale tramite l'ELB.

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-from-client-to-server
  namespace: ${VANILLA_CLUSTER_PROJECT}
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: my-sc-1
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: my-app-ns
        workloads:
          matchLabels:
            app: my-internal-app
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - "$PROJECT_2"
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: my-client
    ports:
    - protocol: TCP
      port: 8080

Crea un ELB di zona per i cluster standard

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

Per creare un servizio ELB, segui questi passaggi:

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

Nota: a differenza della 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.

L'oggetto Service seguente è un esempio di servizio ELB:
```
apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: ELB_SERVICE_NAMESPACE
spec:
  ports:
  - port: PORT
    protocol: TCP
    targetPort: TARGET_PORT
  selector:
    k8s-app: my-app # Example selector, replace with your workload's labels
  type: LoadBalancer
```
Sostituisci quanto segue:
- ELB_SERVICE_NAME: il nome del servizio ELB.
- ELB_SERVICE_NAMESPACE: lo spazio dei nomi nel cluster standard che contiene i workload di backend.
- PORT: la porta esposta dal servizio Kubernetes stesso. Altri servizi o client esterni all'interno del cluster si connetteranno a questa porta sull'indirizzo IP del servizio.
- TARGET_PORT: la porta all'interno del container del pod in cui l'applicazione è in esecuzione e ascolta le connessioni in entrata. Può essere una porta numerica o una porta denominata definita nella specifica del container del pod.
Il campo port configura la porta di 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 di frontend e backend possono essere diverse.
Nel campo selector della definizione Service, specifica le coppie chiave-valore per trovare i workload di backend corrispondenti. Per i cluster standard, solo i pod sono supportati come workload.

che definisci, in base alla corrispondenza delle etichette che specifichi con le etichette dei workload. Service può selezionare solo i workload di backend nello stesso progetto e nello stesso cluster in cui definisci Service.

Per ulteriori informazioni sulla selezione dei servizi, consulta https://kubernetes.io/docs/concepts/services-networking/service/.
Salva la specifica Service in un file YAML. Sostituisci il nome file con ELB_FILE nel comando seguente.
Applica il file di definizione Service al cluster:
```
export KUBECONFIG=KUBECONFIG_PATH
kubectl apply -f ELB_FILE
```
Sostituisci quanto segue:
- ELB_FILE:il nome del file di definizione Service per il servizio ELB.
- KUBECONFIG_PATH: il percorso del file kubeconfig per il cluster standard.
Puoi ottenere gli indirizzi IP del servizio ELB visualizzando lo stato del servizio:
```
kubectl -n ELB_SERVICE_NAMESPACE get svc ELB_SERVICE_NAME
```
Sostituisci quanto segue:
- ELB_SERVICE_NAMESPACE: lo spazio dei nomi che contiene i workload di backend.
- ELB_SERVICE_NAME: il nome del servizio ELB.
Dovresti ottenere un output simile al seguente esempio:
```
NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      203.0.1.11      1235:31931/TCP   22h
```
EXTERNAL-IP è l'indirizzo IP del servizio accessibile dall'esterno dell'organizzazione.

Seleziona una VM come backend per un bilanciatore del carico

Per collegare una VM al bilanciatore del carico:

Assicurati che la VM abbia un'etichetta corrispondente al selettore di etichette utilizzato nella configurazione del bilanciatore del carico.

Ad esempio, se la VM non ha un'etichetta appropriata, puoi aggiungere alla VM l'etichetta specificata dall'oggetto di backend della zona corrispondente:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL
```
Sostituisci quanto segue:
- LABEL: un'etichetta corrispondente a LabelSelector nella configurazione del bilanciatore del carico, ad esempio app=server.
- VM_NAME: il nome della macchina virtuale da collegare.
- PROJECT_NAME: il nome del progetto.
Assicurati che il server sia in ascolto sulla stessa porta specificata nell'oggetto HealthCheck.

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

Crea un bilanciatore del carico esterno per i cluster condivisi

Prima di iniziare

Configura PNP per consentire il traffico verso ELB

Crea un ELB di zona

gdcloud

API

Servizio Kubernetes

Crea un ELB globale

gdcloud

API

Crea un bilanciatore del carico esterno per i cluster standard

Prima di iniziare

Configura PNP per consentire il traffico verso ELB per i cluster standard

Crea un ELB di zona per i cluster standard

Seleziona una VM come backend per un bilanciatore del carico

Configura i bilanciatori del carico esterni