Crea un bilanciatore del carico interno

Autopilot Standard

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

• Informazioni sui servizi LoadBalancer
• Parametri del servizio LoadBalancer GKE

Per saperne di più sui bilanciatori del carico di rete passthrough interni in generale, consulta la panoramica dei bilanciatori del carico di rete passthrough interni.

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.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare la proprietà compute/region. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

• Assicurati di avere un cluster Autopilot o Standard esistente. Per creare un nuovo cluster, vedi Crea un cluster Autopilot.

Requisiti

• Questo tutorial utilizza spec.loadBalancerClass per creare un bilanciatore del carico di rete passthrough interno con backend NEG GCE_VM_IP. Questo tutorial richiede GKE 1.33.1-gke.1779000 o versioni successive perché spec.loadBalancerClass richiede GKE 1.33.1-gke.1779000 o versioni successive.

• L'affinità di zona richiede GKE 1.33.3-gke.1392000 e versioni successive.

• Il cluster deve avere il subsetting GKE abilitato:

  • La suddivisione in sottoinsiemi GKE è abilitata per impostazione predefinita nei cluster che eseguono la versione 1.36 e successive. Per queste versioni, la suddivisione in sottoinsiemi è attiva indipendentemente dal valore del flag di suddivisione in sottoinsiemi del cluster.

  • Nelle versioni GKE supportate precedenti alla versione 1.36, devi abilitare esplicitamente il GKE Subsetting. Puoi attivare il subsetting GKE quando crei un nuovo cluster o aggiorni un cluster esistente. Una volta abilitato, il subsetting GKE non può essere disabilitato. Per maggiori informazioni, consulta Verifica e abilita il subsetting GKE.

• 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 abilitare Cloud Logging per un servizio LoadBalancer interno, il cluster GKE deve utilizzare la versione 1.36.0-gke.2459000 o successiva.

Verifica e abilita l'impostazione secondaria GKE

Assicurati che il subsetting GKE sia abilitato:

• La suddivisione in sottoinsiemi di GKE è sempre abilitata in GKE 1.36 e versioni successive.

• Puoi abilitare manualmente il subsetting GKE nei cluster Standard e Autopilot nuovi ed esistenti che eseguono GKE versione 1.18.19-gke.1400 e successive, ma precedenti alla versione GKE 1.36. Non puoi disattivare il subsetting GKE dopo averlo attivato.

Per informazioni sull'importanza del subsetting GKE, consulta Considerazioni speciali per i servizi LoadBalancer interni.

Per determinare se il subsetting GKE è abilitato, esegui questo comando:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="get(currentMasterVersion, networkConfig.enableL4ilbSubsetting)"

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del cluster.
• LOCATION : la zona o la regione del cluster.

L'output del comando mostra la versione del control plane del cluster seguita da True o False per l'attributo networkConfig.enableL4ilbSubsetting. Interpreta l'output nel seguente modo:

• Se la versione del control plane è 1.36 o successiva, la suddivisione in sottoinsiemi GKE è abilitata indipendentemente dal fatto che l'attributo networkConfig.enableL4ilbSubsetting sia True o False.
• Se la versione del control plane è precedente alla 1.36:
  • True indica che la creazione di sottoinsiemi GKE è abilitata.
  • False indica che la suddivisione in sottoinsiemi GKE è disabilitata.

Per abilitare la suddivisione in sottoinsiemi GKE in un cluster che esegue GKE versione 1.18.19-gke.1400 e successive, ma precedenti alla versione GKE 1.36, utilizza gcloud CLI o la console Google Cloud .

Console

1. Nella console Google Cloud , vai alla pagina Google Kubernetes Engine.

   Vai a Google Kubernetes Engine

2. Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.

3. In Networking, accanto al campo Impostazione secondaria per bilanciatori del carico interni L4, fai clic su Abilita impostazione secondaria per i bilanciatori del carico interni L4.

4. Seleziona la casella di controllo Abilita impostazione secondaria per i bilanciatori del carico interni L4.

5. Fai clic su Salva modifiche.

gcloud

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION
    --enable-l4-ilb-subsetting

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del cluster.
• LOCATION : la zona o la regione del cluster.

L'abilitazione del subsetting GKE, utilizzando gcloud CLI, la consoleGoogle Cloud o eseguendo l'upgrade del cluster alla versione 1.36 o successive, non modifica i servizi LoadBalancer interni esistenti. Se vuoi eseguire la migrazione di un servizio LoadBalancer interno esistente per utilizzare i backend NEG GCE_VM_IP, devi eseguire il deployment di un manifest del servizio sostitutivo.

Attenzione: non rimuovere o modificare i tag finalizer nelle risorse Service. GKE si basa su questi tag per distinguere tra bilanciatori del carico con e senza suddivisione in sottoinsiemi. Se utilizzi gestori di risorse esterni o strumenti GitOps, configurali in modo da conservare i tag dei finalizzatori. La rimozione o l'aggiornamento di questi tag può impedire il provisioning corretto dei nuovi bilanciatori del carico.

Esegui il deployment di un workload

Il seguente manifest descrive un deployment che esegue un'immagine container di un'applicazione web di esempio.

1. Salva il manifest come ilb-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: ilb-deployment
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: ilb-deployment
     template:
       metadata:
         labels:
           app: ilb-deployment
       spec:
         containers:
         - name: hello-app
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
   

2. Applica il manifest al tuo cluster:

   kubectl apply -f ilb-deployment.yaml
   

Crea un servizio LoadBalancer interno

1. (Facoltativo) Disabilita la creazione automatica delle regole firewall VPC:

   Sebbene GKE crei automaticamente regole firewall VPC per consentire il traffico verso il bilanciatore del carico interno, hai la possibilità di disabilitare la creazione automatica delle regole firewall VPC e gestire le regole firewall in autonomia. Puoi disabilitare le regole firewall VPC solo se hai abilitato il subsetting GKE per il servizio LoadBalancer interno. Tuttavia, la gestione delle regole firewall VPC è facoltativa e puoi fare affidamento sulle regole automatiche.

   Prima di disattivare la creazione automatica delle regole firewall VPC, assicurati di definire regole di autorizzazione che consentano al traffico di raggiungere il bilanciatore del carico e i pod dell'applicazione.

   Per saperne di più sulla gestione delle regole firewall VPC, consulta Gestisci la creazione automatica delle regole firewall e come disattivare la creazione automatica delle regole firewall, consulta Regole firewall gestite dall'utente per i servizi LoadBalancer GKE.

2. L'esempio seguente crea un servizio LoadBalancer interno utilizzando la porta TCP 80. GKE esegue il deployment di un bilanciatore del carico di rete passthrough interno la cui regola di forwarding utilizza la porta 80, ma poi inoltra il traffico ai pod di backend sulla porta 8080:

   1. Salva il manifest come ilb-svc.yaml:

      apiVersion: v1
      kind: Service
      metadata:
        name: ilb-svc
      spec:
        type: LoadBalancer
        # Request an internal load balancer.
        loadBalancerClass: networking.gke.io/l4-regional-internal
        # Evenly route external traffic to all endpoints.
        externalTrafficPolicy: Cluster
        # Prioritize routing traffic to endpoints that are in the same zone.
        trafficDistribution: PreferSameZone
        selector:
          app: ilb-deployment
        # Forward traffic from TCP port 80 to port 8080 in backend Pods.
        ports:
        - name: tcp-port
          protocol: TCP
          port: 80
          targetPort: 8080
      

      Il manifest deve contenere quanto segue:

      • Un name per il servizio LoadBalancer interno, in questo caso ilb-svc.
      • Il campo spec.loadBalancerClass impostato sul valore networking.gke.io/l4-regional-internal per specificare un servizio LoadBalancer interno, come mostrato nel manifest di esempio.
      • L'elemento type: LoadBalancer.
      • Un campo spec: selector per specificare i pod che il servizio deve scegliere come target, ad esempio app: hello.
      • Informazioni sulla porta:
        • port rappresenta la porta di destinazione su cui la regola di forwarding del bilanciatore del carico di rete passthrough interno riceve i pacchetti.
        • targetPort deve corrispondere a un containerPort definito su ogni pod di distribuzione.
        • I valori port e targetPort non devono necessariamente essere uguali. I nodi eseguono sempre il NAT di destinazione, modificando l'indirizzo IP della regola di forwarding del bilanciatore del carico di destinazione e port in un indirizzo IP del pod di destinazione e targetPort. Per maggiori dettagli, consulta Network Address Translation di destinazione sui nodi nella documentazione sui concetti del servizio LoadBalancer.

      Il manifest può contenere quanto segue:

      • spec.ipFamilyPolicy e ipFamilies per definire il modo in cui GKE assegna gli indirizzi IP al servizio. GKE supporta servizi LoadBalancer IP a stack singolo (solo IPv4 o solo IPv6) o a doppio stack. Un servizio LoadBalancer a doppio stack viene implementato con due regole di forwarding del bilanciatore del carico di rete passthrough interno separate: una per il traffico IPv4 e una per il traffico IPv6. Il servizio LoadBalancer dual-stack di GKE è disponibile nella versione 1.29 o successive. 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 single-stack, questi sono i valori predefiniti e puoi ometterli. Per saperne di più, consulta Servizi a doppio stack IPv4/IPv6.

      • spec.trafficDistribution per definire il modo in cui GKE instrada il traffico in entrata. Per attivare l'affinità di zona, imposta il valore di questo campo su PreferSameZone. L'affinità di zona significa che GKE dà la priorità al routing del traffico proveniente da una zona verso i nodi e i pod all'interno della stessa zona. Se in quella zona non sono disponibili pod integri, il traffico viene indirizzato a un'altra zona. Per le versioni del cluster precedenti alla 1.35.0-gke.1811000, utilizza invece il valore PreferClose. L'affinità di zona richiede l'abilitazione del subsetting GKE.

        Nota: puoi anche attivare o disattivare l'affinità di zona su un servizio LoadBalancer interno esistente utilizzando il comando 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 aggiungere o rimuovere il parametro spec.trafficDistribution e salvare le modifiche. Il traffico potrebbe essere interrotto brevemente quando modifichi questo parametro.

        Per considerazioni importanti e una soluzione alternativa per la scalabilità dei workload con affinità di zona, consulta Scala i workload con affinità di zona.

      Per saperne di più, consulta Parametri del servizio LoadBalancer.

   2. Applica il manifest al tuo cluster:

      kubectl apply -f ilb-svc.yaml
      

3. Ricevere informazioni dettagliate sul Servizio:

   kubectl get service ilb-svc --output yaml
   

   L'output è simile al seguente:

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       cloud.google.com/neg: '{"ingress":true}'
       cloud.google.com/neg-status: '{"network_endpoint_groups":{"0":"k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r"},"zones":["ZONE_NAME","ZONE_NAME","ZONE_NAME"]}'
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"},"name":"ilb-svc","namespace":"default"},"spec":{"externalTrafficPolicy":"Cluster","ports":[{"name":"tcp-port","port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"ilb-deployment"},"type":"LoadBalancer"}}
       networking.gke.io/load-balancer-type: Internal
       service.kubernetes.io/backend-service: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
       service.kubernetes.io/firewall-rule: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
       service.kubernetes.io/firewall-rule-for-hc: k8s2-pn2h9n5f-l4-shared-hc-fw
       service.kubernetes.io/healthcheck: k8s2-pn2h9n5f-l4-shared-hc
       service.kubernetes.io/tcp-forwarding-rule: k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r
     creationTimestamp: "2022-07-22T17:26:04Z"
     finalizers:
     - gke.networking.io/l4-ilb-v2
     - service.kubernetes.io/load-balancer-cleanup
     name: ilb-svc
     namespace: default
     resourceVersion: "51666"
     uid: d7a1a865-7972-44e1-aa9e-db5be23d6567
   spec:
     allocateLoadBalancerNodePorts: true
     clusterIP: 10.88.2.141
     clusterIPs:
     - 10.88.2.141
     externalTrafficPolicy: Cluster
     internalTrafficPolicy: Cluster
     ipFamilies:
     - IPv4
     ipFamilyPolicy: SingleStack
     ports:
     - name: tcp-port
       # Kubernetes automatically allocates a port on the node during the
       # process of implementing a Service of type LoadBalancer.
       nodePort: 30521
       port: 80
       protocol: TCP
       targetPort: 8080
     selector:
       app: ilb-deployment
     sessionAffinity: None
     trafficDistribution: PreferSameZone
     type: LoadBalancer
   status:
     # IP address of the load balancer forwarding rule.
     loadBalancer:
       ingress:
       - ip: 10.128.15.245
   

   L'output ha i seguenti attributi:

   • L'indirizzo IP della regola di forwarding del bilanciatore del carico di rete passthrough interno è incluso in status.loadBalancer.ingress. Questo indirizzo IP è diverso dal valore di clusterIP. In questo esempio, l'indirizzo IP della regola di forwarding del bilanciatore del carico è 10.128.15.245.
   • Qualsiasi pod con l'etichetta app: ilb-deployment è un pod di distribuzione per questo servizio. Questi sono i pod che ricevono i pacchetti instradati dal bilanciatore del carico di rete passthrough interno.
   • I client chiamano il servizio utilizzando questo indirizzo IP loadBalancer e la porta di destinazione TCP specificata nel campo port del manifest del servizio. Per i dettagli completi su come vengono instradati i pacchetti una volta ricevuti da un nodo, consulta Elaborazione dei pacchetti.
   • GKE ha assegnato un nodePort al servizio; in questo esempio, è assegnata la porta 30521. nodePort non è pertinente per il bilanciatore del carico di rete passthrough interno.

4. Ispeziona il gruppo di endpoint di rete del servizio:

   kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"
   

   L'output è simile al seguente:

   {"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["ZONE_NAME"]}
   

   La risposta indica che GKE ha creato un gruppo di endpoint di rete denominato k8s2-knlc4c77-default-ilb-svc-ua5ugas0. Questa annotazione è presente nei servizi di tipo LoadBalancer che utilizzano la suddivisione in sottoinsiemi di GKE e non è presente nei servizi che non utilizzano la suddivisione in sottoinsiemi di GKE.

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

Anteprima

Questo prodotto o questa funzionalità sono soggetti ai "Termini dell'offerta pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Quando esegui il deployment di un servizio LoadBalancer interno IPv6 a stack singolo su un cluster IPv6 a stack singolo o 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 INTERNAL o EXTERNAL. 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). Per creare un servizio dual-stack, imposta il valore del campo spec.ipFamilyPolicy su RequireDualStack ed elenca entrambe le famiglie di indirizzi nel campo spec.ipFamilies:

• 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), il bilanciatore del carico interno utilizza automaticamente la subnet dei nodi esistente. Crea il tuo servizio senza annotazioni di subnet personalizzate:

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

• 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), un bilanciatore del carico interno non può utilizzare direttamente questa subnet. Devi eseguire il provisioning di una subnet IPv6 interna (INTERNAL) dedicata e fare riferimento alla subnet utilizzando l'annotazione networking.gke.io/load-balancer-subnet nel tuo servizio:

  1. Crea una subnet IPv6 interna dedicata:

     gcloud compute networks subnets create SUBNET_NAME \
         --stack-type=ipv6_only \
         --ipv6-access-type=INTERNAL \
         --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 e fai riferimento al nome della subnet del passaggio precedente nell'annotazione networking.gke.io/load-balancer-subnet:

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

1. Verifica l'indirizzo IP del servizio assegnato:

   kubectl get svc ilb-ipv6-svc
   

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

   NAME           TYPE           CLUSTER-IP                          EXTERNAL-IP               PORT(S)        AGE
   ilb-ipv6-svc   LoadBalancer   2600:2d00:0:4:1a1e:d3b3:de4d:c549   fd20:f5d:a91f:3:0:9:0:0   80:30234/TCP   3m
   

Per saperne di più, consulta Servizi LoadBalancer IPv6.

Utilizza Bring Your Own IPv6 (BYOIPv6)

Per configurare un servizio LoadBalancer interno IPv6 con Bring Your Own IPv6 (BYOIPv6), crea una subnet con un intervallo di indirizzi BYOIPv6 interno e fai riferimento alla subnet nel servizio. L'intervallo di indirizzi IPv6 della subnet deve provenire da un sottoprefisso IPv6 regionale di un prefisso delegato pubblico (PDP) in modalità INTERNAL_IPV6_SUBNETWORK_CREATION.

Attenzione: GKE non supporta l'annotazione networking.gke.io/ip-collection-v6 per i servizi LoadBalancer interni. Se utilizzi questa annotazione, GKE la ignora ed emette un evento di avviso IPCollectionV6Error. Per saperne di più, vedi Problemi noti.

Prima di creare il servizio, verifica di avere un sottoprefisso IPv6 regionale in modalità INTERNAL_IPV6_SUBNETWORK_CREATION nella stessa regione del cluster. Per saperne di più, consulta Crea sottoprefissi IPv6 e Crea subnet con intervalli BYOIP IPv6.

1. Nella stessa regione e rete VPC del cluster, crea una subnet con un intervallo BYOIPv6 interno dal sottoprefisso:

   gcloud compute networks subnets create BYOIP_SUBNET_NAME \
       --network=NETWORK_NAME \
       --region=REGION \
       --stack-type=IPV6_ONLY \
       --ipv6-access-type=INTERNAL \
       --ip-collection=projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME
   

   Sostituisci quanto segue:

   • BYOIP_SUBNET_NAME: il nome della nuova subnet.
   • NETWORK_NAME: il nome della rete VPC del tuo cluster.
   • 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à INTERNAL_IPV6_SUBNETWORK_CREATION.

2. (Facoltativo) Prenota un intervallo di indirizzi IPv6 /96 interni statici dalla subnet BYOIPv6. Se salti questo passaggio, GKE alloca automaticamente un intervallo di indirizzi BYOIPv6 interni temporanei dalla subnet specificata nell'annotazione networking.gke.io/load-balancer-subnet:

   gcloud compute addresses create STATIC_IPV6_NAME \
       --region=REGION \
       --subnet=BYOIP_SUBNET_NAME \
       --ip-version=IPV6
   

   Sostituisci STATIC_IPV6_NAME con un nome per la risorsa dell'indirizzo IPv6 statico.

3. Salva il seguente manifest come ilb-byoipv6-svc.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: ilb-byoipv6-svc
     annotations:
       networking.gke.io/load-balancer-subnet: BYOIP_SUBNET_NAME
       # Optional: To use a static address, uncomment the following line
       # networking.gke.io/load-balancer-ip-addresses: STATIC_IPV6_NAME
   spec:
     type: LoadBalancer
     loadBalancerClass: networking.gke.io/l4-regional-internal
     ipFamilyPolicy: SingleStack
     ipFamilies:
     - IPv6
     selector:
       app: ilb-deployment
     ports:
     - name: tcp-port
       protocol: TCP
       port: 80
       targetPort: 8080
   

   Sostituisci BYOIP_SUBNET_NAME con il nome della subnet BYOIPv6 che hai creato. Per impostazione predefinita, GKE alloca un intervallo di indirizzi BYOIPv6 interni temporanei da questa subnet.

   (Facoltativo) Se hai prenotato un indirizzo BYOIPv6 interno statico nel passaggio precedente, rimuovi il commento dall'annotazione networking.gke.io/load-balancer-ip-addresses e sostituisci STATIC_IPV6_NAME con il nome della risorsa indirizzo IPv6 statico.

4. Applica il manifest al tuo cluster:

   kubectl apply -f ilb-byoipv6-svc.yaml
   

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

Abilita il logging per i servizi di backend

Puoi abilitare, disabilitare e visualizzare i log per un bilanciatore del carico di rete passthrough interno. Per abilitare il logging per i servizi di backend, devi abilitare la suddivisione in sottoinsiemi GKE.

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 ilb-svc.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: ilb-svc
     annotations:
       networking.gke.io/load-balancer-type: "Internal"
       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 ilb-svc.yaml
   

Scala i workload con l'affinità a livello di zona

Poiché HorizontalPodAutoscaler (HPA) scala i pod in base alle metriche aggregate del cluster anziché al carico per zona, disaccoppia i workload per zona per evitare il sovraccarico della zona. Anziché un singolo deployment e un singolo HPA a livello di cluster, crea un deployment e un HPA separati per ogni zona in cui opera il cluster. Un singolo servizio LoadBalancer interno può instradare il traffico a tutti questi workload a livello di zona indipendenti contemporaneamente.

Panoramica dell'architettura

• Un workload per zona: crea deployment separati per ogni zona (ad esempio zone-a, zone-b).
• Selettori di nodi: associa ogni deployment alla zona specifica utilizzando il selettore di nodi topology.kubernetes.io/zone.
• Un HPA per zona: collega un HPA a ogni deployment specifico in modo che i relativi pod vengano scalati in modo indipendente in base alle metriche localizzate.
• Un servizio condiviso: esponi tutti questi deployment dietro un unico servizio LoadBalancer interno configurato con affinità di zona (utilizzando lo stesso selettore).

Configura workload a livello di zona indipendenti

L'esempio seguente mostra come implementare questa architettura in due zone.

1. Crea un deployment separato per ogni zona. I deployment condividono la stessa etichetta app, ma hanno un nodeSelector rigoroso che li associa a una zona specifica.

   Salva il seguente manifest come zonal-deployments.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-app-zone-a
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: my-app
         zone: zone-a
     template:
       metadata:
         labels:
           app: my-app
           zone: zone-a
       spec:
         nodeSelector:
           topology.kubernetes.io/zone: "COMPUTE_ZONE_A"
         containers:
         - name: echoserver
           image: gcr.io/google_containers/echoserver:1.10
           ports:
           - containerPort: 8080
           resources:
             requests:
               cpu: "100m"
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-app-zone-b
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: my-app
         zone: zone-b
     template:
       metadata:
         labels:
           app: my-app
           zone: zone-b
       spec:
         nodeSelector:
           topology.kubernetes.io/zone: "COMPUTE_ZONE_B"
         containers:
         - name: echoserver
           image: gcr.io/google_containers/echoserver:1.10
           ports:
           - containerPort: 8080
           resources:
             requests:
               cpu: "100m"
   

   Sostituisci COMPUTE_ZONE_A e COMPUTE_ZONE_B con le tue zone effettive (ad esempio, us-central1-a e us-central1-b).

2. Applica il manifest:

   kubectl apply -f zonal-deployments.yaml
   

3. Crea un HPA indipendente per ogni deployment a livello di zona.

   Salva il seguente manifest come zonal-hpas.yaml:

   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: hpa-zone-a
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: my-app-zone-a
     minReplicas: 2
     maxReplicas: 10
     metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 70
   ---
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: hpa-zone-b
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: my-app-zone-b
     minReplicas: 2
     maxReplicas: 10
     metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 70
   

4. Applica il manifest:

   kubectl apply -f zonal-hpas.yaml
   

5. Assicurati che il servizio abbia come target l'etichetta condivisa (app: my-app) e che l'affinità di zona sia abilitata.

   Salva il seguente manifest come zonal-service.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: my-app-service-internal
   spec:
     type: LoadBalancer
     loadBalancerClass: networking.gke.io/l4-regional-internal
     trafficDistribution: PreferSameZone
     selector:
       app: my-app
     ports:
     - name: tcp-port
       protocol: TCP
       port: 8080
       targetPort: 8080
   

6. Applica il manifest:

   kubectl apply -f zonal-service.yaml
   

Verifica i componenti del bilanciatore del carico di rete passthrough interno

Questa sezione mostra come verificare i componenti chiave del bilanciatore del carico di rete passthrough interno.

• Verifica che il servizio sia in esecuzione:

  kubectl get service SERVICE_NAME --output yaml
  

  Sostituisci SERVICE_NAME con il nome del manifest del servizio.

  Se hai attivato l'affinità di zona, l'output include il parametro spec.trafficDistribution. Il valore di questo campo è impostato su PreferSameZone o PreferClose se la versione del cluster è precedente alla 1.35.0-gke.1811000.

• Verifica l'indirizzo IP della regola di forwarding del bilanciatore del carico di rete passthrough interno. L'indirizzo IP della regola di forwarding del bilanciatore del carico di rete passthrough interno è 10.128.15.245 nell'esempio incluso nella sezione Crea un servizio LoadBalancer interno. Verifica che questa regola di forwarding sia inclusa nell'elenco delle regole di forwarding nel progetto del cluster utilizzando Google Cloud CLI:

  gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"
  

  L'output include la regola di forwarding del bilanciatore del carico di rete passthrough interno pertinente, il suo indirizzo IP e il servizio di backend a cui fa riferimento la regola di forwarding (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r in questo esempio).

  NAME                          ... IP_ADDRESS  ... TARGET
  ...
  k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r   10.128.15.245   ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
  

• Descrivi il servizio di backend del bilanciatore del carico utilizzando Google Cloud CLI:

  gcloud compute backend-services describe k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION
  

  Sostituisci COMPUTE_REGION con la regione di computing del servizio di backend.

  Se hai attivato l'affinità di zona:

  • Il campo networkPassThroughLbTrafficPolicy.zonalAffinity.spillover deve essere impostato sul valore ZONAL_AFFINITY_SPILL_CROSS_ZONE.
  • Il campo networkPassThroughLbTrafficPolicy.zonalAffinity.spilloverRatio deve essere impostato su 0 o non deve essere incluso.

  L'output include i NEG di backend GCE_VM_IP per il servizio (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r in questo esempio).

  backends:
  - balancingMode: CONNECTION
    group: .../ZONE_NAME/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
  ...
  kind: compute#backendService
  loadBalancingScheme: INTERNAL
  name: aae3e263abe0911e9b32a42010a80008
  networkPassThroughLbTrafficPolicy:
    zonalAffinity:
      spillover: ZONAL_AFFINITY_SPILL_CROSS_ZONE
  protocol: TCP
  ...
  

  Se hai disattivato l'affinità di zona, il campo networkPassThroughLbTrafficPolicy.zonalAffinity.spillover deve essere impostato su ZONAL_AFFINITY_DISABLED o non deve essere incluso. Tieni presente che l'affinità di zona viene disattivata automaticamente se il cluster utilizza una versione precedente alla 1.33.3-gke.1392000.

• Determina l'elenco di nodi in un sottoinsieme per un servizio:

  gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
      --zone=COMPUTE_ZONE
  

  Sostituisci quanto segue:

  • NEG_NAME: il nome del gruppo di endpoint di rete creato dal controller GKE.
  • COMPUTE_ZONE: la zona di computing del gruppo di endpoint di rete su cui operare.

• Determina l'elenco dei nodi integri per un bilanciatore del carico di rete passthrough interno:

  gcloud compute backend-services get-health SERVICE_NAME \
      --region=COMPUTE_REGION
  

  Sostituisci quanto segue:

  • SERVICE_NAME: il nome del servizio di backend. Questo valore corrisponde al nome del gruppo di endpoint di rete creato dal controller GKE.
  • COMPUTE_REGION: la regione di computing del servizio di backend su cui operare.

• Verifica che Cloud Logging sia stato abilitato per il servizio:

  kubectl get svc SERVICE_NAME --output yaml
  

  Sostituisci quanto segue:

  • SERVICE_NAME: il nome del servizio.

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

Testa la connettività al bilanciatore del carico di rete passthrough interno

Il bilanciatore del carico di rete passthrough interno è accessibile solo all'interno della stessa rete VPC (o di una rete connessa). Per impostazione predefinita, la regola di forwarding del bilanciatore del carico ha l'accesso globale disabilitato, quindi le VM client, i tunnel Cloud VPN o i collegamenti Cloud Interconnect (VLAN) devono trovarsi nella stessa regione del bilanciatore del carico di rete passthrough interno. Per supportare i client in tutte le regioni, puoi attivare l'accesso globale nella regola di forwarding del bilanciatore del carico includendo l'annotazione global access nel manifest del servizio.

Esegui questo comando nella stessa regione del cluster:

curl LOAD_BALANCER_IP:80

Sostituisci LOAD_BALANCER_IP con l'indirizzo IP della regola di forwarding del bilanciatore del carico.

La risposta mostra l'output di ilb-deployment:

Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n

Elimina il servizio LoadBalancer interno e le risorse del bilanciatore del carico

Puoi eliminare il deployment e il servizio utilizzando kubectl delete o la consoleGoogle Cloud .

kubectl

Elimina il deployment

Per eliminare il deployment, esegui questo comando:

kubectl delete deployment ilb-deployment

Elimina il servizio

Per eliminare il servizio, esegui questo comando:

kubectl delete service ilb-svc

Console

Elimina il deployment

Per eliminare il deployment, segui questi passaggi:

1. Vai alla pagina Workload nella console Google Cloud .

   Vai a Carichi di lavoro

2. Seleziona il deployment che vuoi eliminare, quindi fai clic su Elimina.

3. Quando ti viene richiesto di confermare, seleziona la casella di controllo Elimina HorizontalPodAutoscaler con associazione a deployment selezionato, quindi fai clic su Elimina.

Elimina il servizio

Per eliminare il servizio, segui questi passaggi:

1. Vai alla pagina Servizi e Ingress nella console Google Cloud .

   Vai a Servizi e Ingress

2. Seleziona il servizio che vuoi eliminare, quindi fai clic su Elimina.

3. Quando ti viene richiesto di confermare, fai clic su Elimina.

IP condiviso

Il bilanciatore del carico di rete passthrough interno consente la condivisione di un indirizzo IP virtuale tra più regole di forwarding. Questo è utile per espandere il numero di porte simultanee sullo stesso IP o per accettare il traffico UDP e TCP sullo stesso IP. Consente un massimo di 50 porte esposte per indirizzo IP. Gli IP condivisi sono supportati in modo nativo sui cluster GKE con servizi LoadBalancer interni. Durante il deployment, il campo loadBalancerIP del servizio viene utilizzato per indicare quale IP deve essere condiviso tra i servizi.

Limitazioni

Un IP condiviso per più bilanciatori del carico presenta le seguenti limitazioni e funzionalità:

• Ogni regola di forwarding può avere fino a cinque porte (contigue o non contigue) oppure può essere configurata in modo da trovare una corrispondenza con il traffico e inoltrarlo su tutte le porte. Se un servizio di bilanciatore del carico interno definisce più di cinque porte, la regola di forwarding verrà impostata automaticamente in modo da corrispondere a tutte le porte.
• Un massimo di dieci servizi (regole di forwarding) possono condividere un indirizzo IP. In questo modo, vengono assegnate al massimo 50 porte per IP condiviso.
• Ogni regola di forwarding che condivide lo stesso indirizzo IP deve utilizzare una combinazione univoca di protocolli e porte. Pertanto, ogni servizio LoadBalancer interno deve utilizzare un insieme univoco di protocolli e porte.
• È supportata una combinazione di servizi solo TCP e solo UDP sullo stesso IP condiviso, ma non puoi esporre porte TCP e UDP nello stesso servizio.
• L'IP condiviso è supportato solo per gli indirizzi IPv4 interni. Non puoi condividere un intervallo di indirizzi IPv6 interni statici tra più servizi LoadBalancer interni.

Attivazione dell'IP condiviso

Per consentire a un servizio LoadBalancer interno di condividere un IP comune, segui questi passaggi:

1. Crea un IP interno statico con --purpose SHARED_LOADBALANCER_VIP. Per poter essere condiviso, un indirizzo IP deve essere creato con questo scopo. Se crei l'indirizzo IP interno statico in un VPC condiviso, devi creare l'indirizzo IP nello stesso progetto di servizio dell'istanza che utilizzerà l'indirizzo IP, anche se il valore dell'indirizzo IP proviene dall'intervallo di IP disponibili in una subnet condivisa selezionata della rete VPC condivisa. Per saperne di più, consulta la sezione Prenotazione di un IP interno statico nella pagina Provisioning del VPC condiviso.

2. Esegui il deployment di un massimo di dieci servizi LoadBalancer interni utilizzando questo IP statico nel campo loadBalancerIP. I bilanciatori del carico di rete passthrough interni vengono riconciliati dal controller di servizio GKE ed è stato eseguito il deployment utilizzando lo stesso IP frontend.

L'esempio seguente mostra come eseguire questa operazione per supportare più porte TCP e UDP per lo stesso IP del bilanciatore del carico interno.

1. Crea un IP statico nella stessa regione del cluster GKE. La subnet deve essere la stessa utilizzata dal bilanciatore del carico, che per impostazione predefinita è la stessa utilizzata dagli IP dei nodi del cluster GKE.

   Se il cluster e la rete VPC si trovano nello stesso progetto:

   gcloud compute addresses create IP_ADDR_NAME \
       --project=PROJECT_ID \
       --subnet=SUBNET \
       --addresses=IP_ADDRESS \
       --region=COMPUTE_REGION \
       --purpose=SHARED_LOADBALANCER_VIP
   

   Se il cluster si trova in un progetto di servizio VPC condiviso, ma utilizza una rete VPC condivisa in un progetto host:

   gcloud compute addresses create IP_ADDR_NAME \
       --project=SERVICE_PROJECT_ID \
       --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET \
       --addresses=IP_ADDRESS \
       --region=COMPUTE_REGION \
       --purpose=SHARED_LOADBALANCER_VIP
   

   Sostituisci quanto segue:

   • IP_ADDR_NAME: un nome per l'oggetto indirizzo IP.
   • SERVICE_PROJECT_ID: l'ID del progetto di servizio.
   • PROJECT_ID: l'ID del progetto (singolo progetto).
   • HOST_PROJECT_ID: l'ID del progetto host del VPC condiviso.
   • COMPUTE_REGION: la regione di computing contenente la subnet condivisa.
   • IP_ADDRESS: un indirizzo IP interno non utilizzato dall'intervallo di indirizzi IP principale della subnet selezionata. Se non specifichi un indirizzo IP, Google Cloud seleziona un indirizzo IP interno non utilizzato dall'intervallo di indirizzi IP principale della subnet selezionata. Per determinare un indirizzo selezionato automaticamente, devi eseguire gcloud compute addresses describe.
   • SUBNET: il nome della subnet condivisa.

2. Salva la seguente configurazione del servizio TCP in un file denominato tcp-service.yaml, quindi esegui il deployment nel cluster. Sostituisci IP_ADDRESS con l'indirizzo IP scelto nel passaggio precedente.

   apiVersion: v1
   kind: Service
   metadata:
     name: tcp-service
     namespace: default
   spec:
     type: LoadBalancer
     # Request an internal load balancer.
     loadBalancerClass: networking.gke.io/l4-regional-internal
     # Use an IP address that you create.
     loadBalancerIP: IP_ADDRESS
     selector:
       app: myapp
     ports:
     - name: 8001-to-8001
       protocol: TCP
       port: 8001
       targetPort: 8001
     - name: 8002-to-8002
       protocol: TCP
       port: 8002
       targetPort: 8002
     - name: 8003-to-8003
       protocol: TCP
       port: 8003
       targetPort: 8003
     - name: 8004-to-8004
       protocol: TCP
       port: 8004
       targetPort: 8004
     - name: 8005-to-8005
       protocol: TCP
       port: 8005
       targetPort: 8005
   

3. Applica questa definizione di servizio al tuo cluster:

   kubectl apply -f tcp-service.yaml
   

4. Salva la seguente configurazione del servizio UDP in un file denominato udp-service.yaml, quindi eseguine il deployment. Utilizza anche il valore IP_ADDRESS specificato nel passaggio precedente.

   apiVersion: v1
   kind: Service
   metadata:
     name: udp-service
     namespace: default
   spec:
     type: LoadBalancer
     # Request an internal load balancer.
     loadBalancerClass: networking.gke.io/l4-regional-internal
     # Use the same IP address that you used for the TCP Service.
     loadBalancerIP: IP_ADDRESS
     selector:
       app: my-udp-app
     ports:
     - name: 9001-to-9001
       protocol: UDP
       port: 9001
       targetPort: 9001
     - name: 9002-to-9002
       protocol: UDP
       port: 9002
       targetPort: 9002
   

5. Applica questo file al tuo cluster:

   kubectl apply -f udp-service.yaml
   

6. Verifica che il VIP sia condiviso tra le regole di forwarding del bilanciatore del carico elencandole e filtrandole in base all'IP statico. Ciò dimostra che esiste una regola di forwarding UDP e una TCP, entrambe in ascolto su sette porte diverse sull'IP_ADDRESS condiviso, che in questo esempio è 10.128.2.98.

   gcloud compute forwarding-rules list | grep 10.128.2.98
   ab4d8205d655f4353a5cff5b224a0dde                         us-west1   10.128.2.98     UDP          us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde
   acd6eeaa00a35419c9530caeb6540435                         us-west1   10.128.2.98     TCP          us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435
   

Problemi noti

Errore durante la creazione del bilanciatore del carico nel livello Standard

Quando crei un bilanciatore del carico di rete passthrough interno in un progetto con il livello di rete predefinito del progetto impostato su Standard, viene visualizzato il seguente messaggio di errore:

Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: STANDARD network tier (the project's default network tier) is not supported: Network tier other than PREMIUM is not supported for loadBalancingScheme=INTERNAL., badRequest

Per risolvere questo problema nelle versioni di GKE precedenti alla 1.23.3-gke.900, configura il livello di rete predefinito del progetto su Premium.

Questo problema è stato risolto nelle versioni GKE 1.23.3-gke.900 e successive quando è abilitato il gke-subsetting.

Il controller GKE crea bilanciatori del carico di rete passthrough interni nel livello di rete Premium anche se il livello di rete predefinito del progetto è impostato su Standard.

Errore durante l'utilizzo dell'annotazione networking.gke.io/ip-collection-v6 su un servizio LoadBalancer interno

Quando aggiungi l'annotazione networking.gke.io/ip-collection-v6 a un servizio LoadBalancer interno, GKE genera un evento di avviso IPCollectionV6Error con il seguente messaggio:

networking.gke.io/ip-collection-v6 is not supported for Internal LoadBalancers. To use BYOIPv6 with ILB, specify a BYOIP subnet using the "networking.gke.io/load-balancer-subnet" annotation

L'annotazione networking.gke.io/ip-collection-v6 si applica solo ai servizi LoadBalancer esterni IPv6 a stack singolo. Per utilizzare gli indirizzi BYOIPv6 con un servizio LoadBalancer interno, crea una subnet con un intervallo di indirizzi IPv6 interni da un prefisso delegato pubblico in modalità INTERNAL_IPV6_SUBNETWORK_CREATION. Specifica la subnet utilizzando l'annotazione networking.gke.io/load-balancer-subnet. Per saperne di più, consulta Utilizza Bring Your Own IPv6 (BYOIPv6).

Passaggi successivi

• Leggi la panoramica della rete GKE.
• Scopri di più sui bilanciatori del carico di Compute Engine.
• Scopri come creare un cluster nativo di VPC.
• Risolvi i problemi di bilanciamento del carico in GKE.
• Scopri di più sull'agente di IP masquerading.
• Scopri di più sulla configurazione delle reti autorizzate.