Crea un bilanciatore del carico esterno basato su un servizio di backend

Questa pagina mostra come eseguire il deployment di un servizio LoadBalancer esterno che crea un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend. Prima di leggere questa pagina, assicurati di avere familiarità con quanto segue:

Per saperne di più sui bilanciatori del carico di rete passthrough esterni regionali in generale, consulta Bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

Requisiti

  • Questo tutorial utilizza spec.loadBalancerClass per creare un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend con backend NEG GCE_VM_IP. Questo tutorial richiede GKE versione 1.33.1-gke.1779000 o successive perché spec.loadBalancerClass richiede GKE versione 1.33.1-gke.1779000 o successive. La versione 1.33.1-gke.1779000 o successive supera anche i requisiti minimi della versione GKE per i backend NEG o la funzionalità di bilanciatore del carico ponderato.

  • Se il cluster utilizza una versione precedente alla 1.36, il componente aggiuntivo HttpLoadBalancing deve essere abilitato nel cluster. Questo componente aggiuntivo è attivo per impostazione predefinita. Per saperne di più, consulta Prerequisito HttpLoadBalancing.

  • Per abilitare Cloud Logging per un servizio LoadBalancer esterno, il tuo cluster GKE deve utilizzare la versione 1.36.0-gke.2459000 o successiva.

  • Per utilizzare gli indirizzi IPv6 Bring Your Own IP (BYOIP) con un servizio LoadBalancer esterno IPv6 single-stack, il tuo cluster GKE deve utilizzare la versione 1.37.1-gke.2097000 o successive.

Scegli un cluster

Puoi creare un nuovo cluster o sceglierne uno esistente che soddisfi i requisiti.

Crea un nuovo cluster

Autopilot

Per creare un nuovo cluster Autopilot:

gcloud container clusters create-auto CLUSTER_NAME \
    --release-channel=RELEASE_CHANNEL \
    --cluster-version=VERSION \
    --location=COMPUTE_LOCATION

Sostituisci quanto segue:

Per disabilitare la creazione automatica delle regole firewall VPC per i servizi LoadBalancer, includi il flag --disable-l4-lb-firewall-reconciliation. Per saperne di più, consulta Regole firewall gestite dall'utente per i servizi LoadBalancer di GKE.

Standard

Per creare un nuovo cluster Standard:

gcloud container clusters create CLUSTER_NAME \
    --release-channel=RELEASE_CHANNEL \
    --cluster-version=VERSION \
    --location=COMPUTE_LOCATION

Sostituisci quanto segue:

Per disabilitare la creazione automatica delle regole firewall VPC per i servizi LoadBalancer, includi il flag --disable-l4-lb-firewall-reconciliation. Per saperne di più, consulta Regole firewall gestite dall'utente per i servizi LoadBalancer di GKE.

Esegui l'upgrade di un cluster esistente

Utilizza gcloud CLI per aggiornare un cluster esistente:

gcloud container clusters upgrade CLUSTER_NAME \
    --cluster-version=VERSION \
    --master \
    --location=COMPUTE_LOCATION

Sostituisci quanto segue:

Per disabilitare la creazione automatica delle regole firewall VPC per i servizi LoadBalancer, includi il flag --disable-l4-lb-firewall-reconciliation. Per saperne di più, consulta Regole firewall gestite dall'utente per i servizi LoadBalancer di GKE.

Esegui il deployment di un workload di esempio

Esegui il deployment del seguente workload di esempio che fornisce i pod di distribuzione per il servizio LoadBalancer esterno.

  1. Salva il seguente deployment di esempio come store-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: store
spec:
  replicas: 20
  selector:
    matchLabels:
      app: store
  template:
    metadata:
      labels:
        app: store
    spec:
      containers:
      - image: registry.k8s.io/echoserver:1.10
        imagePullPolicy: Always
        name: echoserver
        ports:
          - name: http
            containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP

  2. Applica il manifest al cluster:

    kubectl apply -f store-deployment.yaml

  3. Verifica che siano presenti 20 pod di distribuzione per il deployment:

    kubectl get pods

    L'output è simile al seguente:

    NAME                     READY   STATUS    RESTARTS   AGE
store-cdb9bb4d6-s25vw      1/1     Running   0          10s
store-cdb9bb4d6-vck6s      1/1     Running   0          10s
....

Crea il servizio LoadBalancer esterno

  1. Esponi il workload di esempio creando un servizio LoadBalancer esterno.

    1. Salva il seguente manifest del servizio come store-v1-lb-svc.yaml:

      apiVersion: v1
kind: Service
metadata:
  name: store-v1-lb-svc
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  selector:
    app: store
  ports:
  - name: tcp-port
    protocol: TCP
    port: 8080
    targetPort: 8080

    2. Applica il manifest al cluster:

      kubectl apply -f store-v1-lb-svc.yaml

    Tieni presente quanto segue in merito a questo manifest di esempio:

    • Se il cluster esegue GKE dalla versione 1.33.1-gke.1779000 alla versione 1.36, devi impostare il campo spec.loadBalancerClass sul valore networking.gke.io/l4-regional-external quando il manifest viene applicato per la prima volta al cluster. Questo campo indica a GKE di creare un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend. In GKE 1.37 e versioni successive, questa configurazione è il comportamento predefinito e il campo non è obbligatorio. I bilanciatori del carico di rete passthrough esterni regionali basati su servizi di backend sono obbligatori per supportare funzionalità come il traffico IPv6 e il bilanciamento del carico ponderato.

    • GKE utilizza backend NEG GCE_VM_IP o backend di gruppi di istanze non gestite, a seconda della versione del cluster. Nei cluster con versione 1.32.2-gke.1652000, il bilanciatore del carico di rete passthrough esterno regionale basato sui servizio di backend utilizza i NEG GCE_VM_IP. Nelle versioni precedenti, il bilanciatore del carico di rete passthrough esterno regionale basato su servizi di backend utilizza gruppi di istanze non gestite.

    • Questo campo spec.loadBalancerClass è immutabile e deve essere impostato quando crei il servizio. Poiché questo campo è immutabile, non puoi aggiungerlo o modificarlo nel manifest di un servizio LoadBalancer esistente. Qualsiasi tentativo di farlo genererà un errore e l'aggiornamento del servizio non andrà a buon fine.

    • Per creare un servizio IPv6 a stack singolo in un cluster a doppio stack, imposta il valore del campo spec.ipFamilyPolicy su SingleStack e il valore del campo spec.ipFamilies su IPv6. In un cluster IPv6 a stack singolo, questi sono i valori predefiniti e puoi ometterli. Per saperne di più, consulta Servizi LoadBalancer IPv6.

Crea un servizio LoadBalancer esterno su un cluster IPv6 a stack singolo

Quando crei un servizio LoadBalancer esterno IPv6 a stack singolo su un cluster IPv6 a stack singolo o su un cluster a doppio stack, la subnet utilizzata dal bilanciatore del carico dipende dal fatto che la subnet del nodo del cluster utilizzi un tipo di accesso IPv6 EXTERNAL o INTERNAL. In un cluster dual-stack, devi impostare il valore del campo spec.ipFamilyPolicy su SingleStack e il valore del campo spec.ipFamilies su IPv6 (in un cluster IPv6 single-stack, questi sono i valori predefiniti e puoi ometterli). I servizi LoadBalancer esterni IPv6 utilizzano sempre un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend nel livello Premium. I seguenti esempi impostano esplicitamente il campo spec.loadBalancerClass su networking.gke.io/l4-regional-external, anche se questa variante del bilanciatore del carico è l'impostazione predefinita in GKE versione 1.37 e successive:

  • Cluster con nodi esterni (tipo di accesso GUA EXTERNAL): se i nodi del cluster vengono eseguiti su una subnet esterna con indirizzi Global Unicast Address (GUA), il bilanciatore del carico esterno utilizza automaticamente la subnet dei nodi esistente. Crea il servizio senza annotazioni di subnet personalizzate:

    apiVersion: v1
kind: Service
metadata:
  name: ext-ipv6-svc
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: store
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080

  • Cluster con nodi interni (tipo di accesso ULA INTERNAL): se i nodi del cluster vengono eseguiti su una subnet interna con indirizzi unicast locali univoci (ULA), un bilanciatore del carico esterno non può utilizzare direttamente la subnet. Devi eseguire il provisioning di una subnet IPv6 esterna (EXTERNAL) dedicata e farvi riferimento utilizzando l'annotazione networking.gke.io/load-balancer-subnet nel tuo servizio:

    1. Crea una subnet IPv6 esterna dedicata:

      gcloud compute networks subnets create SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=EXTERNAL \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

      Sostituisci quanto segue:

      • SUBNET_NAME: il nome della subnet da creare.
      • NETWORK_NAME: il nome della rete VPC in cui crei questa subnet.
      • COMPUTE_REGION: la regione di Compute Engine per la subnet.

    2. Crea il servizio facendo riferimento al nome della subnet dedicata nell'annotazione networking.gke.io/load-balancer-subnet:

      apiVersion: v1
kind: Service
metadata:
  name: ext-ipv6-svc
  annotations:
    networking.gke.io/load-balancer-subnet: SUBNET_NAME
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: store
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080

  1. Verifica l'indirizzo IP del servizio assegnato:

    kubectl get svc ext-ipv6-svc

    L'output conferma che le colonne CLUSTER-IP e EXTERNAL-IP (un indirizzo GUA pubblico) sono compilate:

    NAME           TYPE           CLUSTER-IP                          EXTERNAL-IP                      PORT(S)        AGE
ext-ipv6-svc   LoadBalancer   2600:2d00:0:4:1a1e:d3b3:de4d:c401   2600:1900:4000:2714:8000:0:0:0   80:31114/TCP   51s

Per saperne di più, consulta Servizi LoadBalancer IPv6.

Utilizza Bring Your Own IPv6 (BYOIPv6)

In GKE versione 1.37.1-gke.2097000 e successive, puoi configurare un servizio LoadBalancer esterno IPv6 a stack singolo per utilizzare indirizzi IPv6 Bring Your Own (BYOIPv6) da un sottoprefisso IPv6 regionale di un prefisso delegato pubblico (PDP) in modalità EXTERNAL_IPV6_FORWARDING_RULE_CREATION.

Prima di creare il servizio, assicurati di soddisfare i seguenti requisiti:

  • Il cluster esegue GKE versione 1.37.1-gke.2097000 o successiva. Il cluster può essere IPv6 a stack singolo o a doppio stack (il servizio deve essere IPv6 a stack singolo in entrambi i casi) e la subnet del cluster può avere un tipo di accesso IPv6 INTERNAL o EXTERNAL; non è richiesto un intervallo di subnet IPv6 esterno perché l'intervallo di indirizzi proviene dal prefisso delegato pubblico.
  • Hai un sottoprefisso IPv6 regionale in modalità EXTERNAL_IPV6_FORWARDING_RULE_CREATION con una lunghezza del prefisso allocabile di /96 e lo stato ANNOUNCED, nella stessa regione del tuo cluster. Per le istruzioni, consulta Crea sottoprofissi IPv6.

  • L'agente di servizio GKE (service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com) ha il ruolo Compute Public IP Admin (roles/compute.publicIpAdmin) nel progetto proprietario del prefisso delegato pubblico. Per concedere il ruolo, esegui questo comando:

    gcloud projects add-iam-policy-binding PDP_PROJECT_ID \
    --member="serviceAccount:service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com" \
    --role="roles/compute.publicIpAdmin"

    Sostituisci quanto segue:

    • PDP_PROJECT_ID: l'ID del progetto proprietario del prefisso delegato pubblico.
    • PROJECT_NUMBER: il numero del progetto che contiene il tuo cluster.

  • Il servizio è un servizio IPv6 a stack singolo (spec.ipFamilyPolicy: SingleStack e spec.ipFamilies: ["IPv6"]) che imposta il campo spec.loadBalancerClass su networking.gke.io/l4-regional-external e utilizza il livello Premium. I servizi a doppio stack, i servizi IPv4 e il livello Standard non sono supportati con BYOIPv6.

  • Il servizio non include l'annotazione networking.gke.io/load-balancer-subnet, che non può essere combinata con l'annotazione networking.gke.io/ip-collection-v6.

Scegli se allocare un intervallo di indirizzi BYOIPv6 esterni temporanei o utilizzare un intervallo di indirizzi BYOIPv6 esterni statici prenotati:

  • Intervallo di indirizzi BYOIPv6 esterni temporanei: aggiungi l'annotazione networking.gke.io/ip-collection-v6 al manifest del servizio e impostala sull'URL completo della risorsa o sul percorso parziale della risorsa del sottoprefisso regionale:

    apiVersion: v1
kind: Service
metadata:
  name: ext-byoipv6-svc
  annotations:
    networking.gke.io/ip-collection-v6: "projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME"
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: store
  ports:
  - name: tcp-port
    protocol: TCP
    port: 80
    targetPort: 8080

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del progetto che contiene il sottoprefisso.
    • REGION: la regione del tuo cluster.
    • SUB_PREFIX_NAME: il nome del sottoprefisso regionale in modalità EXTERNAL_IPV6_FORWARDING_RULE_CREATION.

    Se in un secondo momento modifichi l'annotazione networking.gke.io/ip-collection-v6, GKE ricrea la regola di forwarding IPv6 con un nuovo indirizzo dal nuovo prefisso, interrompendo brevemente il traffico verso il servizio. Se rimuovi l'annotazione, il servizio torna a un indirizzo fornito da Google da una subnet con un intervallo IPv6 esterno. Se la subnet del cluster ha un intervallo IPv6 interno, aggiungi contemporaneamente l'annotazione networking.gke.io/load-balancer-subnet.

  • Intervallo di indirizzi BYOIPv6 esterno statico: prenota un intervallo di indirizzi IPv6 /96 esterno statico regionale dal sottoprefisso e fai riferimento utilizzando l'annotazione networking.gke.io/load-balancer-ip-addresses:

    1. Crea un intervallo di indirizzi IPv6 esterni statici regionali dal tuo sottoprefisso:

      gcloud compute addresses create STATIC_BYOIPV6_NAME \
    --region=REGION \
    --ip-version=IPV6 \
    --endpoint-type=NETLB \
    --ip-collection=projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME

      Sostituisci quanto segue:

      • STATIC_BYOIPV6_NAME: un nome per la risorsa dell'indirizzo IPv6 statico.
      • REGION: la regione del tuo cluster.
      • PROJECT_ID: l'ID del progetto che contiene il sottoprefisso.
      • SUB_PREFIX_NAME: il nome del sottoprefisso regionale in modalità EXTERNAL_IPV6_FORWARDING_RULE_CREATION.

      L'annotazione networking.gke.io/ip-collection-v6 è facoltativa quando utilizzi un intervallo di indirizzi BYOIPv6 esterni statici. Se imposti questa annotazione, deve fare riferimento allo stesso sottoprefisso da cui hai prenotato l'intervallo di indirizzi.

    2. Fai riferimento al nome della risorsa dell'indirizzo IPv6 statico prenotato nel manifest del servizio:

      apiVersion: v1
kind: Service
metadata:
  name: ext-static-byoipv6-svc
  annotations:
    networking.gke.io/load-balancer-ip-addresses: STATIC_BYOIPV6_NAME
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: store
  ports:
  - name: tcp-port
    protocol: TCP
    port: 80
    targetPort: 8080

Per saperne di più, consulta Bring Your Own IP (BYOIPv6).

Abilita il bilanciamento del carico ponderato

Per distribuire le nuove connessioni in modo proporzionale ai nodi in base al numero di pod di gestione, pronti e non in fase di terminazione presenti su ciascun nodo, attiva il bilanciamento del carico ponderato aggiungendo l'annotazione networking.gke.io/weighted-load-balancing: "pods-per-node" al manifest del servizio.

  1. Aggiungi l'annotazione networking.gke.io/weighted-load-balancing: "pods-per-node" al manifest del servizio store-v1-lb-svc.yaml e assicurati di impostare anche il valore externalTrafficPolicy: Local in modo che abbia il seguente aspetto:

    apiVersion: v1
kind: Service
metadata:
  name: store-v1-lb-svc
  annotations:
    networking.gke.io/weighted-load-balancing: "pods-per-node"
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  externalTrafficPolicy: Local
  selector:
    app: store
  ports:
  - name: tcp-port
    protocol: TCP
    port: 8080
    targetPort: 8080

  2. Applica il manifest al cluster:

    kubectl apply -f store-v1-lb-svc.yaml

Tieni presente quanto segue in merito a questo esempio di bilanciamento del carico ponderato:

  • Il manifest del servizio utilizza externalTrafficPolicy: Local. Se non hai bisogno di attivare il bilanciamento del carico ponderato, puoi utilizzare anche externalTrafficPolicy: Cluster. Per informazioni dettagliate su come externalTrafficPolicy definisce il raggruppamento dei nodi, su quali nodi superano i controlli di integrità del bilanciatore del carico e su come vengono elaborati i pacchetti, consulta Concetti relativi ai servizi LoadBalancer.

  • Se attivi il bilanciamento del carico ponderato, GKE non ti impedisce di utilizzare externalTrafficPolicy: Cluster, ma externalTrafficPolicy: Cluster disattiva di fatto il bilanciamento del carico ponderato perché il pacchetto potrebbe essere instradato, dopo il bilanciatore del carico, a un nodo diverso.

Puoi anche attivare il bilanciamento del carico ponderato su un servizio LoadBalancer esterno esistente utilizzando kubectl edit svc service-name. Il comando kubectl edit apre il manifest del servizio del bilanciatore del carico esistente nell'editor di testo configurato, dove puoi modificare il manifest e salvare le modifiche. Quando modifichi un servizio LoadBalancer esterno esistente, tieni presente quanto segue:

  • Il servizio LoadBalancer esterno esistente deve aver comportato la creazione di un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend. Per i cluster che eseguono versioni di GKE precedenti alla 1.37, questo requisito significa che il servizio LoadBalancer esterno esistente deve avere il campo spec.loadBalancerClass impostato su networking.gke.io/l4-regional-external quando il manifest è stato applicato per la prima volta al cluster.

    L'aggiunta dell'annotazione networking.gke.io/weighted-load-balancing: "pods-per-node" a un servizio LoadBalancer esterno esistente che utilizza un bilanciatore del carico di rete passthrough esterno regionale basato su pool di destinazione non ha alcun effetto.

  • Quando aggiorni il manifest del servizio LoadBalancer esterno esistente, assicurati di impostare il valore externalTrafficPolicy: Local. L'utilizzo di externalTrafficPolicy: Cluster disattiva di fatto il bilanciamento del carico ponderato perché il pacchetto potrebbe essere instradato, dopo il bilanciatore del carico, a un nodo diverso.

Disabilita il bilanciamento del carico ponderato

Per distribuire le nuove connessioni ai nodi indipendentemente dal numero di pod di gestione presenti su ciascun nodo, disattiva il bilanciamento del carico ponderato rimuovendo l'annotazione networking.gke.io/weighted-load-balancing: "pods-per-node" dal manifest del servizio.

Abilita il logging per i servizi di backend

Puoi abilitare, disabilitare e visualizzare i log per un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend.

Per configurare Cloud Logging, crea una risorsa personalizzata L4LBConfig che specifica le impostazioni di logging. La risorsa L4LBConfig è collegata a un servizio Kubernetes nel manifest del servizio. Dopo aver applicato il manifest, il controller GKE configura il logging per il servizio di backend. Se non colleghi una risorsa L4LBConfig al servizio, il controller interrompe la gestione della configurazione di logging e lascia il servizio di backend nel suo ultimo stato noto. Per saperne di più, consulta Informazioni sul comportamento di coasting.

Puoi configurare i seguenti campi:

  • enabled: se impostato su true, abilita il logging per questo servizio e i log sono disponibili in Cloud Logging. In caso contrario, il logging è disabilitato per questo servizio.
  • sampleRate: specifica un valore compreso tra 0 e 1,000,000 (valore predefinito), dove 0 indica che non viene registrato nessun pacchetto e 1,000,000 indica che viene registrato il 100% dei pacchetti. Il campo sampleRate è facoltativo ed è pertinente solo se il valore del campo enable è impostato su true.
  • optionalMode: controlla quali campi dei metadati facoltativi sono inclusi nei log generati per il bilanciatore del carico. Il campo accetta uno dei seguenti valori stringa:
    • EXCLUDE_ALL_OPTIONAL: impostazione predefinita se optionalMode non è specificato. Se impostata, nei log non vengono inclusi campi facoltativi, fornendo il formato di log più conciso.
    • INCLUDE_ALL_OPTIONAL: attiva il logging per tutti i campi facoltativi disponibili, fornendo le voci di log più dettagliate.
    • CUSTOM: specifica un elenco personalizzato di campi facoltativi inclusi nei log. Con la modalità CUSTOM, devi utilizzare anche il parametro optionalFields per fornire un elenco separato da virgole dei campi che ti interessano.
  • optionalFields: stringa di nomi di campi separati da virgole. Definisce i campi dei metadati facoltativi esatti che vuoi includere nei log generati. Questo campo viene utilizzato solo quando optionalMode è impostato su CUSTOM, altrimenti i valori vengono ignorati.

Per configurare Cloud Logging, crea la risorsa L4LBConfig nello stesso spazio dei nomi della risorsa Service. Il seguente manifest L4LBConfig di esempio abilita Cloud Logging e imposta la frequenza di campionamento sul 50% delle richieste per un determinato servizio del bilanciatore del carico.

  1. Salva il seguente manifest come svc-l4lb-config.yaml:

    apiVersion: networking.gke.io/v1
kind: L4LBConfig
metadata:
  name: svc-l4lb-config
  namespace: default
spec:
  logging:
    enabled: true # must be included
    sampleRate: 500000
    optionalMode: "INCLUDE_ALL_OPTIONAL"

  2. Applica il manifest L4LBConfig al tuo cluster:

    kubectl apply -f svc-l4lb-config.yaml

  3. Aggiungi l'annotazione networking.gke.io/l4lb-config al manifest del servizio store-v1-lb-svc.yaml:

    apiVersion: v1
kind: Service
metadata:
  name: store-v1-lb-svc
  annotations:
    cloud.google.com/l4-rbs: "enabled"
    networking.gke.io/l4lb-config: "svc-l4lb-config"
spec:
  type: LoadBalancer
  selector:
    app: store
  ports:
    - name: tcp-port
      protocol: TCP
      port: 8080
      targetPort: 8080

  4. Applica il manifest del servizio al tuo cluster:

    kubectl apply -f store-v1-lb-svc.yaml

Verifica il servizio LoadBalancer esterno e i relativi componenti

  1. Verifica che il servizio sia in esecuzione:

    kubectl get svc store-v1-lb-svc

    L'output è simile al seguente:

    NAME               TYPE           CLUSTER-IP        EXTERNAL-IP     PORT(S)          AGE
store-v1-lb-svc   LoadBalancer   10.44.196.160     35.193.28.231   8080:32466/TCP   11m

    GKE ha assegnato un EXTERNAL_IP per il bilanciatore del carico di rete passthrough esterno regionale.

  2. Testa la connessione al bilanciatore del carico:

    curl EXTERNAL_IP:PORT

    Sostituisci quanto segue:

    • EXTERNAL_IP: l'indirizzo IP allocato per il bilanciatore del carico di rete passthrough esterno regionale.
    • PORT: il numero di porta allocato per il bilanciatore del carico di rete passthrough esterno regionale.

    L'output è simile al seguente:

    Hostname: store-v1-lb-svc-cdb9bb4d6-hflxd

Pod Information:
  -no pod information available-

Server values:
  server_version=nginx: 1.13.3 - lua: 10008

Request Information:
  client_address=10.128.0.50
  method=GET
  real path=/
  query=
  request_version=1.1
  request_scheme=http
  request_uri=EXTERNAL_IP

Request Headers:
  accept=*/*
  host=EXTERNAL_IP
  user-agent=curl/7.81.0

Request Body:
  -no body in request-

  3. Controlla il servizio LoadBalancer e il relativo insieme di annotazioni che descrivono le risorseCloud de Confiance :

    kubectl describe svc store-v1-lb-svc

    L'output è simile al seguente:

    Name:                     store-v1-lb-svc
Namespace:                default
Labels:                   <none>
Annotations:              cloud.google.com/neg-status: {"network_endpoint_groups":{"0":"k8s2-qvveq1d8-default-my-service-ext-5s55db85"},"zones":["us-central1-c"]} #This annotation appears in the output only if the service uses NEG backends.
                          networking.gke.io/weighted-load-balancing: pods-per-node #This annotation appears in the output only if weighted load balancing is enabled.
                          service.kubernetes.io/backend-service: k8s2-qvveq1d8-default-my-service-ext-5s55db85
                          service.kubernetes.io/firewall-rule: k8s2-qvveq1d8-default-my-service-ext-5s55db85
                          service.kubernetes.io/firewall-rule-for-hc: k8s2-qvveq1d8-default-my-service-ext-5s55db85-fw
                          service.kubernetes.io/healthcheck: k8s2-qvveq1d8-default-my-service-ext-5s55db85
                          service.kubernetes.io/tcp-forwarding-rule: a808124abf8ce406ca51ab3d4e7d0b7d
Selector:                 app=store
Type:                     LoadBalancer
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.18.102.23
IPs:                      10.18.102.23
LoadBalancer Ingress:     35.184.160.229
Port:                     tcp-port  8080/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-port  31864/TCP
Endpoints:                10.20.1.28:8080,10.20.1.29:8080
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     30394

Events:
  Type    Reason                Age                    From                     Message
  ----    ------                ----                   ----                     -------
  Normal  ADD                   4m55s                  loadbalancer-controller  default/my-service-ext

    Esistono diversi campi che indicano che un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend e le relative risorse Cloud de Confiance sono stati creati correttamente:

    • Campo Events. Questo campo è vuoto se il servizio LoadBalancer e le relative risorse sono stati creati correttamente. Se si è verificato un errore, viene elencato qui.

    • Elenco di Annotations abilitati: GKE aggiunge il seguente elenco di annotazioni di sola lettura al manifest del servizio. Ogni annotazione il cui nome inizia con service.kubernetes.io/ viene utilizzata per indicare il nome di una risorsaCloud de Confiance creata nell'ambito del bilanciatore del carico o per supportarlo.

      • L'annotazione networking.gke.io/weighted-load-balancing: pods-per-node indica che è stato applicato il bilanciamento del carico ponderato e che il bilanciatore del carico distribuisce il traffico ai pod di backend in base al numero di pod in esecuzione su ciascun nodo.
      • L'annotazione service.kubernetes.io/backend-service indica il nome del servizio di backend del bilanciatore del carico.
      • L'annotazione service.kubernetes.io/healthcheck indica il nome del controllo di integrità del bilanciatore del carico utilizzato dal servizio di backend.
      • L'annotazione service.kubernetes.io/tcp-forwarding-rule o service.kubernetes.io/udp-forwarding-rule indica il nome della regola di forwarding del bilanciatore del carico.
      • L'annotazione service.kubernetes.io/firewall-rule indica il nome della regola firewall creata per consentire il traffico verso i nodi del cluster. Gli intervalli di origine per questa regola firewall sono personalizzabili utilizzando spec.loadBalancerSourceRanges[]. Per ulteriori dettagli sulle regole firewall per i servizi LoadBalancer, consulta Regole firewall e lista consentita di indirizzi IP di origine.
      • L'annotazione service.kubernetes.io/firewall-rule-for-hc indica il nome della regola firewall richiesta per i controlli di integrità del bilanciatore del carico.

      • L'annotazione cloud.google.com/neg-status indica sia i NEG utilizzati dal bilanciatore del carico sia le relative zone. Questa annotazione è presente solo se sono soddisfatte entrambe le seguenti condizioni:

        • Il cluster eseguiva GKE versione 1.32.2-gke.1652000 o successive quando il manifest è stato applicato al cluster.
        • Il campo spec.loadBalancerClass impostato sul valore networking.gke.io/l4-regional-external era presente nel manifest del servizio quando è stato applicato al cluster.

  4. Verifica che siano state create risorse del bilanciatore del carico e regole firewall per il servizio LoadBalancer esterno:

    • Per visualizzare la regola di forwarding, esegui questo comando:

        gcloud compute forwarding-rules describe FWD_RULE_NAME \
    --region=REGION_NAME

      Sostituisci quanto segue:

      • FWD_RULE_NAME: il nome della regola di forwarding fornito dalle annotazioni di sola lettura service.kubernetes.io/tcp-forwarding-rule o service.kubernetes.io/udp-forwarding-rule. Per controllare queste annotazioni, esegui kubectl describe svc SERVICE_NAME.
      • REGION_NAME: la regione Cloud de Confiance contenente il cluster. Per i cluster a livello di zona, la regione contiene la zona utilizzata dal cluster.

    • Per visualizzare il servizio di backend, esegui questo comando:

      gcloud compute backend-services describe BACKEND_SERVICE_NAME \
  --region=REGION_NAME

      Sostituisci quanto segue:

      • BACKEND_SERVICE_NAME service.kubernetes.io/backend-service Per controllare questa annotazione di sola lettura, esegui kubectl describe svc SERVICE_NAME.
      • REGION_NAME: la regione Cloud de Confiance contenente il cluster. Per i cluster a livello di zona, la regione contiene la zona utilizzata dal cluster.

    • Per visualizzare il controllo di integrità del bilanciatore del carico, esegui questo comando:

      gcloud compute health-checks describe HEALTH_CHECK_NAME \
  --region=REGION_NAME

      Sostituisci quanto segue:

      • HEALTH_CHECK_NAME: il nome del controllo di integrità del bilanciatore del carico. Il nome del controllo di integrità è fornito dall'annotazione di sola lettura service.kubernetes.io/healthcheck. Per controllare questa annotazione di sola lettura, esegui kubectl describe svc SERVICE_NAME.
      • REGION_NAME: la regione Cloud de Confiance contenente il cluster. Per i cluster a livello di zona, la regione contiene la zona utilizzata dal cluster.

    • Per visualizzare le regole firewall, esegui questi comandi:

      gcloud compute firewall-rules describe FIREWALL_RULE_NAME

      gcloud compute firewall-rules describe HEALTH_CHECK_FIREWALL_RULE_NAME

      Sostituisci quanto segue:

      • FIREWALL_RULE_NAME: il nome della regola firewall che consente il traffico verso il bilanciatore del carico. Il nome di questa regola firewall è fornito dall'annotazione di sola lettura service.kubernetes.io/firewall-rule. Per controllare questa annotazione di sola lettura, esegui kubectl describe svc SERVICE_NAME.
      • HEALTH_CHECK_FIREWALL_RULE_NAME: il nome della regola firewall che consente i controlli di integrità dei backend del bilanciatore del carico (i nodi del cluster). Il nome di questa regola firewall è fornito dall'annotazione di sola lettura service.kubernetes.io/firewall-rule-for-hc. Per controllare questa annotazione di sola lettura, esegui kubectl describe svc SERVICE_NAME.

    • Per visualizzare i NEG del bilanciatore del carico, esegui questo comando:

      gcloud compute network-endpoint-groups describe NEG_NAME \
  --zone=ZONE_NAME

      Sostituisci quanto segue:

      • NEG_NAME: il nome del NEG del bilanciatore del carico. Il nome del NEG è fornito dall'annotazione di sola lettura cloud.google.com/neg-status. Per controllare questa annotazione di sola lettura, esegui il comando kubectl describe svc SERVICE_NAME. L'annotazione contiene dati strutturati con informazioni sui nomi e sulle zone dei NEG utilizzati dal bilanciatore del carico. Per i cluster di zona, questa annotazione contiene informazioni su un NEG. Per i cluster a livello di regione, questa annotazione contiene informazioni su un NEG in ogni zona in cui si trova il cluster.
      • ZONE_NAME: la zona Cloud de Confiance che contiene il NEG.

  5. Verifica che Cloud Logging sia stato abilitato per il servizio di backend:

    kubectl get svc SERVICE_NAME --output yaml

    Sostituisci quanto segue:

    • SERVICE_NAME: il nome del servizio di backend.

    Nell'output, assicurati che il campo Status.Conditions contenga Type: LoggingConfigManaged e Reason: Reconciled.

Elimina il servizio LoadBalancer esterno

Per eliminare il servizio LoadBalancer esterno store-v1-lb-svc di esempio, utilizza il seguente comando:

kubectl delete service store-v1-lb-svc

GKE rimuove automaticamente tutte le risorse del bilanciatore del carico create per il servizio LoadBalancer esterno.

Esegui la migrazione ai backend NEG GCE_VM_IP

I servizi LoadBalancer esterni creano bilanciatori del carico di rete passthrough esterni regionali basati su servizio di backend se vengono creati in GKE 1.37 o versioni successive, specificano il valore networking.gke.io/l4-regional-external per il campo spec.loadBalancerClass o includono l'annotazione cloud.google.com/l4-rbs: "enabled". A seconda della versione GKE del cluster, GKE utilizza gruppi di endpoint di rete GCE_VM_IP o gruppi di istanze non gestite come backend:

  • Se il manifest del servizio è stato applicato a un cluster che esegue GKE versione 1.32.2-gke.1652000 o successive, il bilanciatore del carico di rete passthrough esterno regionale risultante utilizza i backend dei gruppi di endpoint di rete (NEG) GCE_VM_IP.

  • Se il manifest del servizio è stato applicato a un cluster che esegue una versione precedente di GKE, il bilanciatore del carico di rete passthrough esterno regionale risultante utilizza backend di gruppi di istanze non gestite.

Per saperne di più, consulta Raggruppamento dei nodi in Informazioni sui servizi LoadBalancer.

Puoi creare un nuovo servizio LoadBalancer esterno basato su un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend che utilizza i backend NEG GCE_VM_IP se il tuo servizio esistente utilizza uno dei seguenti bilanciatori del carico:

  • Un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend con backend di gruppi di istanze
  • Un bilanciatore del carico di rete passthrough esterno regionale basato su pool di destinazione

Per conservare un indirizzo IPv4 esterno quando passi a un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend che utilizza backend NEG GCE_VM_IP (i servizi LoadBalancer esterni IPv6 non richiedono questa migrazione):

  1. Se non l'hai ancora fatto, esegui l'upgrade del cluster alla versione GKE 1.32.2-gke.1652000 o successiva.

  2. Identifica il servizio LoadBalancer esterno che vuoi passare a un bilanciatore del carico di rete passthrough esterno regionale basato su servizio di backend utilizzando i backend NEG GCE_VM_IP. Descrivi il servizio utilizzando il seguente comando:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    Sostituisci quanto segue:

    • SERVICE_NAME: il nome del servizio LoadBalancer esterno esistente.

    • SERVICE_NAMESPACE: lo spazio dei nomi del servizio LoadBalancer esterno esistente.

    Nell'output comando, prendi nota dell'indirizzo IPv4 esterno del bilanciatore del carico elencato dopo LoadBalancer Ingress.

  3. Recupera il manifest del servizio per il servizio LoadBalancer esistente:

    • È meglio avere il manifest del servizio originale che hai applicato al cluster in passato. Ad esempio, potresti avere questo file in un repository di controllo del codice sorgente.

    • Se non hai il manifest del servizio originale:

      • Esegui questo comando per ottenere una copia YAML del manifest del servizio che rappresenta l'implementazione attuale del bilanciatore del carico:

        kubectl get svc SERVICE_NAME -n SERVICE_NAMESPACE -o yaml

      • Copia il file YAML del manifest in un editor di testo. Rimuovi l'attributo status e i seguenti attributi metadata:

        • Tutte le seguenti annotazioni:
          • L'annotazione kubectl.kubernetes.io/last-applied-configuration
          • Tutte le annotazioni che iniziano con service.kubernetes.io
        • creationTimestamp
        • finalizers
        • resourceVersion
        • uid

    • Assicurati che il manifest includa il campo spec.loadBalancerClass impostato sul valore networking.gke.io/l4-regional-external. Se esegui la migrazione da un bilanciatore del carico di rete passthrough esterno regionale basato su pool di destinazione, il campo deve essere aggiunto.

    Salva il file manifest e prendi nota della posizione in cui lo hai salvato. Il resto di questa procedura fa riferimento al percorso in cui hai salvato il manifest come MANIFEST_FILE_PATH.

  4. Configura una risorsa indirizzo IPv4 esterno statico per contenere l'indirizzo IPv4 esterno utilizzato dal bilanciatore del carico esistente:

    gcloud compute addresses create IP_ADDRESS_NAME --region=CLUSTER_REGION --addresses LB_EXTERNAL_IP

    Sostituisci quanto segue:

    • IP_ADDRESS_NAME: il nome dell'indirizzo IP esterno statico. Il nome deve rispettare le convenzioni di denominazione per le risorse Compute Engine.

    • CLUSTER_REGION: la regione che contiene il cluster. Per i cluster di zona, questa è la regione che contiene la zona del cluster.

    • LB_EXTERNAL_IP: l'indirizzo IPv4 esterno utilizzato dal bilanciatore del carico attuale, determinato nel secondo passaggio di questa procedura.

  5. Verifica che la risorsa indirizzo IPv4 esterno statico sia stata creata:

    gcloud compute addresses describe IP_ADDRESS_NAME --region=CLUSTER_REGION

    Sostituisci le variabili come indicato nel passaggio precedente.

  6. Elimina il servizio esistente:

    kubectl delete svc SERVICE_NAME -n SERVICE_NAMESPACE

  7. Aggiungi la seguente annotazione al file manifest del servizio MANIFEST_FILE_PATH:

    networking.gke.io/load-balancer-ip-addresses: IP_ADDRESS_NAME

    Per saperne di più su questa annotazione, consulta Indirizzi IP statici nei parametri del servizio LoadBalancer.

  8. Applica il manifest del servizio aggiornato al cluster:

    kubectl apply -f MANIFEST_FILE_PATH

  9. (Facoltativo) Rilascia la risorsa indirizzo IPv4 statico.

    gcloud compute addresses delete IP_ADDRESS_NAME --region=CLUSTER_REGION

Risoluzione dei problemi

Questa sezione descrive i problemi che potresti riscontrare durante la configurazione di un servizio LoadBalancer esterno basato su un servizio di backend.

Policy del traffico esterno errata per il bilanciamento del carico ponderato

Se non imposti il valore externalTrafficPolicy: Local quando attivi il bilanciamento del carico ponderato, potresti ricevere un evento di avviso quando descrivi il servizio utilizzando il seguente comando:

kubectl describe svc store-v1-lb-svc`

Events:
  Type     Reason                   Age      From                     Message
  ----     ------                   ----     ----                     -------
  Warning  UnsupportedConfiguration 4m55s    loadbalancer-controller  Weighted load balancing by pods-per-node has no effect with External Traffic Policy: Cluster.

Per attivare in modo efficace il bilanciamento del carico ponderato, devi impostare il valore externalTrafficPolicy: Local.

Errore durante la creazione di un bilanciatore del carico IPv6 nel livello Standard

Se un servizio LoadBalancer esterno IPv6 mostra un evento SyncExternalLoadBalancerFailed con il messaggio Network tier Standard is not supported for IPv6 External Load Balancer, rimuovi l'annotazione cloud.google.com/network-tier: Standard dal manifest del servizio. I servizi LoadBalancer esterni IPv6 sono supportati solo nel livello Premium.

Errori durante la configurazione di Bring Your Own IPv6 (BYOIPv6)

Quando configuri Porta i tuoi indirizzi IPv6 (BYOIPv6) per un servizio LoadBalancer esterno, potresti visualizzare eventi di avviso SyncExternalLoadBalancerFailed quando esegui il comando kubectl describe service SERVICE_NAME. Il messaggio di evento inizia con Error ensuring Resource for L4 External LoadBalancer, err: seguito da uno dei seguenti errori:

  • networking.gke.io/ip-collection-v6 is currently only supported for IPv6-only Services: assicurati che il manifest del servizio specifichi spec.ipFamilyPolicy: SingleStack e spec.ipFamilies: ["IPv6"].
  • static IPv6 address "ADDRESS_NAME" is a BYOIP address from IP collection "SUB_PREFIX", which is currently only supported for IPv6-only Services: assicurati che il manifest del servizio specifichi spec.ipFamilyPolicy: SingleStack e spec.ipFamilies: ["IPv6"]. Questo errore indica che il servizio è a doppio stack o IPv4, ma fa riferimento a un indirizzo BYOIPv6 statico.
  • cannot specify both networking.gke.io/load-balancer-subnet ("SUBNET") and networking.gke.io/ip-collection-v6 ("SUB_PREFIX") for LoadBalancer: rimuovi l'annotazione networking.gke.io/load-balancer-subnet dal manifesto del servizio quando utilizzi l'annotazione networking.gke.io/ip-collection-v6.
  • invalid networking.gke.io/ip-collection-v6 "VALUE": expected projects/PROJECT/regions/REGION/publicDelegatedPrefixes/NAME o invalid networking.gke.io/ip-collection-v6 "VALUE": the public delegated prefix must be in the cluster region REGION: imposta l'annotazione sull'URL completo della risorsa o sul percorso parziale della risorsa (projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME) di un prefisso secondario nella stessa regione del cluster. Un nome di sottoprofisso semplice non è accettato.
  • reserved address ("ADDRESS_NAME") is not valid, err: ipCollection mismatch, expected "SUB_PREFIX_A", actual: "SUB_PREFIX_B": assicurati che l'annotazione networking.gke.io/ip-collection-v6 corrisponda al prefisso delegato pubblicamente che hai utilizzato per prenotare l'indirizzo IPv6 statico oppure ometti l'annotazione networking.gke.io/ip-collection-v6 quando utilizzi l'annotazione networking.gke.io/load-balancer-ip-addresses.
  • googleapi: Error 403: Required 'compute.publicDelegatedPrefixes.use' permission for 'SUB_PREFIX', forbidden: concedi il ruolo Compute Public IP Admin (roles/compute.publicIpAdmin) all'agente di servizio GKE (service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com) nel progetto proprietario del prefisso delegato pubblico. GKE ha bisogno di questa autorizzazione ogni volta che sincronizza il servizio, quindi non rimuovere il ruolo dopo che GKE ha creato il servizio.

Passaggi successivi