Crea un bilanciatore del carico interno (original) (raw)

Questa pagina spiega come creare unbilanciatore del carico di rete passthrough interno o un bilanciatore del carico interno su Google Kubernetes Engine (GKE). Per creare un bilanciatore del carico di rete passthrough esterno, consultaCreare un servizio di tipo LoadBalancer.

Prima di leggere questa pagina, assicurati di conoscere i seguenti concetti:

Utilizzo del bilanciatore del carico di rete passthrough interno

I bilanciatori del carico di rete passthrough interni rendono i servizi del tuo cluster accessibili ai client situati nella rete VPC del cluster e ai client nelle reti collegate alla rete VPC del cluster. I client nella rete VPC del cluster possono essere nodi o pod del cluster oppure VM al di fuori del cluster. Per ulteriori informazioni sulla connettività dei client nelle reti collegate, consulta Bilanciatori del carico di rete passthrough interni e reti collegate.

Utilizzo dell'impostazione secondaria GKE

Il sottoinsieme GKE migliora la scalabilità dei servizi LoadBalancer interni perché utilizza i GCE_VM_IP gruppi di endpoint di rete (NEG) come backend anziché i gruppi di istanze. Quando il sottoinsieme GKE è attivo, GKE crea un NEG per compute zone per servizio LoadBalancer interno.

Il externalTrafficPolicy del servizio controlla l'appartenenza dei nodi ai backend GCE_VM_IPNEG. Per ulteriori informazioni, vedi Adesione ai nodi nei backend GCE_VM_IP NEG.

Requisiti e limitazioni

Di seguito sono riportati i requisiti e le limitazioni per i bilanciatori del carico interni.

Requisiti

Il sottoinsieme GKE presenta i seguenti requisiti e limitazioni:

Limitazioni

Bilanciatori del carico di rete passthrough interni

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

Abilita l'impostazione secondaria GKE in un nuovo cluster standard

Puoi creare un cluster standard con il sottoinsieme GKE attivato utilizzando Google Cloud CLI, la Google Cloud console o Terraform. Un cluster creato con l'impostazione secondaria GKE abilitata sempre utilizza l'impostazione secondaria GKE.

Console

  1. Nella Google Cloud console, vai alla pagina Crea un cluster Kubernetes.
    Vai a Crea un cluster Kubernetes
  2. Configura il cluster come preferisci.
  3. Nel riquadro di navigazione, in Cluster, fai clic su Networking.
  4. Seleziona la casella di controllo Abilita impostazione secondaria per i bilanciatori del carico interni L4.
  5. Fai clic su Crea.

gcloud

gcloud container clusters create CLUSTER_NAME \
  --cluster-version=VERSION \
  --enable-l4-ilb-subsetting \
  --location=COMPUTE_LOCATION

Sostituisci quanto segue:

Se vuoi utilizzare una rete o una sottorete non predefinita, esegui il seguente comando:

gcloud container clusters create CLUSTER_NAME \
  --cluster-version=VERSION \
  --network NETWORK_NAME \
  --subnetwork SUBNETWORK_NAME \
  --enable-l4-ilb-subsetting \
  --location=COMPUTE_LOCATION

Sostituisci quanto segue:

Terraform

Per creare un cluster standard con il sottoinsieme GKE attivato utilizzando Terraform, consulta il seguente esempio:

Per scoprire di più sull'utilizzo di Terraform, consultaSupporto di Terraform per GKE.

Abilitare l'impostazione secondaria GKE in un cluster esistente

Puoi abilitare l'impostazione secondaria GKE per un cluster esistente utilizzando la gcloud CLI o la Google Cloud console. Non puoi disabilitare il sottoinsieme GKE dopo averlo attivato.

Console

  1. Nella Google Cloud console, 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 \
    --enable-l4-ilb-subsetting

Sostituisci quanto segue:

L'attivazione del sottoinsieme GKE non interrompe i servizi LoadBalancer interni esistenti. Se vuoi eseguire la migrazione dei servizi LoadBalancer interni esistenti in modo che utilizzino servizi di backend con NEG GCE_VM_IP come backend, devi eseguire il deployment di un manifest del servizio sostitutivo. Per ulteriori dettagli, consultaRaggruppamento dei nodinella documentazione relativa ai concetti del servizio LoadBalancer.

Esegui il deployment di un carico di lavoro

Il manifest seguente 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
  1. Applica il manifest al cluster:
kubectl apply -f ilb-deployment.yaml

Creare un servizio LoadBalancer interno

  1. (Facoltativo) Disabilita la creazione automatica delle regole firewall VPC:
    Sebbene GKE crei automaticamente le regole firewall VPC per consentire il traffico al bilanciatore del carico interno, hai la possibilità di disattivare la creazione automatica delle regole firewall VPC e di gestire autonomamente le regole firewall. Puoi disabilitare le regole firewall VPC solo se hai attivato l'impostazione secondaria GKE per il tuo 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 del firewall VPC, assicurati di definire regole di autorizzazione che consentano al traffico di raggiungere il bilanciatore del carico e i pod delle applicazioni.
    Per ulteriori informazioni sulla gestione delle regole firewall VPC, consulta la sezione Gestire la creazione automatica delle regole firewall e su come disattivare la creazione automatica delle regole firewall, consulta la sezione Regole firewall gestite dall'utente per i servizi LoadBalancer GKE.
  2. Il seguente esempio crea un servizio LoadBalancer interno che utilizza la porta TCP 80. GKE esegue il deployment di un bilanciatore del carico di rete passthrough interno la cui regola di inoltro 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  
  annotations:  
    networking.gke.io/load-balancer-type: "Internal"  
spec:  
  type: LoadBalancer  
  externalTrafficPolicy: Cluster  
  selector:  
    app: ilb-deployment  
  ports:  
  - name: tcp-port  
    protocol: TCP  
    port: 80  
    targetPort: 8080

    Il file manifest deve contenere quanto segue:
    * Un name per il servizio LoadBalancer interno, in questo caso ilb-svc.
    * Un'annotazione che specifica che è necessario un servizio LoadBalancer interno. Per GKE 1.17 e versioni successive, utilizza l'annotazionenetworking.gke.io/load-balancer-type: "Internal" come mostrato nel manifest di esempio. Per le versioni precedenti, utilizzacloud.google.com/load-balancer-type: "Internal".
    * L'elemento type: LoadBalancer.
    * Un campo spec: selector per specificare i pod di destinazione del servizio, 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 pubblicazione.
    * I valori port e targetPort non devono essere necessariamente uguali. I nodi eseguono sempre la NAT di destinazione, modificando l'indirizzo IP della regola di forwarding di inoltro del bilanciatore del carico di destinazione e port in un indirizzo IP del pod di destinazione e targetPort. Per ulteriori dettagli, consulta Traduzione dell'indirizzo di rete di destinazione sui nodi nella documentazione relativa ai concetti del servizio LoadBalancer.
    Il file manifest può contenere quanto segue:
    * spec.ipFamilyPolicy e ipFamilies per definire in che modo GKE alloca gli indirizzi IP al servizio. GKE supporta i 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 inoltro del bilanciatore del carico di rete passthrough interno distinte: una per il traffico IPv4 e una per il traffico IPv6. Il servizio LoadBalancer dual-stack GKE è disponibile nella versione 1.29 o successive. Per saperne di più, consultaServizi IPv4/IPv6 a doppio stack.
    Per ulteriori informazioni, consulta Parametri del servizio LoadBalancer.
    2. Applica il manifest al cluster: 

    kubectl apply -f ilb-svc.yaml
  3. Visualizza 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  
    nodePort: 30521  
    port: 80  
    protocol: TCP  
    targetPort: 8080  
  selector:  
    app: ilb-deployment  
  sessionAffinity: None  
  type: LoadBalancer  
status:  
  loadBalancer:  
    ingress:  
    - ip: 10.128.15.245

L'output ha i seguenti attributi:

  1. Controlla 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 chiamato k8s2-knlc4c77-default-ilb-svc-ua5ugas0. Questa annotazione è presente nei servizi di tipo LoadBalancer che utilizzano il sottoinsieme GKE e non è presente nei servizi che non utilizzano il sottoinsieme GKE.

Verifica i componenti del bilanciatore del carico di rete passthrough interno

L'indirizzo IP della regola di forwarding di inoltro del bilanciatore del carico di rete passthrough interno è 10.128.15.245 nell'esempio incluso nella sezione Creare un servizio LoadBalancer interno. Puoi vedere che questa regola di forwarding è inclusa nell'elenco delle regole di inoltro 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 relativo 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

Puoi descrivere il servizio di backend del bilanciatore del carico utilizzando Google Cloud CLI:

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

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

L'output include il NEG o i NEG GCE_VM_IP di backend 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
...

Per determinare l'elenco dei nodi in un sottoinsieme per un servizio, utilizza il seguente comando:

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

Sostituisci quanto segue:

Per determinare l'elenco dei nodi operativi per un bilanciatore del carico di rete passthrough interno, utilizza il seguente comando:

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

Sostituisci quanto segue:

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

Esegui il seguente 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

Il bilanciatore del carico di rete passthrough interno è accessibile solo all'interno della stessa rete VPC (o di una rete collegata). Per impostazione predefinita, l'accesso globale è disattivato nella regola di forwarding del bilanciatore del carico, pertanto le VM client, i tunnel Cloud VPN o gli attacchi (VLAN) Cloud Interconnect 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 file manifest del servizio.

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 il seguente comando:

kubectl delete deployment ilb-deployment

Elimina il servizio

Per eliminare il servizio, esegui il seguente comando:

kubectl delete service ilb-svc

Console

Elimina il deployment

Per eliminare il deployment:

  1. Vai alla pagina Workload nella Google Cloud console.
    Vai a Carichi di lavoro
  2. Seleziona il deployment da eliminare e fai clic su Elimina.
  3. Quando ti viene chiesto di confermare, seleziona la casella di controllo Elimina Horizontal Pod Autoscaler 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 Google Cloud console.
    Vai a Servizi e Ingress
  2. Seleziona il servizio che vuoi eliminare e fai clic su Elimina.
  3. Quando ti viene richiesto di confermare, fai clic su Elimina.

Il bilanciatore del carico di rete passthrough interno consente lacondivisione di un indirizzo IP virtuale tra più regole di inoltro. Questo è utile per espandere il numero di porte simultanee sullo stesso IP o per accettare traffico UDP e TCP sullo stesso IP. Consente fino a un massimo di 50 porte esposte per indirizzo IP. Gli IP condivisi sono supportati in modo nativo nei 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à:

Abilitazione dell'IP condiviso

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

  1. Crea un IP interno statico con --purpose SHARED_LOADBALANCER_VIP. A questo scopo, è necessario creare un indirizzo IP che possa essere condiviso. Se crei l'indirizzo IP interno statico in un VPC condiviso, devi creare l'indirizzo IP nello stesso progetto di servizio dell'istanza che lo utilizzerà, anche se il valore dell'indirizzo IP proviene dall'intervallo di IP disponibili in una subnet condivisa selezionata della rete VPC condivisa. Per ulteriori informazioni, consulta la sezione Prenotazione di un indirizzo IP interno statico nella pagina Provisioning di un VPC condiviso.
  2. Esegui il deployment di un massimo di dieci servizi LoadBalancer interni utilizzando questo indirizzo IP statico nelloadBalancerIP. I bilanciatori del carico di rete passthrough interni vengono riconciliati dal controller dei servizi GKE e vengono di cui viene eseguito il deployment utilizzando lo stesso indirizzo IP frontend.

L'esempio seguente mostra come viene eseguita questa operazione per supportare più porte TCP e UDP sullo stesso indirizzo IP del bilanciatore del carico interno.

  1. Crea un indirizzo IP statico nella stessa regione del tuo 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:

  1. Salva la seguente configurazione del servizio TCP in un file denominatotcp-service.yaml e poi esegui il deployment nel cluster. SostituisciIP_ADDRESS con l'indirizzo IP che hai scelto nel passaggio precedente.
apiVersion: v1  
kind: Service  
metadata:  
  name: tcp-service  
  namespace: default  
  annotations:  
    networking.gke.io/load-balancer-type: "Internal"  
spec:  
  type: LoadBalancer  
  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
  1. Applica questa definizione di servizio al tuo cluster:
kubectl apply -f tcp-service.yaml
  1. Salva la seguente configurazione del servizio UDP in un file denominato udp-service.yaml e poi esegui il deployment. Utilizza inoltre il valore IP_ADDRESS specificato nel passaggio precedente.
apiVersion: v1  
kind: Service  
metadata:  
  name: udp-service  
  namespace: default  
  annotations:  
    networking.gke.io/load-balancer-type: "Internal"  
spec:  
  type: LoadBalancer  
  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
  1. Applica questo file al tuo cluster:
kubectl apply -f udp-service.yaml
  1. Verifica che il VIP sia condiviso tra le regole di inoltro del bilanciatore del carico elencandole e filtrando per l'IP statico. Ciò indica che esistono una regola di forwarding UDP e una TCP che ascoltano su sette porte diverse sul 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

Timeout della connessione ogni 10 minuti

I servizi LoadBalancer interni creati con il sottoinsieme potrebbero registrare interruzioni del traffico ogni circa 10 minuti. Questo bug è stato corretto nelle versioni:

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 illivello di rete predefinito del progettoimpostato 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 il 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 sottoinsieme GKE.

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.

Passaggi successivi