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 qualsiasi endpoint al di fuori dell'organizzazione.

Per impostazione predefinita, puoi accedere ai servizi ILB all'interno dello stesso progetto da qualsiasi cluster nell'organizzazione. I criteri di rete del progetto predefiniti non ti consentono di accedere a nessuna risorsa del progetto dall'esterno del progetto e questa limitazione si applica anche ai servizi ILB. Se l'amministratore della piattaforma (PA) configura criteri 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 i bilanciatori del carico interni, 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.

  • I ruoli di identità e accesso necessari:

    • Chiedi all'amministratore IAM dell'organizzazione di concederti il ruolo Amministratore bilanciatore del carico (load-balancer-admin).
    • Per i bilanciatori del carico interni globali, chiedi all'amministratore IAM dell'organizzazione di concederti il ruolo Amministratore bilanciamento del carico globale (global-load-balancer-admin). Per ulteriori informazioni, consulta Descrizioni dei ruoli predefiniti.

Crea un bilanciatore del carico interno

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

Crea bilanciatori del carico interni utilizzando tre metodi diversi in GDC:

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

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

Crea un bilanciatore del carico interno di zona

Crea un bilanciatore del carico interno zonale utilizzando gcloud CLI, l'API KRM o il servizio Kubernetes nel cluster Kubernetes:

gdcloud

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

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

Per creare un bilanciamento del carico interno utilizzando gcloud CLI:

  1. Crea una risorsa Backend per definire l'endpoint per il bilanciamento del carico interno:

    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.

  2. Salta questo passaggio se questo bilanciamento del carico interno è per i workload dei pod. Se stai configurando un bilanciatore del carico interno per i carichi di lavoro delle VM, definisci un controllo di integrità per il bilanciatore del carico interno:

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --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 bilanciamento del carico interno.

  3. 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_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 bilanciamento del carico interno per i carichi di lavoro 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 definisca il VIP a 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 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.

  6. Per convalidare il bilanciamento del carico interno configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Verifica il traffico con una richiesta curl all'indirizzo 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 bilanciamento del carico interno che abbia come target carichi di lavoro di pod o VM utilizzando l'API KRM. Questo bilanciatore del carico interno ha come target tutti i carichi di lavoro nel progetto che corrispondono all'etichetta definita nell'oggetto Backend.

Per creare un bilanciatore del carico interno zonale utilizzando l'API KRM:

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

    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 saperne di più, 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.

    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 bilanciamento del carico interno è per i workload dei pod. Se stai configurando un bilanciatore del carico interno per i carichi di lavoro delle VM, definisci un controllo di integrità per il bilanciatore del carico interno:

    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.

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

  4. Crea una risorsa ForwardingRule interna che definisca l'IP virtuale a 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: CIDR
  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: 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.
    • 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

  5. Per convalidare il bilanciamento del carico interno configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Verifica il traffico con una richiesta curl all'indirizzo 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 bilanciatori del carico interni in GDC creando un oggetto Kubernetes Service di tipo LoadBalancer in un cluster Kubernetes. Questo bilanciamento del carico interno ha come target solo i carichi di lavoro nel cluster in cui viene creato l'oggetto Service.

Per creare un bilanciamento del carico interno con l'oggetto Service:

  1. Crea un file YAML per la definizione Service del 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 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.

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

  3. Salva il file di definizione Service nello stesso progetto dei carichi di lavoro 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 di bilanciamento del carico interno.

    Quando crei un servizio ILB, al servizio viene assegnato 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 carichi di lavoro di backend.
    • ILB_SERVICE_NAME: il nome del servizio ILB.

    Devi 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. Ora è possibile accedere a questo indirizzo IP da altri cluster dell'organizzazione, in conformità con le norme di rete del progetto del progetto.

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

    GDC supporta i nomi Domain Name System (DNS) 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 bilanciamento del carico interno globale

Crea un bilanciamento del carico interno globale utilizzando gcloud CLI o l'API KRM.

gdcloud

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

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

Per creare un bilanciamento del carico interno utilizzando gcloud CLI:

  1. Crea una risorsa Backend per definire l'endpoint per il bilanciamento del carico interno:

    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.

  2. Salta questo passaggio se questo bilanciamento del carico interno è per i workload dei pod. Se stai configurando un bilanciatore del carico interno per i carichi di lavoro delle VM, definisci un controllo di integrità per il bilanciatore del carico interno:

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --global

    Sostituisci quanto segue:

    • HEALTH_CHECK_NAME: il nome 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.

  3. 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 bilanciamento del carico interno per i carichi di lavoro 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 definisca il VIP a 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 che hai scelto per la regola di forwarding.
    • CIDR: il nome di una risorsa Subnet nello stesso spazio dei nomi di questa regola di forwarding. Una risorsa Subnet rappresenta le informazioni su richiesta e allocazione di una subnet globale. Per saperne di più sulle risorse Subnet, consulta Esempio di risorse personalizzate. Se non specificato, viene riservato automaticamente un CIDR IPv4/32 dal pool 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 che l'applicazione effettiva espone all'interno del container.

  6. Per convalidare il bilanciamento del carico interno configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Verifica il traffico con una richiesta curl all'indirizzo 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 bilanciamento del carico interno che abbia come target carichi di lavoro di pod o VM utilizzando l'API KRM. Questo bilanciatore del carico interno ha come target tutti i workload nel progetto che corrispondono all'etichetta definita nell'oggetto backend. Per creare un bilanciatore del carico interno zonale utilizzando l'API KRM:

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

    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.

    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 bilanciamento del carico interno è per i workload dei pod. Se stai configurando un bilanciatore del carico interno per i carichi di lavoro delle VM, definisci un controllo di integrità per il bilanciatore del carico interno:

    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 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 bilanciamento del carico interno 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 carichi di lavoro 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 bilanciamento 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 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

  4. Crea una risorsa ForwardingRule interna 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: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  Name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef: CIDR
  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: il nome di una risorsa Subnet nello stesso spazio dei nomi di questa regola di forwarding. Una risorsa Subnet rappresenta le informazioni su richiesta e allocazione di una subnet globale. Per saperne di più sulle risorse Subnet, consulta Esempio di risorse personalizzate. Se non specificato, viene riservato automaticamente un CIDR IPv4/32 dal pool 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 che l'applicazione effettiva espone all'interno del container.

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

      ports:
- port: 80
  protocol: TCP

  5. Per convalidare il bilanciamento del carico interno configurato, conferma la condizione Ready su ciascuno degli oggetti creati. Verifica il traffico con una richiesta curl all'indirizzo 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.