Bilanciamento del carico nativo del container tramite NEG standalone a livello di zona

Questa pagina mostra come creare un servizio Kubernetes supportato da un gruppo di endpoint di rete (NEG) zonale GCE_VM_IP_PORT in uncluster Google Kubernetes Engine (GKE) VPC nativo.

Per informazioni sui vantaggi, i requisiti e le limitazioni del bilanciamento del carico nativo del container, vedi Bilanciamento del carico nativo del container.

Panoramica

Un NEG rappresenta un gruppo di endpoint. GKE supporta i NEG autonomi di tipo GCE_VM_IP_PORT. GCE_VM_IP_PORT I NEG supportano gli endpoint che utilizzano l'indirizzo IP interno principale della VM o un indirizzo IP di uno dei suoi intervalli IP alias.

Nel contesto di un cluster GKE nativo di VPC che utilizza NEG autonomi, ogni endpoint è un indirizzo IP del pod e una porta di destinazione. Gli indirizzi IP dei pod provengono dall'intervallo IP alias del nodo per i pod, che deriva dall'intervallo di indirizzi IP secondario della subnet per i pod del cluster.

GKE fornisce un controller NEG per gestire l'appartenenza dei NEG GCE_VM_IP_PORT. Puoi aggiungere i NEG che crea come backend ai servizi di backend per i bilanciatori del carico che configuri al di fuori dell'API GKE.

Il seguente diagramma descrive la corrispondenza tra gli oggetti API Kubernetes e gli oggetti Compute Engine.

Ingress con NEG

Quando i NEG vengono utilizzati con GKE Ingress, il controller Ingress facilita la creazione di tutti gli aspetti del bilanciatore del carico. Ciò include la creazione dell'indirizzo IP virtuale, delle regole di forwarding, dei controlli di integrità, delle regole firewall e altro ancora.

Ingress è il modo consigliato per utilizzare il bilanciamento del carico nativo del container, in quanto offre molte funzionalità che semplificano la gestione dei NEG. I NEG autonomi sono un'opzione se i NEG gestiti da Ingress non soddisfano il tuo caso d'uso.

NEG standalone

Quando i NEG vengono implementati con bilanciatori del carico di cui è stato eseguito il provisioning da qualsiasi altro elemento diverso da Ingress, vengono considerati NEG standalone. I NEG autonomi vengono implementati e gestiti tramite il controller NEG, ma le regole di forwarding, i controlli di integrità e altri oggetti di bilanciamento del carico vengono implementati manualmente.

I NEG standalone non sono in conflitto con il bilanciamento del carico nativo del container abilitato per Ingress.

L'illustrazione seguente mostra le differenze nel modo in cui gli oggetti di bilanciamento del carico vengono implementati in ogni scenario:

Prevenzione delle NEG trapelate

Con i NEG autonomi, sei responsabile della gestione dei cicli di vita dei NEG e delle risorse che compongono il bilanciatore del carico. Potresti divulgare NEGs nei seguenti modi:

• Quando un servizio GKE viene eliminato, il NEG associato non viene raccolto come spazzatura se il NEG viene ancora referenziato da un servizio di backend. Annulla il riferimento al NEG dal servizio di backend per consentire l'eliminazione del NEG.

• Quando un cluster viene eliminato, i NEG autonomi non vengono eliminati nei seguenti scenari:

  • Il NEG fa ancora riferimento a un servizio di backend.
  • Il processo di eliminazione del cluster arresta il controller NEG prima che possa eliminare il NEG.

  Per evitare NEG compromessi, dereferenzia il NEG dal servizio di backend ed elimina tutti i NEG prima di eliminare il cluster.

Se hai NEGs trapelati dopo aver eliminato il cluster o il servizio, puoi eliminarli utilizzando Google Cloud CLI.

Casi d'uso dei NEG autonomi

I NEG autonomi hanno diversi utilizzi fondamentali. I NEG standalone sono molto flessibili. Ciò è in contrasto con Ingress (utilizzato con o senza NEG), che definisce un insieme specifico di oggetti di bilanciamento del carico scelti in modo soggettivo per renderli semplici da usare.

I casi d'uso per i NEG autonomi includono:

Servizi eterogenei di container e VM

I NEG possono contenere indirizzi IP di VM e container. Ciò significa che un singolo indirizzo IP virtuale può puntare a un backend costituito da carichi di lavoro Kubernetes e non Kubernetes. Può essere utilizzato anche per eseguire la migrazione dei carichi di lavoro esistenti a un cluster GKE.

I NEG autonomi possono puntare agli IP delle VM, il che consente di configurare manualmente i bilanciatori del carico in modo che puntino ai backend costituiti da VM e container per lo stesso VIP del servizio.

Controller Ingress personalizzati

Puoi utilizzare un controller Ingress personalizzato (o nessun controller Ingress) per configurare i bilanciatori del carico che hanno come target i NEG autonomi.

Utilizzare Cloud Service Mesh con GKE

Puoi utilizzare Cloud Service Mesh con GKE. Cloud Service Mesh utilizza i NEG standalone per fornire il bilanciamento del carico nativo del container per ilmesh di servizih gestito.

Utilizzare i bilanciatori del carico di rete proxy esterni con GKE

Puoi utilizzare i NEG autonomi per bilanciare il carico direttamente sui container con il bilanciatore del carico di rete con proxy esterno, che non è supportato in modo nativo da Kubernetes/GKE.

Pod readiness

I cancelli di preparazione sono una funzionalità di estensibilità di Kubernetes che consente l'inserimento di feedback o segnali aggiuntivi in PodStatus per consentire al pod di passare allo stato Pronto. Il controller NEG gestisce un gate di preparazione personalizzato per garantire che il percorso di rete completo dal bilanciatore del carico Compute Engine al pod sia funzionante. Le porte di prontezza dei pod in GKE sono spiegate nel bilanciamento del carico nativo del container.

Ingress con NEG esegue il deployment e gestisce i controlli di integrità di Compute Engine per conto del bilanciatore del carico. Tuttavia, i NEG autonomi non fanno ipotesi sui controlli di integrità di Compute Engine perché devono essere implementati e gestiti separatamente. I controlli di integrità di Compute Engine devono essere sempre configurati insieme al bilanciatore del carico per impedire l'invio di traffico ai backend che non sono pronti a ricevere. Se non è associato alcuno stato di controllo di integrità al NEG (di solito perché non è configurato alcun controllo di integrità), il controller NEG imposta il valore del gate di preparazione del pod su True quando il relativo endpoint è programmato nel NEG.

Requisiti

Il cluster deve essere nativo di VPC. Per scoprire di più, consulta la sezione Creazione di un cluster nativo di VPC.

Il cluster deve avere il componente aggiuntivo HttpLoadBalancing abilitato. I cluster GKE hanno il componente aggiuntivo HttpLoadBalancing abilitato per impostazione predefinita.

Prima di iniziare

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

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

Utilizzo di NEG standalone

Le istruzioni riportate di seguito mostrano come utilizzare i NEG autonomi con un bilanciatore del carico HTTP esterno su GKE.

Devi creare i seguenti oggetti:

• Un deployment che crea e gestisce i pod.
• Un servizio che crea un NEG.
• Un bilanciatore del carico creato con l'API Compute Engine. Ciò è diverso dall'utilizzo di NEG con Ingress, nel qual caso Ingress crea e configura un bilanciatore del carico per te. Con i NEG autonomi, sei responsabile dell'associazione del NEG e del servizio di backend per connettere i pod al bilanciatore del carico. Il bilanciatore del carico è costituito da diversi componenti, mostrati nel seguente diagramma:

Crea un cluster nativo di VPC

I cluster Autopilot sono VPC nativi per impostazione predefinita, quindi puoi passare a Esegui il deployment di un carico di lavoro.

Per i cluster Standard, crea un cluster nativo di VPC nella zona us-central1-a:

gcloud container clusters create neg-demo-cluster \
    --create-subnetwork="" \
    --network=default \
    --location=us-central1-a

Creazione di un deployment

I manifest di esempio seguenti specificano i deployment che eseguono tre istanze di un server HTTP in container. Il server HTTP risponde alle richieste con il nome host del server delle applicazioni, il nome del pod su cui è in esecuzione il server.

Ti consigliamo di utilizzare i workload che utilizzano il feedback sulla prontezza dei pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

Salva questo manifest come neg-demo-app.yaml, quindi crea il deployment eseguendo il seguente comando:

kubectl apply -f neg-demo-app.yaml

crea un servizio

Il seguente manifest specifica un servizio in cui:

• Qualsiasi pod con l'etichetta run: neg-demo-app è membro di questo servizio.
• Il servizio ha un campo ServicePort con la porta 80.
• L'annotazione cloud.google.com/neg specifica che la porta 80 verrà associata a un NEG. Il campo facoltativo name specifica che il NEG verrà denominato NEG_NAME. Se il campo name viene omesso, verrà generato automaticamente un nome univoco. Per maggiori dettagli, vedi Assegnazione dei nomi ai NEGs.
• Ogni pod membro deve avere un container in ascolto sulla porta TCP 9376.

apiVersion: v1
kind: Service
metadata:
  name: neg-demo-svc
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'
spec:
  type: ClusterIP
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376

Sostituisci NEG_NAME con il nome del NEG. Il nome del NEG deve essere univoco nella regione.

Salva questo manifest come neg-demo-svc.yaml, quindi crea il servizio eseguendo il seguente comando:

kubectl apply -f neg-demo-svc.yaml

Un NEG viene creato entro pochi minuti dalla creazione del servizio.

Tipi di servizi

Sebbene questo esempio utilizzi un servizio ClusterIP, tutti e cinque i tipi di servizi supportano i NEG autonomi. Ti consigliamo il tipo predefinito, ClusterIP.

Denominazione dei NEG

Nelle versioni di GKE 1.18.18-gke.1200 e successive, puoi specificare un nome personalizzato per i NEG oppure GKE può generare automaticamente un nome. Le versioni precedenti di GKE supportano solo nomi NEG generati automaticamente.

GKE crea un NEG in ogni zona utilizzata dal cluster. Tutti i NEG utilizzano lo stesso nome.

Specifica di un nome

La specifica di un nome NEG personalizzato semplifica la configurazione del bilanciamento del carico perché conosci in anticipo il nome e le zone delle NEG. I nomi dei NEG personalizzati devono soddisfare i seguenti requisiti:

• Essere univoco per la zona del cluster per i cluster zonali o univoco per la regione per i cluster regionali.

• Non deve corrispondere al nome di alcun NEG esistente non creato dal controller NEG di GKE.

• Non deve contenere trattini bassi.

Utilizza il campo name nell'annotazione cloud.google.com/neg del servizio per specificare un nome NEG:

cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'

Sostituisci NEG_NAME con il nome del NEG. Il nome del NEG deve essere univoco nella regione.

Utilizzo di un nome generato automaticamente

I nomi NEG generati automaticamente sono univoci. Per utilizzare un nome generato automaticamente, ometti il campo name:

cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'

Il nome generato automaticamente ha il seguente formato:

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

Mappare le porte a più NEG

Un servizio può essere in ascolto su più di una porta. Per definizione, i NEG hanno un solo indirizzo IP e una sola porta. Ciò significa che se specifichi un servizio con più porte, verrà creato un NEG per ogni porta.

Il formato dell'annotazione cloud.google.com/neg è:

cloud.google.com/neg: '{
   "exposed_ports":{
      "SERVICE_PORT_1":{},
      "SERVICE_PORT_2":{},
      "SERVICE_PORT_3":{},
      ...
   }
 }'

In questo esempio, ogni istanza di SERVICE_PORT_N è un numero di porta distinto che fa riferimento alle porte di servizio esistenti del servizio. Per ogni porta di servizio elencata, il controller NEG crea un NEG in ogni zona occupata dal cluster.

Recuperare gli stati dei NEG

Utilizza questo comando per recuperare gli stati dei servizi del cluster:

kubectl get service neg-demo-svc -o yaml

L'output è simile al seguente:

cloud.google.com/neg-status: '{
   "network-endpoint-groups":{
      "SERVICE_PORT_1": "NEG_NAME_1",
      "SERVICE_PORT_2": "NEG_NAME_2",
      ...
   },
   "zones":["ZONE_1", "ZONE_2", ...]
}

In questo output, ogni elemento nel mapping network-endpoint-groups è una porta di servizio (come SERVICE_PORT_1) e il nome dei NEG gestiti corrispondenti (come NEG_NAME_1). L'elenco zones contiene ogni zona (come ZONE_1) che contiene un NEG.

L'output è simile al seguente:

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"80":"k8s1-cca197ad-default-neg-demo-app-80-4db81e02"},"zones":["ZONE_1", "ZONE_2"]}'
  labels:
    run: neg-demo-app
  name: neg-demo-app
  namespace: default
  selfLink: /api/v1/namespaces/default/services/neg-demo-app
  ...
spec:
  clusterIP: 10.0.14.252
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376
  selector:
    run: neg-demo-app
  sessionAffinity: None
status:
  loadBalancer: {}

In questo esempio, l'annotazione mostra che la porta di servizio 80 è esposta ai NEG denominati k8s1-cca197ad-default-neg-demo-app-80-4db81e02.

Convalida la creazione del NEG

Un NEG viene creato entro pochi minuti dalla creazione del servizio. Se esistono pod che corrispondono all'etichetta specificata nel manifest del servizio, al momento della creazione il NEG conterrà gli IP dei pod.

Esistono due modi per verificare che il NEG sia stato creato e configurato correttamente. In GKE 1.18.6-gke.6400 e versioni successive, una risorsa personalizzata ServiceNetworkEndpointGroup memorizza le informazioni sullo stato dei NEG creati dal controller del servizio. Nelle versioni precedenti, devi esaminare direttamente le NEGs.

La risorsa ServiceNetworkEndpointGroup

Elenca i NEG in un cluster recuperando tutte le risorse ServiceNetworkEndpointGroup:

kubectl get svcneg

Osserva lo stato di un NEG controllando lo stato della risorsa ServiceNetworkEndpointGroup:

kubectl get svcneg NEG_NAME -o yaml

Sostituisci NEG_NAME con il nome del NEG individuale che vuoi esaminare.

L'output di questo comando include una sezione di stato che potrebbe contenere messaggi di errore. Alcuni errori vengono segnalati come evento di servizio. Puoi trovare ulteriori dettagli eseguendo una query sull'oggetto Service:

kubectl describe service SERVICE_NAME

Sostituisci SERVICE_NAME con il nome del servizio pertinente.

Per verificare che il controller NEG stia sincronizzando correttamente il NEG, controlla il campo stato della risorsa ServiceNetworkEndpointGroup per una condizione con type:Synced. L'ora della sincronizzazione più recente è nel campo status.lastSyncTime.

Le risorse ServiceNetworkEndpointGroup esistono solo in GKE versione 1.18 e successive.

Esaminare direttamente i NEG

Verifica che il NEG esista elencando i NEG nel tuo progetto Trusted Cloud e controllando se esiste un NEG che corrisponda al servizio che hai creato. Il nome del gruppo di annunci ha il seguente formato:

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

Utilizza il seguente comando per elencare i NEG:

gcloud compute network-endpoint-groups list

L'output è simile al seguente:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  ZONE_NAME      GCE_VM_IP_PORT  3

Questo output mostra che SIZE del NEG è 3, il che significa che ha tre endpoint che corrispondono ai tre pod nel deployment.

Identifica i singoli endpoint con il seguente comando:

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME

Sostituisci NEG_NAME con il nome del NEG per cui vuoi visualizzare gli endpoint individuali.

L'output mostra tre endpoint, ognuno dei quali ha l'indirizzo IP e la porta di un pod:

INSTANCE                                           IP_ADDRESS  PORT
gke-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.43  9376
gke-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.44  9376
gke-cluster-3-default-pool-4cc71a15-w9nk  10.12.2.26  9376

Collegamento di un bilanciatore del carico delle applicazioni esterno a NEG autonomi

Puoi utilizzare i NEG come backend per un bilanciatore del carico delle applicazioni esterno utilizzando l'API Compute Engine.

1. Crea una regola firewall. I bilanciatori del carico devono accedere agli endpoint del cluster per eseguire i controlli di integrità. Questo comando crea una regola firewall per consentire l'accesso:

   gcloud compute firewall-rules create fw-allow-health-check-and-proxy \
      --network=NETWORK_NAME \
      --action=allow \
      --direction=ingress \
      --target-tags=GKE_NODE_NETWORK_TAGS \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --rules=tcp:9376
   

   Sostituisci quanto segue:

   • NETWORK_NAME: la rete in cui viene eseguito il cluster.
   • GKE_NODE_NETWORK_TAGS: i tag di networking sui nodi GKE.

   Se non hai creato tag di rete personalizzati per i tuoi nodi, GKE genera automaticamente i tag. Puoi cercare questi tag generati eseguendo il seguente comando:

   gcloud compute instances describe INSTANCE_NAME
   

   Sostituisci INSTANCE_NAME con il nome dell'istanza VM di Compute Engine host che esegue il nodo GKE. Ad esempio, l'output nella sezione precedente mostra i nomi delle istanze nella colonna INSTANCE per i nodi GKE.

   Per i cluster Standard, puoi anche eseguire gcloud compute instances list per elencare tutte le istanze nel tuo progetto.

2. Crea un indirizzo IP virtuale globale per il bilanciatore del carico:

   gcloud compute addresses create hostname-server-vip \
       --ip-version=IPV4 \
       --global
   

3. Creare un controllo di integrità. Viene utilizzato dal bilanciatore del carico per rilevare l'attività dei singoli endpoint all'interno del NEG.

   gcloud compute health-checks create http http-basic-check \
       --use-serving-port
   

4. Crea un servizio di backend che specifica che si tratta di un bilanciatore del carico delle applicazioni esterno globale:

   gcloud compute backend-services create my-bes \
       --protocol HTTP \
       --health-checks http-basic-check \
       --global
   

5. Crea una mappa URL e un proxy di destinazione per il bilanciatore del carico. Questo esempio è molto semplice perché l'app serve_hostname utilizzata per questa guida ha un singolo endpoint e non include URL.

   gcloud compute url-maps create web-map \
       --default-service my-bes
   

   gcloud compute target-http-proxies create http-lb-proxy \
       --url-map web-map
   

6. Crea una regola di forwarding. Questo crea il bilanciatore del carico.

   gcloud compute forwarding-rules create http-forwarding-rule \
       --address=HOSTNAME_SERVER_VIP \
       --global \
       --target-http-proxy=http-lb-proxy \
       --ports=80
   

   Sostituisci HOSTNAME_SERVER_VIP con l'indirizzo IP da utilizzare per il bilanciatore del carico. Se ometti --address, GKE assegna automaticamente un indirizzo IP temporaneo.

   Puoi anche prenotare un nuovo indirizzo IP esterno statico.

Checkpoint

Queste sono le risorse che hai creato finora:

• Un indirizzo IP virtuale esterno
• Le regole di forwarding
• Le regole firewall
• Il proxy HTTP di destinazione
• La mappa URL del controllo di integrità Compute Engine
• Il servizio di backend
• Il controllo di integrità Compute Engine

La relazione tra queste risorse è mostrata nel seguente diagramma:

Queste risorse insieme costituiscono un bilanciatore del carico. Nel passaggio successivo aggiungerai i backend al bilanciatore del carico.

Uno dei vantaggi dei NEG autonomi mostrati qui è che i cicli di vita del bilanciatore del carico e del backend possono essere completamente indipendenti. Il bilanciatore del carico può continuare a essere eseguito dopo l'eliminazione dell'applicazione, dei relativi servizi o del cluster GKE. Puoi aggiungere e rimuovere nuovi NEG o più NEG dal bilanciamento del carico senza modificare nessuno degli oggetti del bilanciamento del carico frontend.

Aggiungi backend al bilanciatore del carico

Utilizza gcloud compute backend-services add-backend per connettere il NEG al bilanciatore del carico aggiungendolo come backend del servizio di backend my-bes:

gcloud compute backend-services add-backend my-bes \
    --global \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    --balancing-mode RATE --max-rate-per-endpoint 5

Sostituisci quanto segue:

• NEG_NAME: il nome del gruppo di endpoint di rete. Il nome è il nome che hai specificato durante la creazione del NEG o un nome generato automaticamente. Se non hai specificato un nome per il NEG, consulta le seguenti istruzioni per trovare il nome generato automaticamente.
• NEG_ZONE: la zona in cui si trova il gruppo di endpoint di rete. Per trovare questo valore, segui le istruzioni riportate di seguito.

Utilizza questo comando per ottenere il nome e la posizione del NEG:

gcloud compute network-endpoint-groups list

L'output è simile al seguente:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  ZONE_NAME      GCE_VM_IP_PORT  3

In questo output di esempio, il nome del NEG è k8s1-70aa83a6-default-my-service-80-c9710a6f.

È possibile aggiungere più NEG allo stesso servizio di backend. I servizi di backend globali come my-bes possono avere backend NEG in regioni diverse, mentre i servizi di backend regionali devono avere backend in una singola regione.

Verifica che il bilanciatore del carico funzioni

Esistono due modi per verificare che il bilanciatore del carico che hai configurato funzioni:

• Verifica che il controllo di integrità sia configurato correttamente e che lo stato sia Integro.
• Accedi all'applicazione e verifica la risposta.

Verifica dei controlli di integrità

Verifica che il servizio di backend sia associato al controllo di integrità e ai gruppi di endpoint di rete e che i singoli endpoint siano integri.

Utilizza questo comando per verificare che il servizio di backend sia associato al controllo di integrità e al gruppo di endpoint di rete:

gcloud compute backend-services describe my-bes --global

L'output è simile al seguente:

backends:
- balancingMode: RATE
  capacityScaler: 1.0
  group: ... /networkEndpointGroups/k8s1-70aa83a6-default-my-service-80-c9710a6f
...
healthChecks:
- ... /healthChecks/http-basic-check
...
name: my-bes
...

Dopodiché, controlla l'integrità dei singoli endpoint:

gcloud compute backend-services get-health my-bes --global

La sezione status: dell'output è simile alla seguente:

status:
  healthStatus:
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-w9nk
    ipAddress: 10.12.2.26
    port: 50000

Accedere all'applicazione

Accedi all'applicazione tramite l'indirizzo IP del bilanciatore del carico per verificare che tutto funzioni.

Per prima cosa, recupera l'indirizzo IP virtuale del bilanciatore del carico:

gcloud compute addresses describe hostname-server-vip --global | grep "address:"

L'output includerà un indirizzo IP. Dopodiché, invia una richiesta a questo indirizzo IP (34.98.102.37 in questo esempio):

curl 34.98.102.37

La risposta dell'app serve_hostname deve essere neg-demo-app.

Collegamento di un bilanciatore del carico delle applicazioni interno a NEG autonomi

Puoi utilizzare i NEG per configurare un bilanciatore del carico delle applicazioni interno per i servizi in esecuzione in pod GKE autonomi.

Configurazione della subnet solo proxy

La subnet solo proxy è per tutti i bilanciatori del carico delle applicazioni interni regionali nella regione del bilanciatore del carico.

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=COMPUTE_REGION \
    --network=lb-network \
    --range=10.129.0.0/23

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "region": "projects/PROJECT_ID/regions/COMPUTE_REGION",
  "purpose": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

Configurazione delle regole del firewall

Questo esempio utilizza le seguenti regole firewall:

• fw-allow-ssh: una regola in entrata, applicabile alle istanze con bilanciamento del carico, che consente la connettività SSH in entrata sulla porta TCP 22 da qualsiasi indirizzo. Puoi scegliere un intervallo IP di origine più restrittivo per questa regola. Ad esempio, puoi specificare solo gli intervalli IP del sistema da cui avvii le sessioni SSH. Questo esempio utilizza il tag di destinazione allow-ssh per identificare le VM a cui si applica la regola firewall.

• fw-allow-health-check: una regola di ingresso, applicabile alle istanze con bilanciamento del carico, che consente tutto il traffico TCP dai sistemi di controllo di integrità Trusted Cloud(in 130.211.0.0/22 e 35.191.0.0/16). Questo esempio utilizza il tag di destinazione load-balanced-backend per identificare le istanze a cui deve essere applicata.

• fw-allow-proxies: una regola in entrata, applicabile alle istanze con bilanciamento del carico, che consente il traffico TCP sulla porta 9376 dai proxy gestiti del bilanciatore del carico HTTP(S) interno. Questo esempio utilizza il tag di destinazione load-balanced-backend per identificare le istanze a cui deve essere applicato.

Senza queste regole firewall, la regola default-deny per il traffico in entrata blocca il traffico in ingresso verso le istanze di backend.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-ssh",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-proxies",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/23"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "9376"
      ]
    }
  ],
  "direction": "INGRESS"
}

Configurazione del bilanciatore del carico

Per l'indirizzo IP della regola di forwarding, utilizza una subnet di backend. Se provi a utilizzare la subnet solo proxy, la creazione della regola di forwarding non va a buon fine.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks

{
   "name": "l7-ilb-gke-basic-check",
   "type": "HTTP",
   "httpHealthCheck": {
     "portSpecification": "USE_SERVING_PORT"
   }
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices

{
  "name": "l7-ilb-gke-backend-service",
  "backends": [
    {
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/networkEndpointGroups/NEG_NAME",
      "balancingMode": "RATE",
      "maxRatePerEndpoint": 5
    }
  ],
  "healthChecks": [
    "projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks/l7-ilb-gke-basic-check"
  ],
  "loadBalancingScheme": "INTERNAL_MANAGED"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/urlMaps

{
  "name": "l7-ilb-gke-map",
  "defaultService": "projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices/l7-ilb-gke-backend-service"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxy

{
  "name": "l7-ilb-gke-proxy",
  "urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-gke-map",
  "region": "COMPUTE_REGION"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/forwardingRules

{
  "name": "l7-ilb-gke-forwarding-rule",
  "IPAddress": "10.1.2.199",
  "IPProtocol": "TCP",
  "portRange": "80-80",
  "target": "projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxies/l7-ilb-gke-proxy",
  "loadBalancingScheme": "INTERNAL_MANAGED",
  "subnetwork": "projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks/backend-subnet",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "networkTier": "PREMIUM",
}

Test

Crea un'istanza VM nella zona per testare la connettività:

gcloud compute instances create l7-ilb-client \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --zone=COMPUTE_ZONE \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=l7-ilb-client,allow-ssh

Accedi all'istanza client per verificare che i servizi HTTP(S) sui backend siano raggiungibili utilizzando l'indirizzo IP della regola di forwarding del bilanciatore del carico delle applicazioni interno e che il traffico venga bilanciato tra gli endpoint nel NEG.

Connettiti a ogni istanza client tramite SSH:

gcloud compute ssh l7-ilb-client \
    --zone=COMPUTE_ZONE-b

Verifica che l'IP stia gestendo il proprio nome host:

curl 10.1.2.199

Per il test HTTPS, esegui questo comando:

curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443

Il flag -k fa sì che curl salti la convalida del certificato.

Esegui 100 richieste e verifica che siano bilanciate.

Per HTTP:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl --silent 10.1.2.199)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Per HTTPS:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Collega un bilanciatore del carico di rete proxy esterno a NEG autonomi

Puoi utilizzare i NEG autonomi per bilanciare il carico direttamente sui container con il bilanciatore del carico di rete con proxy esterno, che non è supportato in modo nativo da Kubernetes o GKE. I bilanciatori del carico di rete proxy sono destinati solo al traffico TCP, con o senza SSL. Per il traffico HTTP(S), ti consigliamo di utilizzare un bilanciatore del carico delle applicazioni.

1. Crea una regola firewall per consentire i controlli di integrità.

   I bilanciatori del carico devono accedere agli endpoint del cluster per eseguire i controlli di integrità. Il comando seguente crea una regola firewall per consentire l'accesso:

   gcloud compute firewall-rules create allow-tcp-lb-and-health \
      --network=NETWORK_NAME \
      --target-tags=GKE_NODE_NETWORK_TAGS \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --allow tcp:9376
   

   Sostituisci quanto segue:

   • NETWORK_NAME: la rete in cui viene eseguito il cluster.
   • GKE_NODE_NETWORK_TAGS: i tag di networking sui nodi GKE.

   Se non hai creato tag di rete personalizzati per i tuoi nodi, GKE genera automaticamente i tag per te. Puoi cercare questi tag generati eseguendo il seguente comando:

   gcloud compute instances describe INSTANCE_NAME
   

   Sostituisci INSTANCE_NAME con il nome dell'istanza VM di Compute Engine host che esegue il nodo GKE. Ad esempio, l'output nella sezione Ispeziona direttamente i NEG mostra i nomi delle istanze nella colonna INSTANCE per i nodi GKE.

   Per i cluster Standard, puoi anche eseguire gcloud compute instances list per elencare tutte le istanze nel tuo progetto.

   Per i cluster Autopilot, scegli come target il account di servizio del cluster anziché i tag di rete.

   Sostituisci il flag --target-tags=GKE_NODE_NETWORK_TAGS con --target-service-accounts=SERVICE_ACCOUNT_EMAIL. Ti consigliamo di utilizzare un account di servizio personalizzato con privilegi minimi per il cluster.

2. Crea un indirizzo IP virtuale globale per il bilanciatore del carico:

   gcloud compute addresses create tcp-lb-static-ipv4 \
      --ip-version=IPV4 \
      --global
   

3. Definisci un controllo di integrità per gli endpoint di backend.

   Il bilanciatore del carico utilizza i controlli di integrità per rilevare l'attività dei singoli endpoint all'interno del NEG.

   gcloud compute health-checks create tcp my-tcp-health-check \
      --use-serving-port
   

4. Crea un servizio di backend con affinità sessione.

   Questo servizio di backend specifica che si tratta di un bilanciatore del carico di rete proxy esterno con affinità sessione CLIENT_IP:

   gcloud compute backend-services create my-tcp-lb \
      --load-balancing-scheme EXTERNAL_MANAGED \
      --global-health-checks \
      --global \
      --protocol TCP \
      --health-checks my-tcp-health-check \
      --timeout 5m \
      --session-affinity=CLIENT_IP
   

5. Crea un proxy TCP di destinazione per il bilanciatore del carico.

   Se vuoi attivare l'intestazione proxy, impostala su PROXY_V1 anziché su NONE.

   gcloud beta compute target-tcp-proxies create my-tcp-lb-target-proxy \
       --backend-service my-tcp-lb \
       --proxy-header NONE
   

6. Crea una regola di forwarding per instradare il traffico.

   Questa regola di forwarding crea il bilanciatore del carico.

    gcloud compute forwarding-rules create my-tcp-lb-ipv4-forwarding-rule \
       --load-balancing-scheme EXTERNAL_MANAGED \
       --global \
       --target-tcp-proxy my-tcp-lb-target-proxy \
       --address tcp-lb-static-ipv4 \
       --ports 80
   

Verifica la creazione delle risorse del bilanciatore del carico

Hai creato le seguenti risorse:

• Un indirizzo IP virtuale esterno
• La regola di forwarding
• La regola firewall
• Il proxy di destinazione
• Il servizio di backend
• Il controllo di integrità Compute Engine

L'indirizzo IP virtuale esterno è connesso alla regola di forwarding, che indirizza il traffico consentito dalla regola firewall al proxy di destinazione. Il proxy di destinazione comunica quindi con il servizio di backend, che viene controllato periodicamente dal controllo di integrità. La relazione tra queste risorse è mostrata nel seguente diagramma:

Queste risorse insieme costituiscono un bilanciatore del carico. Nel passaggio successivo aggiungerai i backend al bilanciatore del carico.

Uno dei vantaggi dei NEG autonomi mostrati qui è che i cicli di vita del bilanciatore del carico e del backend possono essere completamente indipendenti. Il bilanciatore del carico può continuare a essere eseguito dopo l'eliminazione dell'applicazione, dei relativi servizi o del cluster GKE. Puoi aggiungere e rimuovere nuovi NEG o più NEG dal bilanciamento del carico senza modificare nessuno degli oggetti del bilanciamento del carico frontend.

Aggiungi NEG standalone come backend al bilanciatore del carico

Utilizza gcloud compute backend-services add-backend per collegare il NEG al bilanciatore del carico aggiungendolo come backend del servizio di backend my-tcp-lb:

gcloud compute backend-services add-backend my-tcp-lb \
    --global \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    --balancing-mode CONNECTION \
    --max-connections 100

Sostituisci quanto segue:

• NEG_NAME: il nome del gruppo di endpoint di rete. Il nome è il nome che hai specificato durante la creazione del NEG o un nome generato automaticamente. Se non hai specificato un nome per il NEG, consulta le seguenti istruzioni per trovare il nome generato automaticamente.
• NEG_ZONE: la zona in cui si trova il gruppo di endpoint di rete. Per trovare questo valore, segui le istruzioni riportate di seguito.

Per ottenere il nome e la posizione dei NEG, utilizza questo comando:

gcloud compute network-endpoint-groups list

L'output è simile al seguente:

NAME: k8s1-65a95e90-default-neg-demo-svc-80-663a85e4
LOCATION: us-central1-a
ENDPOINT_TYPE: GCE_VM_IP_PORT
SIZE: 3

In questo output di esempio, il nome del NEG è kk8s1-65a95e90-default-neg-demo-svc-80-663a85e4 e la zona è us-central1-a.

È possibile aggiungere più NEG allo stesso servizio di backend. I servizi di backend globali come my-tcp-lb possono avere backend NEG in regioni diverse, mentre i servizi di backend regionali devono avere backend in una singola regione.

Verifica la configurazione e la connettività del bilanciatore del carico

Esistono due modi per verificare che il bilanciatore del carico che hai configurato funzioni:

• Verifica che il controllo di integrità sia configurato correttamente e che lo stato sia Integro.
• Accedi all'applicazione e verifica la risposta.

Verifica dei controlli di integrità

Verifica che il servizio di backend sia associato al controllo di integrità e ai gruppi di endpoint di rete e che i singoli endpoint siano integri.

Per verificare che il servizio di backend sia associato al controllo di integrità e al gruppo di endpoint di rete, utilizza questo comando:

gcloud compute backend-services describe my-tcp-lb --global

L'output è simile al seguente:

backends:
- balancingMode: CONNECTION
  group: ... /networkEndpointGroups/k8s1-65a95e90-default-neg-demo-svc-80-663a85e4
  maxConnections: 100
...
healthChecks:
- ... /healthChecks/my-tcp-health-check
...
name: my-tcp-lb
...

Dopodiché, controlla l'integrità dei singoli endpoint:

gcloud compute backend-services get-health my-tcp-lb --global

La sezione status: dell'output è simile alla seguente:

status:
  healthStatus:
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-w9nk
    ipAddress: 10.12.2.26
    port: 50000

Verificare la connettività dell'applicazione

Per verificare che il bilanciatore del carico funzioni correttamente, accedi all'applicazione tramite l'indirizzo IP esterno del bilanciatore del carico.

1. Recupera l'indirizzo IP esterno del bilanciatore del carico:

   Per recuperare l'indirizzo IP esterno che hai prenotato per il bilanciatore del carico, utilizza questo comando:

   gcloud compute addresses describe tcp-lb-static-ipv4 --global | grep "address:"
   

   Questo comando restituisce l'indirizzo IP.

2. Invia una richiesta all'indirizzo IP:

   Utilizza il comando curl per inviare una richiesta all'indirizzo IP esterno.

   curl EXTERNAL_IP_ADDRESS
   

   Sostituisci EXTERNAL_IP_ADDRESS con l'indirizzo IP che hai ottenuto nel passaggio precedente:

   La risposta dell'applicazione serve_hostname deve iniziare con neg-demo-app.

Implementazione di servizi eterogenei (VM e container)

I bilanciatori del carico possono essere frontend per carichi di lavoro Kubernetes e non Kubernetes misti. Potrebbe far parte di una migrazione dalle VM ai container o di un'architettura permanente che trae vantaggio da un bilanciatore del carico condiviso. Ciò può essere ottenuto creando bilanciatori del carico che hanno come target diversi tipi di backend, inclusi i NEG autonomi.

VM e container nello stesso servizio di backend

Questo esempio mostra come creare un NEG che punta a una VM esistente che esegue un carico di lavoro e come aggiungere questo NEG come un altro backend di un backendService esistente. In questo modo, un singolo bilanciatore del carico esegue il bilanciamento tra le VM e i container GKE.

Questi esempi estendono l'esempio precedente che utilizza un bilanciatore del carico HTTP esterno.

Poiché tutti gli endpoint sono raggruppati in base allo stesso backendService, gli endpoint VM e container sono considerati lo stesso servizio. Ciò significa che la corrispondenza di host o percorso tratterà tutti i backend in modo identico in base alle regole della mappa URL.

Quando utilizzi un NEG come backend per un servizio di backend, anche tutti gli altri backend di questo servizio di backend devono essere NEG. Non puoi utilizzare gruppi di istanze e NEG come backend nello stesso servizio di backend. Inoltre, i container e le VM non possono esistere come endpoint all'interno dello stesso NEG, pertanto devono sempre essere configurati con NEG separati.

1. Esegui il deployment di una VM in Compute Engine con questo comando:

   gcloud compute instances create vm1 \
       --zone=COMPUTE_ZONE \
       --network=NETWORK \
       --subnet=SUBNET \
       --image-project=cos-cloud \
       --image-family=cos-stable --tags=vm-neg-tag
   

   Sostituisci quanto segue:

   • COMPUTE_ZONE: il nome della zona.
   • NETWORK: il nome della rete.
   • SUBNET: il nome della subnet associata alla rete.

2. Esegui il deployment di un'applicazione sulla VM:

   gcloud compute ssh vm1 \
       --zone=COMPUTE_ZONE \
       --command="docker run -d --rm --network=host registry.k8s.io/serve_hostname:v1.4 && sudo iptables -P INPUT ACCEPT"
   

   Questo comando esegue il deployment sulla VM della stessa applicazione di esempio utilizzata nell'esempio precedente. Per semplicità, l'applicazione viene eseguita come container Docker, ma non è essenziale. Il comando iptables è necessario per consentire l'accesso del firewall al container in esecuzione.

3. Verifica che l'applicazione sia in esecuzione sulla porta 9376 e che segnali che è in esecuzione su vm1:

   gcloud compute ssh vm1 \
       --zone=COMPUTE_ZONE \
       --command="curl -s localhost:9376"
   

   Il server deve rispondere con vm1.

4. Crea un NEG da utilizzare con l'endpoint VM. I container e le VM possono essere entrambi endpoint NEG, ma un singolo NEG non può avere endpoint VM e container.

   gcloud compute network-endpoint-groups create vm-neg \
       --subnet=SUBNET \
       --zone=COMPUTE_ZONE
   

5. Collega l'endpoint VM al NEG:

   gcloud compute network-endpoint-groups update vm-neg \
       --zone=COMPUTE_ZONE \
       --add-endpoint="instance=vm1,ip=VM_PRIMARY_IP,port=9376"
   

   Sostituisci VM_PRIMARY_IP con l'indirizzo IP principale della VM.

6. Verifica che il NEG abbia l'endpoint VM:

   gcloud compute network-endpoint-groups list-network-endpoints vm-neg \
       --zone COMPUTE_ZONE
   

7. Collega il NEG al servizio di backend utilizzando lo stesso comando che hai utilizzato per aggiungere un backend container:

   gcloud compute backend-services add-backend my-bes
       --global \
       --network-endpoint-group vm-neg \
       --network-endpoint-group-zone COMPUTE_ZONE \
       --balancing-mode RATE --max-rate-per-endpoint 10
   

8. Apri il firewall per consentire il controllo di integrità della VM:

   gcloud compute firewall-rules create fw-allow-health-check-to-vm1 \
       --network=NETWORK \
       --action=allow \
       --direction=ingress \
       --target-tags=vm-neg-tag \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --rules=tcp:9376
   

9. Verifica che il bilanciatore del carico inoltri il traffico sia al nuovo backend vm1 sia al backend container esistente inviando traffico di test:

   for i in `seq 1 100`; do curl ${VIP};echo; done
   

   Dovresti visualizzare le risposte sia dagli endpoint del container (neg-demo-app) sia della VM (vm1).

VM e container per diversi servizi di backend

Questo esempio mostra come creare un NEG che punta a una VM esistente che esegue un carico di lavoro e come aggiungere questo NEG come backend a un nuovo backendService. Ciò è utile nel caso in cui i container e le VM siano servizi diversi, ma debbano condividere lo stesso bilanciatore del carico L7, ad esempio se i servizi condividono lo stesso indirizzo IP o nome di dominio.

Questi esempi estendono l'esempio precedente che ha un backend VM nello stesso servizio di backend del backend container. Questo esempio riutilizza la VM.

Poiché gli endpoint del container e della VM sono raggruppati in servizi di backend separati, sono considerati servizi diversi. Ciò significa che la mappa URL corrisponderà ai backend e indirizzerà il traffico alla VM o al container in base al nome host.

Il seguente diagramma mostra come un singolo indirizzo IP virtuale corrisponda a due nomi host, che a loro volta corrispondono a un servizio di backend basato su container e a un servizio di backend basato su VM.

Il seguente diagramma mostra l'architettura descritta nella sezione precedente:

1. Crea un nuovo servizio di backend per la VM:

   gcloud compute backend-services create my-vm-bes \
      --protocol HTTP \
      --health-checks http-basic-check \
      --global
   

2. Collega il NEG per la VM, vm-neg, al servizio di backend:

   gcloud compute backend-services add-backend my-vm-bes \
       --global \
       --network-endpoint-group vm-neg \
       --network-endpoint-group-zone COMPUTE_ZONE \
       --balancing-mode RATE --max-rate-per-endpoint 10
   

3. Aggiungi una regola host alla mappa URL per indirizzare le richieste per l'host container.example.com al servizio di backend del container:

   gcloud compute url-maps add-path-matcher web-map \
       --path-matcher-name=container-path --default-service=my-bes \
       --new-hosts=container.example.com --global
   

4. Aggiungi un'altra regola host alla mappa URL per indirizzare le richieste per l'host vm.example.com al servizio di backend VM:

   gcloud compute url-maps add-path-matcher web-map \
       --path-matcher-name=vm-path --default-service=my-vm-bes \
       --new-hosts=vm.example.com --global
   

5. Verifica che il bilanciatore del carico invii il traffico al backend della VM in base al percorso richiesto:

   curl -H "HOST:vm.example.com" VIRTUAL_IP
   

   Sostituisci VIRTUAL_IP con l'indirizzo IP virtuale.

Limitazioni dei NEG autonomi

• Gli errori di convalida delle annotazioni vengono mostrati all'utente tramite gli eventi Kubernetes.
• I limiti dei NEG si applicano anche ai NEG autonomi.
• I NEG autonomi non funzionano con le reti legacy.
• I NEG autonomi possono essere utilizzati solo con servizi di rete compatibili, tra cui Cloud Service Mesh e i tipi di bilanciatori del carico compatibili.

Risoluzione dei problemi

Questa sezione fornisce i passaggi per la risoluzione dei problemi comuni che potresti riscontrare con le estensioni di Google indipendenti.

Nessun NEG autonomo configurato

Sintomo:non viene creato alcun NEG.

Potenziale risoluzione:

• Controlla gli eventi associati al servizio e cerca i messaggi di errore.
• Verifica che l'annotazione NEG autonoma sia un JSON ben formato e che le porte esposte corrispondano alle porte esistenti nella specifica del servizio.
• Verifica l'annotazione dello stato NEG e controlla se le porte di servizio previste hanno NEG corrispondenti.
• Verifica che i NEG siano stati creati nelle zone previste con il comando gcloud compute network-endpoint-groups list.
• Se utilizzi GKE 1.18 o versioni successive, controlla se esiste la risorsa svcneg per il servizio. In questo caso, controlla la condizione Initialized per informazioni sugli errori.
• Se utilizzi nomi NEG personalizzati, assicurati che ogni nome NEG sia univoco nella sua regione.

Il traffico non raggiunge gli endpoint

Sintomo: errori 502 o connessioni rifiutate.

Potenziale risoluzione:

• Una volta configurato il servizio, i nuovi endpoint diventano generalmente raggiungibili dopo essere stati collegati al NEG, a condizione che rispondano ai controlli di integrità.
• Se dopo questo periodo il traffico non riesce ancora a raggiungere gli endpoint, con conseguente codice di errore 502 per HTTP(S) o connessioni rifiutate per i bilanciatori del carico TCP/SSL, controlla quanto segue:
  • Verifica che le regole firewall consentano il traffico TCP in entrata verso i tuoi endpoint dai seguenti intervalli: 130.211.0.0/22 e 35.191.0.0/16.
  • Verifica che gli endpoint siano integri utilizzando Google Cloud CLI o chiamando l'API getHealth su backendService o l'API listEndpoints sul NEG con il parametro showHealth impostato su SHOW.

Implementazione bloccata

Sintomo: il rollout di un deployment aggiornato si blocca e il numero di repliche aggiornate non corrisponde al numero di repliche scelto.

Potenziale risoluzione:

I controlli di integrità del deployment non riescono. L'immagine container potrebbe essere danneggiata o il controllo di integrità potrebbe essere configurato in modo errato. La sostituzione in sequenza dei pod attende che il pod appena avviato superi il gate di idoneità del pod. Ciò si verifica solo se il pod risponde ai controlli di integrità del bilanciatore del carico. Se il pod non risponde o se il controllo di integrità è configurato in modo errato, le condizioni del gate di idoneità non possono essere soddisfatte e l'implementazione non può continuare.

• Se utilizzi kubectl 1.13 o versioni successive, puoi controllare lo stato dei readiness gate di un pod con il seguente comando:

  kubectl get my-Pod -o wide
  

  Controlla la colonna READINESS GATES.

  Questa colonna non esiste in kubectl 1.12 e versioni precedenti. Un pod contrassegnato come in stato READY potrebbe avere un gate di idoneità non riuscito. Per verificarlo, utilizza questo comando:

  kubectl get my-pod -o yaml
  

  Nell'output sono elencati i gate di preparazione e il relativo stato.

• Verifica che l'immagine container nella specifica del pod del deployment funzioni correttamente e sia in grado di rispondere ai controlli di integrità.

• Verifica che i controlli di integrità siano configurati correttamente.

Il NEG non viene sottoposto a garbage collection

Sintomo: esiste ancora un NEG che avrebbe dovuto essere eliminato.

Potenziale risoluzione:

• Il NEG non viene sottoposto a garbage collection se viene fatto riferimento a un servizio di backend. Per informazioni dettagliate, consulta la sezione Prevenzione della fuga di intent incorporati.
• Se utilizzi la versione 1.18 o successive, puoi verificare la presenza di eventi nella risorsa ServiceNetworkEndpointGroup utilizzando la procedura di negazione del servizio.
• Controlla se il NEG è ancora necessario per un servizio. Controlla la risorsa svcneg per il servizio corrispondente al NEG e verifica se esiste un'annotazione del servizio.

Il NEG non è sincronizzato con il servizio

Sintomo: gli endpoint previsti (IP pod) non esistono nel NEG, il NEG non è sincronizzato o l'errore Failed to sync NEG_NAME (will not retry): neg name NEG_NAME is already in use, found a custom named neg with an empty description

Potenziale risoluzione:

Se utilizzi GKE 1.18 o versioni successive, controlla la risorsa svcneg per informazioni:

• Controlla il valore di status.lastSyncTime per verificare se il NEG è stato sincronizzato di recente.
• Controlla la condizione Synced per verificare la presenza di errori nella sincronizzazione più recente.

Se utilizzi GKE 1.19.9 o versioni successive, verifica se esiste un NEG il cui nome e zona corrispondono al nome e alla zona del NEG che il controller NEG di GKE deve creare. Ad esempio, un NEG con il nome che il controller NEG deve utilizzare potrebbe essere stato creato utilizzando l'interfaccia a riga di comando gcloud o la console Trusted Cloud nella zona del cluster (o in una delle zone del cluster). In questo caso, devi eliminare il NEG esistente prima che il controller NEG possa sincronizzare i relativi endpoint. La creazione e l'appartenenza di NEG autonomi sono progettate per essere gestite dal controller NEG.

Passaggi successivi

• Panoramica dei gruppi di endpoint di rete a livello di zona
• Servizi di backend
• Creazione di controlli di integrità
• Utilizzo dei proxy di destinazione
• Utilizzo delle regole di inoltro