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

Autopilot Standard

---

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

Per informazioni sui vantaggi, sui requisiti e sulle limitazioni del bilanciamento del carico nativo del container, consulta Bilanciamento del carico nativo del container.

Panoramica

Un NEG rappresenta un gruppo di endpoint. GKE supporta NEG autonomi di tipoGCE_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 della 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 di indirizzi IP dell'alias del nodo per i pod, che proviene dall'intervallo di indirizzi IP secondario della subnet per i pod del cluster.

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

Il seguente diagramma descrive in che modo gli oggetti dell'API Kubernetes corrispondono agli oggetti Compute Engine.

Ingress con NEG

Quando le NEG vengono utilizzate con GKE Ingress, il controller Ingress semplifica la creazione di tutti gli aspetti del bilanciatore del carico. Sono incluse la creazione dell'indirizzo IP virtuale, delle regole di inoltro, del controllo di integrità, delle regole del 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 quelli gestiti da Ingress non sono adatti al tuo caso d'uso.

NEG standalone

Quando i NEG vengono di cui vengono eseguiti il provisioning con bilanciatori del carico diversi da Ingress, sono considerati NEG autonomi. Le NEG autonome vengono implementate e gestite tramite il controller NEG, ma le regole di inoltro, i controlli di integrità e gli altri oggetti di bilanciamento del carico vengono implementati manualmente.

I NEG autonomi non sono in conflitto con il bilanciamento del carico nativo del container attivato su Ingress.

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

Evitare la fuga di NEG

Con i gruppi di elenchi di negazioni autonomi, sei responsabile della gestione dei relativi cicli di vita e delle risorse che compongono il bilanciatore del carico. Potresti divulgare NEG in questi modi:

• Quando un servizio GKE viene eliminato, il NEG associato non verrà sottoposto a raccolta dei rifiuti se il NEG è ancora fatto riferimento da un servizio di backend. Dereferenziare il NEG dal servizio di backend per consentire l'eliminazione del NEG.
• Quando un cluster viene eliminato, i NEG autonomi non vengono eliminati.

Casi d'uso di NEG autonomi

I NEG autonomi hanno diversi utilizzi critici. I NEG autonomi 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 opinato per semplificarne l'utilizzo.

I casi d'uso per i gruppi di elenchi di negazioni autonomi includono:

Servizi eterogenei di container e VM

I NEG possono contenere sia gli indirizzi IP delle VM che quelli dei container. Ciò significa che un singolo indirizzo IP virtuale può puntare a un backend costituito da carichi di lavoro sia Kubernetes che non Kubernetes. Può essere utilizzato anche per eseguire la migrazione dei carichi di lavoro esistenti in 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 a backend composti sia da VM sia da contenitori 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 NEG autonomi.

Utilizzare Cloud Service Mesh con GKE

Puoi utilizzare Cloud Service Mesh con GKE. Cloud Service Mesh utilizza NEG autonomi per fornire il bilanciamento del carico nativo del container per il mesh di servizi gestiti.

Utilizzare i bilanciatori del carico di rete proxy esterni con GKE

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

Disponibilità dei pod

I cancelli di idoneità sono una funzionalità di estensione di Kubernetes che consente l'iniezione di feedback o indicatori aggiuntivi in PodStatus per consentire al pod di passare allo stato di idoneità. Il controller NEG gestisce un cancello di idoneità personalizzato per garantire che il percorso di rete completo dal bilanciatore del carico Compute Engine al pod sia funzionale. I cancelli di idoneità dei pod in GKE sono descritti nel bilanciamento del carico nativo del container.

L'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 supposizioni sui controlli di integrità di Compute Engine perché devono essere implementati e gestiti separatamente. I controlli di integrità di Compute Engine devono sempre essere configurati insieme al bilanciatore del carico per impedire l'invio di traffico ai backend non pronti a riceverlo. Se non è associato alcun stato del controllo di integrità al NEG (in genere perché non è configurato alcun controllo di integrità), il controller NEG imposterà il valore del cancello di idoneità del pod su True quando l'endpoint corrispondente è 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.

Nel cluster deve essere attivato il componente aggiuntivo HttpLoadBalancing. Nei cluster GKE il componente aggiuntivo HttpLoadBalancing è attivo 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à, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le posizioni predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

Utilizzo di NEG autonomi

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

Devi creare i seguenti oggetti:

• Un deployment{track-name="k8sLink" track-type="concept"} che crea e gestisce i pod.
• Un servizio che crea un NEG.
• Un bilanciatore del carico creato con l'API Compute Engine. Questo è diverso dall'utilizzo di NEG con Ingress, nel qual caso Ingress crea e configura un bilanciatore del carico per te. Con i NEG autonomi, è tua responsabilità associare il NEG e il 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 nativi VPC per impostazione predefinita, quindi puoi saltare a Eseguire il deployment di un carico di lavoro.

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

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

Creazione di un deployment

I manifest di esempio riportati di seguito 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 dell'applicazione, il nome del pod su cui è in esecuzione il server.

Ti consigliamo di utilizzare i carichi di lavoro che utilizzano il feedback relativo all'idoneità dei pod.

Utilizzare il feedback relativo all'idoneità 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
  

Utilizzare un ritardo hardcoded

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 sarà chiamato NEG_NAME. Se il campo name viene omesso, verrà generato automaticamente un nome univoco. Per informazioni dettagliate, consulta la sezione Nomi dei gruppi di esclusioni.
• 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 gruppo di esclusioni. 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.

Assegnare un nome ai NEG

Nelle versioni GKE 1.18.18-gke.1200 e successive, puoi specificare un nome personalizzato per i NEG oppure GKE può generare un nome automaticamente. Le versioni precedenti di GKE supportano solo i 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 bilanciatore del carico perché conosci in anticipo il nome e le zone dei NEG. I nomi NEG personalizzati devono soddisfare i seguenti requisiti:

• Deve essere univoco per la zona del cluster per i cluster a livello di zona o per la regione per i cluster a livello di regione.

• Non deve corrispondere al nome di un NEG esistente non creato dal controller NEG GKE.
• Non deve contenere trattini bassi.

Nota: in caso di conflitto di nomi, la creazione o la sincronizzazione del NEG non va a buon fine. Per la procedura di risoluzione dei problemi, consulta Il NEG non è sincronizzato con il servizio.

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 gruppo di esclusioni. Il nome del NEG deve essere univoco nella regione.

Utilizzo di un nome generato automaticamente

I nomi NEG generati automaticamente sono garantiti come 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

Mappatura delle porte a più NEG

Un servizio può ascoltare su più porte. Per definizione, i NEG hanno solo un singolo indirizzo IP e una singola 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 il seguente 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 nella mappatura network-endpoint-groups è una porta di servizio (ad esempio SERVICE_PORT_1) e il nome dei NEG gestiti corrispondenti (ad esempio NEG_NAME_1). L'elenco zones contiene ogni zona (ad esempio 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 nominati 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 sia configurato correttamente. In GKE 1.18.6-gke.6400 e versioni successive, una risorsa personalizzataServiceNetworkEndpointGroup memorizza le informazioni sullo stato dei NEG creati dal controller dei servizi. Nelle versioni precedenti, devi ispezionare direttamente i NEG.

La risorsa ServiceNetworkEndpointGroup

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

kubectl get svcneg

Controlla 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 singolo NEG che vuoi controllare.

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 si trova nel campo status.lastSyncTime.

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

Ispezione diretta dei NEG

Verifica che l'NEG esista elencando le NEG nel progetto Google Cloud e controllando se esiste una NEG corrispondente al servizio che hai creato. Il nome del NEG 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 il valore 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 gruppo di negozianti elettronici per cui vuoi visualizzare i singoli endpoint.

L'output mostra tre endpoint, ognuno con 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 su cui viene eseguito il cluster.
   • GKE_NODE_NETWORK_TAGS: i tag di rete 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 dell'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 del 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 la funzionalità 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 specifichi 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 unico endpoint e non presenta 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. È così che viene creato 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.

Check Point

Queste sono le risorse che hai creato finora:

• Un indirizzo IP virtuale esterno
• Le regole di forwarding
• Le regole del 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 è illustrata 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 gruppi di elementi non elaborati autonomi dimostrati qui è che i cicli di vita del bilanciatore del carico e del backend possono essere completamente indipendenti. Il bilanciatore del carico può continuare a funzionare dopo l'eliminazione dell'applicazione, dei relativi servizi o del cluster GKE. Puoi aggiungere e rimuovere nuovi NEG o più NEG dal bilanciatore del carico senza modificare nessuno degli oggetti bilanciatore del carico frontend.

Aggiungere 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-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 può essere il nome specificato durante la creazione del gruppo di esclusioni o un nome generato automaticamente. Se non hai specificato un nome per il gruppo di esclusioni, consulta le istruzioni riportate di seguito 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 esempio di output, 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.

Verificare il funzionamento del bilanciatore del carico

Nota: potrebbero essere necessari alcuni minuti per il provisioning e la stabilizzazione del bilanciatore del carico.

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

• Verifica che il controllo di integrità sia configurato correttamente e che indichi che il sistema è in stato di salute.
• Accedi all'applicazione e verifica la risposta.

Verificare i 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 operativi.

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

Successivamente, 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.

Nota: la programmazione completa del bilanciatore del carico richiede alcuni minuti.

Innanzitutto, ottieni l'indirizzo IP virtuale del bilanciatore del carico:

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

L'output includerà un indirizzo IP. Invia una richiesta all'indirizzo IP corrispondente (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 è destinada per tutti i bilanciatori del carico delle applicazioni interni regionali nella regione del bilanciatore del carico.

Importante: non tentare di assegnare indirizzi della subnet solo proxy ai backend o alla regola di forwarding del bilanciatore del carico. Assegna l'indirizzo IP della regola di forwarding e gli indirizzi IP istanza di backend da un intervallo (o intervalli) di subnet diverso dalla subnet solo proxy. Google Cloud si riserva l'intervallo di sottoreti per i proxy gestiti da Google Cloud.

Console

Se utilizzi la console Google Cloud, puoi attendere e creare la sottorete solo proxy in un secondo momento.

gcloud

Crea la subnet solo proxy con il comando gcloud compute networks subnets create.

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

Sostituisci COMPUTE_REGION con Compute Engine per la sottorete.

API

Crea la subnet solo proxy con il metodo subnetworks.insert.

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"
}

Sostituisci quanto segue:

• PROJECT_ID: il tuo ID progetto.
• COMPUTE_REGION: il Compute Engine per la sottorete.

Configurazione delle regole del firewall

Questo esempio utilizza le seguenti regole firewall:

• fw-allow-ssh: una regola in entrata, applicabile alle istanze sottoposte a 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 in entrata, applicabile alle istanze bilanciate in base al carico, che consente tutto il traffico TCP proveniente dai sistemi di controllo di integrità di Google Cloud (in 130.211.0.0/22 e 35.191.0.0/16). Questo esempio utilizza il tag target load-balanced-backend per identificare le istanze a cui deve essere applicata.

• fw-allow-proxies: una regola di ingresso, applicabile alle istanze bilanciate in base al carico, che consente il traffico TCP sulla porta 9376 dai proxy gestiti del bilanciatore del carico HTTP(S) interno. Questo esempio utilizza il tag target 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 entrata verso le istanze di backend.

Console

1. Vai alla pagina Criteri firewall nella console Google Cloud.

   Vai a Criteri Firewall

2. Fai clic su Crea regola firewall per creare la regola che consente le connessioni SSH in entrata:

   • Nome: fw-allow-ssh
   • Rete: lb-network
   • Direzione del traffico: in entrata
   • Azione in caso di corrispondenza: consenti
   • Target: Tag di destinazione specificati
   • Tag di destinazione: allow-ssh
   • Filtro di origine: IPv4 ranges
   • Intervalli IPv4 di origine: 0.0.0.0/0
   • Protocolli e porte:
     • Seleziona Protocolli e porte specificati.
     • Seleziona la casella di controllo tcp e specifica la porta 22.

3. Fai clic su Crea.

4. Fai di nuovo clic su Crea regola firewall per creare la regola per consentire i controlli di integrità di Google Cloud:

   • Nome: fw-allow-health-check
   • Rete: lb-network
   • Direzione del traffico: in entrata
   • Azione in caso di corrispondenza: consenti
   • Target: Tag di destinazione specificati
   • Tag di destinazione: load-balanced-backend
   • Filtro di origine: IPv4 ranges
   • Intervalli IPv4 di origine: 130.211.0.0/22 e 35.191.0.0/16
   • Protocolli e porte:
     • Seleziona Protocolli e porte specificati
     • Seleziona la casella di controllo tcp e specifica la porta 80. Come best practice, limita questa regola solo ai protocolli e alle porte che corrispondono a quelli utilizzati dal controllo di integrità. Se utilizzi tcp:80 per il protocollo e la porta, Google Cloud può contattare le tue VM utilizzando HTTP sulla porta 80, ma non può farlo utilizzando HTTPS sulla porta 443.

5. Fai clic su Crea.

6. Fai di nuovo clic su Crea regola firewall per creare la regola che consenta ai server proxy del bilanciatore del carico di collegare i backend:

   • Nome: fw-allow-proxies
   • Rete: lb-network
   • Direzione del traffico: in entrata
   • Azione in caso di corrispondenza: consenti
   • Target: Tag di destinazione specificati
   • Tag di destinazione: load-balanced-backend
   • Filtro di origine: IPv4 ranges
   • Intervalli IPv4 di origine: 10.129.0.0/23
   • Protocolli e porte:
     • Seleziona Protocolli e porte specificati.
     • Seleziona la casella di controllo tcp e specifica la porta 9376.

7. Fai clic su Crea.

gcloud

1. Crea la regola firewall fw-allow-ssh per consentire la connettività SSH alle VM con il tag di rete allow-ssh. Se ometti source-ranges, Google Cloud interpreta la regola come qualsiasi origine.

   gcloud compute firewall-rules create fw-allow-ssh \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-ssh \
       --rules=tcp:22
   

2. Crea la regola fw-allow-health-check per consentire i controlli di integrità di Google Cloud. Questo esempio consente tutto il traffico TCP proveniente dai probe del controllo di integrità. Tuttavia, puoi configurare un insieme più ristretto di porte in base alle tue esigenze.

   gcloud compute firewall-rules create fw-allow-health-check \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=load-balanced-backend \
       --rules=tcp
   

3. Crea la regola fw-allow-proxies per consentire ai proxy del bilanciatore del carico HTTP(S) interno di connettersi ai tuoi backend.

   gcloud compute firewall-rules create fw-allow-proxies \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --source-ranges=10.129.0.0/23 \
       --target-tags=load-balanced-backend \
       --rules=tcp:9376
   

API

Crea la regola firewall fw-allow-ssh inviando una richiesta POST al metodo firewalls.insert.

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"
}

Sostituisci PROJECT_ID con l'ID progetto.

Crea la regola firewall fw-allow-health-check inviando una richiesta POST al metodo firewalls.insert.

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"
}

Crea la regola firewall fw-allow-proxies per consentire il traffico TCP all'interno della subnet del proxy con il metodo firewalls.insert.

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"
}

Sostituisci PROJECT_ID con l'ID progetto.

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 regola di forwarding non va a buon fine.

Console

Seleziona un tipo di bilanciatore del carico

1. Vai alla pagina Crea un bilanciatore del carico nella console Google Cloud. Vai a Creare un bilanciatore del carico
2. In Bilanciamento del carico HTTP(S), fai clic su Avvia configurazione.
3. Seleziona Solo tra le mie VM. Questa impostazione indica che il bilanciatore del carico è interno.
4. Fai clic su Continua.

Prepara il bilanciatore del carico

1. In Nome del bilanciatore del carico, inserisci l7-ilb-gke-map.
2. Per Regione, seleziona la regione in cui hai creato la subnet.
3. In Rete, seleziona lb-network.

Riserva una subnet solo proxy

Nota: se hai già riservato una subnet solo per i proxy, come indicato, il pulsante Prendi una subnet non viene visualizzato, quindi salta questa sezione e continua con i passaggi descritti in Configurare il servizio di backend.

Riserva una subnet solo proxy:

1. Fai clic su Prenota una subnet.
2. In Nome, inserisci proxy-only-subnet.
3. Per l'intervallo di indirizzi IP, inserisci 10.129.0.0/23.
4. Fai clic su Aggiungi.

Configura il servizio di backend

1. Fai clic su Configurazione backend.
2. Dal menu Crea o seleziona servizi di backend, seleziona Crea un servizio di backend.
3. Imposta il nome del servizio di backend su l7-ilb-gke-backend-service.
4. In Tipo di backend, seleziona Gruppi di endpoint di rete.
5. Nella scheda Nuovo backend della sezione Backend:
   1. Imposta il gruppo di endpoint di rete sul gruppo di endpoint di rete creato da GKE. Per ottenere il nome del NEG, consulta Convalidare la creazione del NEG.
   2. Per RPS massimo, specifica una frequenza massima di 5 RPS per endpoint. Google Cloud supererà questo valore massimo, se necessario.
   3. Fai clic su Fine.
6. Nell'elenco a discesa Controllo di integrità, seleziona Crea un controllo di integrità e specifica i seguenti parametri:
   1. Nome: l7-ilb-gke-basic-check
   2. Protocollo: HTTP
   3. Specifiche della porta: Porta utilizzata
   4. Fai clic su Salva e continua.
7. Fai clic su Crea.

Configura la mappa URL

1. Fai clic su Regole di routing. Assicurati che l7-ilb-gke-backend-service sia l'unico servizio di backend per qualsiasi host e percorso senza corrispondenza.

Configura il frontend

Fai clic su Configurazione frontend ed esegui i seguenti passaggi:

Per HTTP:

1. Fai clic su Configurazione frontend.
2. Fai clic su Aggiungi IP e porta frontend.
3. Imposta il Nome su l7-ilb-gke-forwarding-rule.
4. Imposta Protocollo su HTTP.
5. Imposta Subnet su backend-subnet.
6. In IP interno, seleziona Prenota un indirizzo IP interno statico.
7. Nel riquadro visualizzato, fornisci i seguenti dettagli:
   1. Nome: l7-ilb-gke-ip
   2. Nella sezione Indirizzo IP statico, seleziona Scelta manuale.
   3. Nella sezione Indirizzo IP personalizzato, inserisci 10.1.2.199.
   4. Fai clic su Prenota.
8. Imposta Porta su 80.
9. Fai clic su Fine.

Per HTTPS:

Se utilizzi HTTPS tra il client e il bilanciatore del carico, hai bisogno di una o più risorse del certificato SSL per configurare il proxy. Per informazioni su come creare risorse dei certificati SSL, consulta Certificati SSL. I certificati gestiti da Google non sono supportati con i bilanciatori del carico HTTP(S) interni.

1. Fai clic su Configurazione frontend.
2. Fai clic su Aggiungi IP e porta frontend.
3. Nel campo Nome, inserisci l7-ilb-gke-forwarding-rule.
4. Nel campo Protocollo, seleziona HTTPS (includes HTTP/2).
5. Imposta Subnet su backend-subnet.
6. In IP interno, seleziona Prenota un indirizzo IP interno statico.
7. Nel riquadro visualizzato, fornisci i seguenti dettagli:
   1. Nome: l7-ilb-gke-ip
   2. Nella sezione Indirizzo IP statico, seleziona Scelta manuale.
   3. Nella sezione Indirizzo IP personalizzato, inserisci 10.1.2.199.
   4. Fai clic su Prenota.
8. Assicurati che Porta sia impostata su 443 per consentire il traffico HTTPS.
9. Fai clic sull'elenco a discesa Certificato.
   1. Se hai già una risorsa del certificato SSL con gestione indipendente che vuoi utilizzare come certificato SSL principale, selezionala dal menu a discesa.
   2. In caso contrario, seleziona Crea un nuovo certificato.
      1. Inserisci un Nome di l7-ilb-cert.
      2. Carica i file in formato PEM nei campi appropriati:
         • Certificato di chiave pubblica
         • Catena di certificati
         • Chiave privata
      3. Fai clic su Crea.
10. Per aggiungere risorse del certificato oltre alla risorsa del certificato SSL principale:
    1. Fai clic su Aggiungi certificato.
    2. Seleziona un certificato dall'elenco Certificati o fai clic su Crea un nuovo certificato e segui le istruzioni.
11. Fai clic su Fine.

Completare la configurazione

Fai clic su Crea.

gcloud

1. Definisci il controllo di integrità HTTP con il comando gcloud compute health-checks create http.

   gcloud compute health-checks create http l7-ilb-gke-basic-check \
       --region=COMPUTE_REGION \
       --use-serving-port
   

2. Definisci il servizio di backend con il comando gcloud compute backend-services create.

   gcloud compute backend-services create l7-ilb-gke-backend-service \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --protocol=HTTP \
       --health-checks=l7-ilb-gke-basic-check \
       --health-checks-region=COMPUTE_REGION \
       --region=COMPUTE_REGION
   

3. Imposta la variabile DEPLOYMENT_NAME:

   export DEPLOYMENT_NAME=NEG_NAME
   

   Sostituisci NEG_NAME con il nome del gruppo di esclusioni.

4. Aggiungi i backend NEG al servizio di backend con il comando gcloud compute backend-services add-backend.

   gcloud compute backend-services add-backend l7-ilb-gke-backend-service \
       --network-endpoint-group=$DEPLOYMENT_NAME \
       --network-endpoint-group-zone=COMPUTE_ZONE-b \
       --region=COMPUTE_REGION \
       --balancing-mode=RATE \
       --max-rate-per-endpoint=5
   

5. Crea la mappa URL con il comando gcloud compute url-maps create.

   gcloud compute url-maps create l7-ilb-gke-map \
       --default-service=l7-ilb-gke-backend-service \
       --region=COMPUTE_REGION
   

6. Crea il proxy di destinazione.

   Per HTTP:

   Utilizza il comando gcloud compute target-http-proxies create.

   gcloud compute target-http-proxies create l7-ilb-gke-proxy \
       --url-map=l7-ilb-gke-map \
       --url-map-region=COMPUTE_REGION \
       --region=COMPUTE_REGION
   

   Per HTTPS:

   Per informazioni su come creare risorse del certificato SSL, consulta Certificati SSL. I certificati gestiti da Google non sono supportati con i bilanciatori del carico HTTP(S) interni.

   Assegna i percorsi file ai nomi delle variabili.

   export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
   

   export LB_PRIVATE_KEY=PATH_TO_PEM_FORMATTED_FILE
   

   Crea un certificato SSL a livello di regione utilizzando il comando gcloud compute ssl-certificates create.

   gcloud compute ssl-certificates create

   gcloud compute ssl-certificates create l7-ilb-cert \
       --certificate=$LB_CERT \
       --private-key=$LB_PRIVATE_KEY \
       --region=COMPUTE_REGION
   

   Utilizza il certificato SSL regionale per creare un proxy di destinazione con il comando gcloud compute target-https-proxies create.

   gcloud compute target-https-proxies create l7-ilb-gke-proxy \
       --url-map=l7-ilb-gke-map \
       --region=COMPUTE_REGION \
       --ssl-certificates=l7-ilb-cert
   

7. Crea la regola di forwarding.

   Per le reti personalizzate, devi fare riferimento alla subnet nella regola di inoltro. Tieni presente che si tratta della subnet della VM, non della subnet del proxy.

   Per HTTP:

   Utilizza il comando gcloud compute forwarding-rules create con i flag corretti.

   gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=backend-subnet \
       --address=10.1.2.199 \
       --ports=80 \
       --region=COMPUTE_REGION \
       --target-http-proxy=l7-ilb-gke-proxy \
       --target-http-proxy-region=COMPUTE_REGION
   

   Per HTTPS:

   Utilizza il comando gcloud compute forwarding-rules create con i flag corretti.

   gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=backend-subnet \
       --address=10.1.2.199 \
       --ports=443 \
       --region=COMPUTE_REGION \
       --target-https-proxy=l7-ilb-gke-proxy \
       --target-https-proxy-region=COMPUTE_REGION
   

API

Crea il controllo di integrità inviando una richiesta POST al metodo regionHealthChecks.insert.

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"
   }
}

Sostituisci PROJECT_ID con l'ID progetto.

Crea il servizio di backend regionale inviando una richiesta POST al metodo regionBackendServices.insert.

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"
}

Sostituisci quanto segue:

• PROJECT_ID: l'ID progetto.
• NEG_NAME: il nome del NEG.

Crea la mappa URL inviando una richiesta POST al metodo regionUrlMaps.insert.

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"
}

Sostituisci PROJECT_ID con l'ID progetto.

Crea il proxy HTTP di destinazione inviando una richiesta POST al metodo regionTargetHttpProxies.insert.

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"
}

Sostituisci PROJECT_ID con l'ID progetto.

Crea la regola di forwarding inviando una richiesta POST al metodo forwardingRules.insert.

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",
}

Sostituisci PROJECT_ID con l'ID progetto.

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 accessibili 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 pubblicando il proprio nome host:

curl 10.1.2.199

Per i test HTTPS, esegui il seguente 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 in base al carico.

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
}

Implementazione di servizi eterogenei (VM e container)

I bilanciatori del carico possono essere frontend per carichi di lavoro misti Kubernetes e non Kubernetes. Potrebbe essere parte di una migrazione dalle VM ai container o di un'architettura permanente che beneficia di un bilanciatore del carico condiviso. Questo risultato 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 rimandi 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.

Questo esempio estende l'esempio precedente che utilizza un bilanciatore del carico HTTP esterno.

Poiché tutti gli endpoint sono raggruppati per lo stesso backendService, gli endpoint VM e contenuto sono considerati lo stesso servizio. Ciò significa che la corrispondenza dell'host o del 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, tutti gli altri backend di quel 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 essere presenti come endpoint all'interno dello stesso NEG, pertanto devono sempre essere configurati con NEG distinti.

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 nella 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 nella VM della stessa applicazione di esempio utilizzata nell'esempio precedente. Per semplicità, l'applicazione viene eseguita come contenitore Docker, ma non è essenziale. Il comando iptables è necessario per consentire all'accesso al firewall al contenitore in esecuzione.

3. Verifica che l'applicazione venga pubblicata sulla porta 9376 e che sia 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 sia VM che container.

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

5. Collega l'endpoint della 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 gruppo di elenchi di esclusione abbia l'endpoint della 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 utilizzato per aggiungere un backend del contenitore:

   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 del contenitore esistente inviando traffico di test:

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

   Dovresti vedere le risposte sia dagli endpoint del contenitore (neg-demo-app) sia da quelli della VM (vm1).

VM e container per diversi servizi di backend

Questo esempio mostra come creare un NEG che rimandi a una VM esistente che esegue un carico di lavoro e come aggiungere questo NEG come backend a un nuovo backendService. Questo è utile nel caso in cui i contenitori 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.

Questo esempio estende l'esempio precedente che ha un backend VM nello stesso servizio di backend del backend del contenitore. Questo esempio riutilizza la VM.

Poiché gli endpoint dei contenitori e delle VM sono raggruppati in servizi di backend separati, vengono considerati servizi diversi. Ciò significa che la mappa URL assocerà i backend e indirizzerà il traffico alla VM o al contenitore 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 contenitori 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 contenitore:

   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'vm.example.com host al servizio di backend della 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
   

   Nota: la programmazione completa del bilanciatore del carico richiede alcuni minuti.

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.

Limiti dei NEG autonomi

• Gli errori di convalida delle annotazioni vengono esposti all'utente tramite gli eventi Kubernetes.
• Le limitazioni dei NEG si applicano anche ai NEG autonomi.

• I NEG autonomi non funzionano con le reti precedenti.

• 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.

Prezzi

Per i dettagli sui prezzi del bilanciatore del carico, consulta la sezione sul bilanciamento del carico della pagina dei prezzi. Non è previsto alcun costo aggiuntivo per i NEG.

Risoluzione dei problemi

Questa sezione fornisce la procedura di risoluzione dei problemi comuni che potresti incontrare con i NEG autonomi.

Nessun NEG autonomo configurato

Sintomo: non viene creato alcun NEG.

Possibile risoluzione:

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

Il traffico non raggiunge gli endpoint

Sintomo: errori 502 o connessioni rifiutate.

Possibile risoluzione:

• Una volta configurato il servizio, i nuovi endpoint diventano generalmente raggiungibili dopo l'attacco al NEG, a condizione che rispondano ai controlli di integrità.
• Se dopo questo periodo di tempo il traffico non riesce ancora a raggiungere gli endpoint, generando un 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 dagli seguenti intervalli: 130.211.0.0/22 e 35.191.0.0/16.
  • Verifica che gli endpoint siano operativi utilizzando Google Cloud CLI o chiamando l'API getHealth su backendService o l'API listEndpoints su NEG con il parametro showHealth impostato su SHOW.

Implementazione in stallo

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

Possibile risoluzione:

I controlli di integrità del deployment non vanno a buon fine. L'immagine del contenitore potrebbe essere danneggiata o il controllo di integrità potrebbe essere configurato in modo errato. La sostituzione graduale dei pod attende fino a quando il pod appena avviato non supera il relativo cancello di idoneità dei 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 cancello 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 cancelli di idoneità di un pod con il seguente comando:

  kubectl get my-Pod -o wide
  

  Controlla la colonna BARRIERE DI PRONTO.

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

  kubectl get my-pod -o yaml
  

  I controlli di idoneità e il relativo stato sono elencati nell'output.

• Verifica che l'immagine del contenitore 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.

NEG non viene sottoposto a garbage collection

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

Possibile risoluzione:

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

NEG non è sincronizzato con il servizio

Sintomo: gli endpoint previsti (IP del pod) non esistono nel NEG, il NEG non è sincronizzato o si verifica 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

Possibile risoluzione:

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

• Controlla il valore 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, controlla se esiste un NEG il cui nome e la cui zona corrispondono al nome e alla zona del NEG che il controller NEG GKE deve creare. Ad esempio, un NEG con il nome che il controller NEG deve utilizzare potrebbe essere stato creato utilizzando gcloud CLI o la console Google 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 a un NEG autonomo sono progettate per essere gestite dal controller NEG.

Passaggi successivi

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