Configura i bilanciatori del carico interni

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

Per impostazione predefinita, puoi accedere ai servizi ILB all'interno dello stesso progetto da qualsiasi cluster dell'organizzazione. La policy di rete del progetto predefinita non consente di accedere alle risorse del progetto dall'esterno del progetto e questa limitazione si applica anche ai servizi ILB. Se l'amministratore della piattaforma (PA) configura policy di rete del progetto che consentono l'accesso al tuo progetto da altri progetti, il servizio ILB è accessibile anche da questi altri progetti nella stessa organizzazione.

Prima di iniziare

Per configurare gli ILB, devi:

  • Essere proprietario del progetto per cui stai configurando il bilanciatore del carico. Per saperne di più, consulta Crea un progetto.

  • Disporre dei ruoli di identità e accesso necessari:

    • Chiedi all'amministratore dell'organizzazione IAM di concederti il ruolo Amministratore bilanciatore del carico (load-balancer-admin).
    • Per i bilanciatori del carico interni 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.

  • Conoscere il tipo di cluster che ospita i tuoi workload. Esistono istruzioni distinte per la configurazione degli ILB per i cluster condivisi e standard.

Crea un bilanciatore del carico interno per i cluster condivisi

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

Crea ILB utilizzando tre metodi diversi in GDC:

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 dal cluster Kubernetes.

Crea un ILB di zona

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

gdcloud

Crea un bilanciatore del carico interno che ha come target i workload di pod o VM utilizzando la CLI gdcloud.

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

Per creare un bilanciatore del carico interno utilizzando la CLI gdcloud, segui questi passaggi:

  1. Crea una risorsa Backend per definire l'endpoint per l'ILB:

    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.

  2. Salta questo passaggio se questo ILB è per i workload dei pod. Se stai configurando un bilanciatore del carico interno per i workload delle VM, definisci il tipo di controllo di integrità per il bilanciatore del carico interno. 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 ILB.

  3. 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_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 bilanciatore del carico interno per i workload delle VM.

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

  5. Crea una risorsa ForwardingRule interna che definisce il 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 \
  --zone=ZONE \
  --project=PROJECT_NAME

    Sostituisci quanto segue:

    • BACKEND_SERVICE_NAME: il nome del servizio di backend.
    • FORWARDING_RULE_INTERNAL_NAME con 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.

  6. Per convalidare l'ILB 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_INTERNAL_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 ILB che ha come target i workload di pod o VM utilizzando l'API KRM. Questo ILB ha come target tutti i workload del progetto che corrispondono all'etichetta definita nell'oggetto Backend.

Per creare un ILB a livello di zona utilizzando l'API KRM, segui questi passaggi:

  1. Crea una risorsa Backend per definire gli endpoint per l'ILB. 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 a livello 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.

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

  2. Salta questo passaggio se questo ILB è per i workload dei pod. Se stai configurando un ILB per i workload delle VM, definisci un controllo di integrità per l'ILB:

    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.

  3. Crea un oggetto BackendService utilizzando la risorsa Backend creata in precedenza. Se stai configurando un bilanciatore del carico interno 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 bilanciatore del carico di rete passthrough interno per i workload dei pod.

  4. Crea una risorsa ForwardingRule interna che definisce il VIP in cui è disponibile il servizio.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    Sostituisci quanto segue:

    • FORWARDING_RULE_INTERNAL_NAME: il nome scelto per la risorsa ForwardingRuleInternal.
    • 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 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

  5. Per convalidare l'ILB 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 forwardingruleinternal -n PROJECT_NAME

      L'output è simile al seguente:

      NAME           BACKENDSERVICE                               CIDR              READY
ilb-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 ILB in GDC creando un oggetto Kubernetes Service di tipo LoadBalancer in un cluster Kubernetes. Questo ILB ha come target solo i workload nel cluster in cui viene creato l'oggetto Service.

Per creare un bilanciatore del carico interno con l'oggetto Service, segui questi passaggi:

  1. Crea un file YAML per la definizione Service di tipo LoadBalancer. Devi progettare il servizio ILB come interno utilizzando l'annotazione networking.gke.io/load-balancer-type: internal.

    Il seguente oggetto Service è un esempio di servizio ILB:

    apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

    Sostituisci quanto segue:

    • ILB_SERVICE_NAME: il nome del servizio ILB.
    • 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.

  2. Nel campo selector della definizione 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/.

  3. Salva il file di definizione Service nello stesso progetto dei workload di backend. Il servizio ILB può selezionare solo i workload che si trovano nello stesso cluster della definizione Service.

  4. Applica il file di definizione Service al cluster:

    kubectl apply -f ILB_FILE

    Sostituisci ILB_FILE con il nome del file di definizione Service per il servizio ILB.

    Quando crei un servizio ILB, questo riceve un indirizzo IP. Puoi ottenere l'indirizzo IP del servizio ILB visualizzando lo stato del servizio:

    kubectl -n PROJECT_NAME get svc ILB_SERVICE_NAME

    Sostituisci quanto segue:

    • PROJECT_NAME: lo spazio dei nomi del progetto che contiene i workload di backend.
    • ILB_SERVICE_NAME: il nome del servizio ILB.

    Dovresti ottenere un output simile al seguente esempio:

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      10.0.0.1        1234:31930/TCP   22h

    I campi CLUSTER-IP e EXTERNAL-IP devono mostrare lo stesso valore, ovvero l'indirizzo IP del servizio ILB. Questo indirizzo IP è ora accessibile da altri cluster dell'organizzazione, in conformità con le policy di rete del progetto.

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

    GDC supporta i nomi DNS (Domain Name System) per i servizi. Tuttavia, questi nomi funzionano solo nello stesso cluster per i servizi ILB. Da altri cluster, devi utilizzare l'indirizzo IP per accedere al servizio ILB.

Crea un bilanciatore del carico interno globale

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

gdcloud

Crea un bilanciatore del carico interno che ha come target i workload di pod o VM utilizzando la CLI gdcloud.

Questo ILB 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 bilanciatore del carico interno utilizzando la CLI gdcloud, segui questi passaggi:

  1. Crea una risorsa Backend per definire l'endpoint per l'ILB:

    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.

  2. Salta questo passaggio se questo ILB è per i workload dei pod. Se stai configurando un ILB per i workload delle VM, definisci un controllo di integrità per l'ILB:

    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.

  3. 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 bilanciatore del carico interno per i workload delle VM.

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

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

  5. Crea una risorsa ForwardingRule interna che definisce il 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_NAME \
  --global

    Sostituisci quanto segue:

    • FORWARDING_RULE_INTERNAL_NAME: il nome scelto per la regola di forwarding.
    • CIDR: il nome di una risorsa Subnet nello stesso namespace 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. Se non specificato, viene prenotato automaticamente un CIDR IPv4/32 dal pool di IP globale. Questo campo è facoltativo.
    • 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.

  6. Per convalidare l'ILB 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_INTERNAL_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 ILB che ha come target i workload di pod o VM utilizzando l'API KRM. Questo ILB ha come target tutti i workload del progetto che corrispondono all'etichetta definita nell'oggetto Backend. Per creare un ILB a livello di zona utilizzando l'API KRM, segui questi passaggi:

  1. Crea una risorsa Backend per definire gli endpoint per l'ILB. Crea risorse Backend per ogni zona in cui si trovano i workload:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.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.

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

  2. Salta questo passaggio se questo ILB è per i workload dei pod. Se stai configurando un ILB per i workload delle VM, definisci un controllo di integrità per l'ILB:

    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

    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 ILB globale, crea il controllo di integrità nell'API globale.

  3. Crea un oggetto BackendService utilizzando la risorsa Backend creata in precedenza. Se stai configurando un bilanciatore del carico interno 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 bilanciatore del carico interno 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

  4. Crea una risorsa ForwardingRule interna che definisce il VIP in cui è disponibile il servizio.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    Sostituisci quanto segue:

    • FORWARDING_RULE_INTERNAL_NAME: il nome scelto per la risorsa ForwardingRuleInternal.
    • CIDR_NAME: il nome di una risorsa Subnet nello stesso namespace 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. Se non specificato, viene prenotato automaticamente un CIDR IPv4/32 dal pool di IP globale. Questo campo è facoltativo.
    • 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

  5. Per convalidare l'ILB 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 forwardingruleinternal -n PROJECT_NAME

      L'output è simile al seguente:

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

    2. Testa 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 interno per i cluster standard

Puoi creare ILB di zona per i cluster standard; gli ILB globali non sono supportati. L'ambito degli ILB di zona è limitato alla zona specificata al momento della creazione. Per saperne di più, consulta Bilanciatori del carico globali e di zona.

Crea ILB di zona per i cluster standard utilizzando il servizio Kubernetes direttamente nel cluster Kubernetes. Puoi scegliere come target solo i workload nel cluster in cui viene creato l'oggetto Service quando utilizzi il servizio Kubernetes direttamente dal cluster Kubernetes.

Crea un ILB di zona per i cluster standard

Puoi creare ILB in GDC creando un oggetto Kubernetes Service di tipo LoadBalancer in un cluster Kubernetes. Questo ILB ha come target solo i workload nel cluster in cui viene creato l'oggetto Service.

Per creare un bilanciatore del carico interno con l'oggetto Service, segui questi passaggi:

  1. Crea un file YAML per la definizione Service di tipo LoadBalancer. Devi progettare il servizio ILB come interno utilizzando l'annotazione networking.gke.io/load-balancer-type: internal.

    Il seguente oggetto Service è un esempio di servizio ILB:

    apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: ILB_SERVICE_NAMESPACE
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

    Sostituisci quanto segue:

    • ILB_SERVICE_NAME: il nome del servizio ILB.
    • ILB_SERVICE_NAMESPACE: lo spazio dei nomi 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.

  2. Nel campo selector della definizione Service, specifica i pod che fungeranno da 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/.

  3. Salva la specifica Service in un file YAML. Sostituisci il nome file con ILB_FILE nel comando seguente. Il servizio ILB può selezionare solo i workload che si trovano nello stesso cluster della definizione Service.

  4. Applica il file di definizione Service al cluster:

    export KUBECONFIG=KUBECONFIG_PATH
kubectl apply -f ILB_FILE

    Sostituisci quanto segue:

    • ILB_FILE:il nome del file di definizione Service per il servizio ILB.
    • KUBECONFIG_PATH: il percorso del file kubeconfig per il cluster standard.

    Quando crei un servizio ILB, questo riceve un indirizzo IP. Puoi ottenere l'indirizzo IP del servizio ILB visualizzando lo stato del servizio:

    kubectl -n ILB_SERVICE_NAMESPACE get svc ILB_SERVICE_NAME

    Sostituisci quanto segue:

    • ILB_SERVICE_NAMESPACE: lo spazio dei nomi che contiene i workload di backend.
    • ILB_SERVICE_NAME: il nome del servizio ILB.
    • KUBECONFIG_PATH: il percorso del file kubeconfig per il cluster standard.

    Otterrai un output simile al seguente esempio:

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      198.51.0.1        1234:31930/TCP   22h

    Questo indirizzo IP è ora accessibile da altri cluster dell'organizzazione, in conformità con le policy di rete del progetto di cui dispone il progetto.

Seleziona una VM come backend per un bilanciatore del carico

Per collegare una VM al bilanciatore del carico:

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

  2. Assicurati che il server sia in ascolto sulla stessa porta specificata nell'oggetto HealthCheck.