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 GCE_VM_IP_PORT (NEG) di zona in un cluster nativo VPC Google Kubernetes Engine (GKE).

Consulta la pagina relativa al bilanciamento del carico nativo del container per informazioni su vantaggi, requisiti e limitazioni del bilanciamento del carico nativo del container.

Panoramica

Un NEG rappresenta un gruppo di endpoint. GKE supporta i NEG autonomi del 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 da uno dei suoi intervalli IP alias.

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

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

Il seguente diagramma descrive la modalità con cui gli oggetti dell'API Kubernetes corrispondono agli oggetti di Compute Engine.

I servizi Kubernetes corrispondono ai gruppi di endpoint di rete di Compute Engine, mentre i pod Kubernetes corrispondono agli endpoint di rete Compute Engine. Il componente del controller NEG del piano di controllo gestisce questa situazione.

Ingress con NEG

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

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

NEG standalone

Quando viene eseguito il deployment dei NEG con bilanciatori del carico di cui non si tratta il traffico in entrata, sono considerati NEG autonomi. Il deployment dei NEG autonomi viene eseguito e gestito tramite il controller NEG, ma le regole di forwarding, i controlli di integrità e altri oggetti di bilanciamento del carico vengono sottoposti a deployment manualmente.

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

La seguente illustrazione mostra le differenze nel modo in cui viene eseguito il deployment degli oggetti di bilanciamento del carico in ogni scenario:

Con i NEG autonomi e i NEG gestiti da Ingress, il controller NEG sul piano di controllo GKE gestisce gli oggetti NEG e degli endpoint di rete. Con i NEG autonomi, ogni altro componente è gestito dall'utente come descritto nei paragrafi precedenti.

Evitare NEG di fuga

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 dati NEG nei seguenti modi:

  • Quando un servizio GKE viene eliminato, il NEG associato non sarà garbage collection se il NEG fa ancora riferimento a un servizio di backend. Fai riferimento al 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. in contrasto con Ingress (utilizzato con o senza NEG), che definisce un insieme specifico di oggetti di bilanciamento del carico che sono stati scelti in modo convinto per semplificarne l'utilizzo.

I casi di utilizzo dei NEG autonomi includono:

Servizi eterogenei di container e VM

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

I NEG autonomi possono puntare a IP VM, il che consente di configurare manualmente i bilanciatori del carico in modo che puntino a backend composti sia da VM che da container per lo stesso VIP di servizio.

Controller Ingress personalizzati

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

Utilizza Traffic Director con GKE

Puoi utilizzare Traffic Director con GKE. Traffic Director utilizza i NEG autonomi per fornire il bilanciamento del carico nativo del container per il mesh di servizi gestito.

Usa il bilanciamento del carico del proxy TCP esterno con GKE

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

Preparazione del pod

I gateway di prontezza sono una funzionalità di estensibilità di Kubernetes che consente l'inserimento di feedback o indicatori aggiuntivi nel podStatus per consentire al pod di passare allo stato Ready. Il controller NEG gestisce un gate di idoneità personalizzato per garantire che il percorso di rete completo dal bilanciatore del carico di Compute Engine al pod funzioni. Le porte di idoneità 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 presuppongono ipotesi sui controlli di integrità di Compute Engine perché si prevede che ne verrà eseguito il deployment e la gestione separatamente. I controlli di integrità di Compute Engine devono sempre essere configurati insieme al bilanciatore del carico, per evitare che il traffico venga inviato a backend che non sono pronti a ricevere. Se al NEG non è associato uno stato del controllo di integrità (di solito perché non è configurato alcun controllo di integrità), il controller NEG contrassegna il valore del gate di idoneità del pod su True quando il relativo endpoint corrispondente è programmato in NEG.

Requisiti

I NEG autonomi sono disponibili in GKE 1.10 e versioni successive. Il feedback di idoneità dei pod è abilitato per i NEG autonomi nella versione 1.16.4 e successive.

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

Per il tuo cluster deve essere abilitato il componente aggiuntivo HttpLoadBalancing. Per i cluster GKE è attivato il componente aggiuntivo HttpLoadBalancing per impostazione predefinita.

Prima di iniziare

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

  • Abilita l'API Google Kubernetes Engine.
  • Abilita l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza l'interfaccia a riga di comando gcloud.

Utilizzo di NEG autonomi

Le seguenti istruzioni 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 pod.
  • Un servizio che crea un NEG.
  • Un bilanciatore del carico creato con l'API Compute Engine. Questo differisce 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 di 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 diagramma seguente:

I componenti di un bilanciatore del carico sono regole di forwarding, proxy HTTP di destinazione, mappa URL, controllo di integrità e servizio di backend. Questo indirizza il traffico a un NEG che contiene indirizzi IP del pod.

Crea un cluster nativo di VPC

Per utilizzare il bilanciamento del carico nativo del container, devi creare un cluster con IP alias abilitati. Questo cluster:

  • È necessario eseguire GKE versione 1.16.4 o successiva.
  • Deve essere un cluster nativo di VPC.
  • Deve essere attivato il componente aggiuntivo HttpLoadBalancing.

Il comando seguente crea un cluster nella zona us-central1-a con una subnet di cui è stato eseguito il provisioning automatico:

gcloud container clusters create neg-demo-cluster \
    --enable-ip-alias \
    --create-subnetwork="" \
    --network=default \
    --zone=us-central1-a \
    --cluster-version VERSION

Sostituisci VERSION con il numero di versione del cluster. La versione deve essere 1.16.4 o successiva.

Creazione di un deployment

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

Ti consigliamo di utilizzare i carichi di lavoro che utilizzano il feedback di idoneità del pod, se questa è disponibile nella versione di GKE in uso. Per ulteriori informazioni, consulta la sezione sull'idoneità dei pod e consulta la sezione Requisiti per i requisiti di versione di GKE per l'utilizzo del feedback di idoneità dei pod. Valuta l'opportunità di eseguire l'upgrade del cluster per utilizzare il feedback sull'idoneità del pod.

Utilizzo del feedback di idoneità del 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: k8s.gcr.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

Utilizzare il 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: k8s.gcr.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 comando seguente:

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 dispone di un campo ServicePort con la porta 80.
  • L'annotazione cloud.google.com/neg specifica che la porta 80 sarà associata a un NEG. Il campo facoltativo name specifica che il NEG sarà denominato NEG_NAME. Se il campo name viene omesso, verrà generato automaticamente un nome univoco. Per maggiori dettagli, vedi la denominazione dei NEG.
  • 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 NEG deve essere univoco nella rispettiva area geografica.

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

kubectl apply -f neg-demo-svc.yaml

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

Tipi di servizi

Anche se in questo esempio viene utilizzato un servizio ClusterIP, tutti e cinque i tipi di servizi supportano i NEG autonomi. Consigliamo il tipo predefinito ClusterIP.

Denominazione NEG

Nelle versioni di 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. I NEG utilizzano tutti lo stesso nome.

Specificare un nome

Specificare un nome NEG personalizzato semplifica la configurazione del bilanciatore del carico perché conosci il nome e la zona o i paesi del NEG in anticipo. I nomi NEG personalizzati devono soddisfare i seguenti requisiti:

  • Devono essere univoci per la zona del cluster all'interno dei cluster di zona o univoci per la regione dei cluster a livello di regione.
  • Non deve corrispondere al nome di alcun NEG esistente che non sia stato creato dal controller NEG GKE.

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 NEG deve essere univoco nella rispettiva area geografica.

Utilizzare 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

Mappatura delle porte a più NEG

Un servizio può ascoltare su più porte. Per definizione, i NEG hanno un solo 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 si riferisce alle porte di servizio esistenti del Servizio. Per ogni porta di servizio elencata, il controller NEG crea un NEG in ogni zona occupa il cluster.

Recuperare gli stati NEG

Utilizza il comando seguente 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 tutte le zone (ad esempio ZONE_1) che contengono 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":["us-central1-a", "us-central1-b"]}'
  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 nelle zone us-central1-a e us-central1-b.

Convalida creazione NEG

Un NEG viene creato entro pochi minuti dalla creazione del servizio. Se sono presenti 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 creato e configurato correttamente. In GKE 1.18.6-gke.6400 e versioni successive, una risorsa personalizzata ServiceNetworkEndpointGroup archivia le informazioni sullo stato relative ai NEG creati dal controller di servizio. Nelle versioni precedenti, devi controllare direttamente i NEG.

La risorsa ServiceNetworkEndpointGroup

Elenca i NEG in un cluster ottenendo 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 controllare.

L'output di questo comando include una sezione di stato che potrebbe contenere messaggi di errore. Alcuni errori vengono segnalati come eventi di servizio. Per ulteriori dettagli, esegui 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 sincronizzi correttamente il NEG, controlla il campo di 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 nella versione 1.18 e successive di GKE.

Ispezione diretta dei NEG

Verifica l'esistenza del NEG elencando i NEG nel tuo progetto Google Cloud e cercando un 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  us-central1-a  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 comando seguente:

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

Sostituisci NEG_NAME con il nome del NEG per il quale vuoi visualizzare i singoli endpoint.

L'output mostra tre endpoint, ognuno dei quali ha un indirizzo IP e una porta del pod:

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

Collegamento di un bilanciatore del carico HTTP(S) esterno a NEG autonomi

Puoi utilizzare i NEG come backend per un bilanciatore del carico HTTP(S) esterno utilizzando l'API Compute Engine.

  1. Creare 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 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 comando seguente:

    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 nel 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 validità 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 HTTP(S) 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 inoltro. È questo che 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. Puoi prenotare un nuovo indirizzo IP esterno statico a questo scopo. Puoi anche omettere l'opzione --address e verrà assegnato automaticamente un indirizzo IP temporaneo.

Check Point

Le risorse che hai creato finora:

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

La relazione tra queste risorse è mostrata nel diagramma seguente:

""

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

Uno dei vantaggi di NEG autonomi che abbiamo dimostrato è 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 bilanciatore del carico senza modificare nessuno degli oggetti del bilanciatore 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 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. Segui le istruzioni riportate di seguito per trovare questo valore.

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  us-central1-a  GCE_VM_IP_PORT  3

In questo output di esempio, il nome del NEG è k8s1-70aa83a6-default-my-service-80-c9710a6f e si trova nella zona us-central1-a.

È 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 a livello di regione 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 il report sia integro.
  • Accedere all'applicazione e verificarne la risposta.

Verificare i controlli di integrità

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

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

Quindi, 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-standard-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-standard-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-standard-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 confermare che tutto funzioni.

Innanzitutto, 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. Poi, 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 HTTP(S) interno a NEG autonomi

Puoi utilizzare i NEG per configurare un bilanciatore del carico HTTP(S) 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 HTTP(S) interni nella regione del bilanciatore del carico, in questo esempio us-west1.

console

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

gcloud

Crea la subnet solo proxy con il comando gcloud compute Networks subnetscreate.

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

Server

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

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/us-west1/subnetworks
{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "region": "projects/PROJECT_ID/regions/us-west1",
  "purpose": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

Sostituisci PROJECT_ID con l'ID progetto.

Configurazione delle regole del firewall

In questo esempio vengono utilizzate le seguenti regole firewall:

  • fw-allow-ssh: una regola in entrata, applicabile alle istanze in fase di 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. In questo esempio viene utilizzato 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 in fase di bilanciamento del 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). In questo esempio viene utilizzato 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 in fase di bilanciamento del carico, che consente il traffico TCP sulla porta 9376 dal proxy del carico HTTP(S) interno. In questo esempio viene utilizzato il tag di destinazione load-balanced-backend per identificare le istanze a cui deve essere applicato.

Senza queste regole firewall, la regola default nega in entrata blocca il traffico in entrata verso le istanze di backend.

console

  1. Vai alla pagina Regole firewall in Google Cloud Console. Vai a Regole firewall
  2. Fai clic su Crea regola firewall per creare la regola per consentire 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 target specificati
    • Tag di destinazione: allow-ssh
    • Filtro di origine: IP ranges
    • Intervalli IP 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 target specificati
    • Tag di destinazione: load-balanced-backend
    • Filtro di origine: IP ranges
    • Intervalli IP 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 tramite HTTP sulla porta 80, ma non può contattarle tramite HTTPS sulla porta 443.
  5. Fai clic su Crea.
  6. Fai di nuovo clic su Crea regola firewall per creare la regola per consentire ai server proxy del bilanciatore del carico di connettere i backend:
    • Nome: fw-allow-proxies
    • Rete: lb-network
    • Direzione del traffico: in entrata
    • Azione in caso di corrispondenza: Consenti
    • Target: tag target specificati
    • Tag di destinazione: load-balanced-backend
    • Filtro di origine: IP ranges
    • Intervalli IP 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 tag di rete allow-ssh. Quando ometti source-ranges, Google Cloud interpreta la regola in modo da indicare 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 da probe di controllo di integrità; tuttavia, puoi configurare un insieme di porte più ristrette per soddisfare le 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 la connessione ai proxy di bilanciamento del carico HTTP(S) interno.

    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
    

Server

Crea la regola firewall fw-allow-ssh effettuando 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 effettuando 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 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 della regola di forwarding non riuscirà.

console

Seleziona un tipo di bilanciatore del carico

  1. Vai alla pagina Crea un bilanciatore del carico in Google Cloud Console. 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 significa che il bilanciatore del carico è interno.
  4. Fai clic su Continua.

Prepara il bilanciatore del carico

  1. In Name (Nome) del bilanciatore del carico, inserisci l7-ilb-gke-map.
  2. Per Area geografica, seleziona us-west1.
  3. In Rete, seleziona lb-network.

Prenota una subnet solo proxy

Per il bilanciamento del carico HTTP(S) interno, prenota una subnet proxy:

  1. Fai clic su Prenota una subnet.
  2. In Nome, inserisci proxy-only-subnet.
  3. In 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. Per 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 NEG creato da GKE. Per ottenere il nome NEG, consulta la pagina di convalida del NEG.
    2. Per RPS massimo, specifica una frequenza massima di 5 RPS per endpoint. Google Cloud supererà questo limite massimo, se necessario.
    3. Fai clic su Fine.
  6. Nell'elenco a discesa Controllo di integrità, seleziona Crea un controllo di integrità, quindi 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 senza corrispondenza e qualsiasi 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 il Protocollo su HTTP.
  5. Imposta la 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 Fammi scegliere.
    3. Nella sezione Indirizzo IP personalizzato, inserisci 10.1.2.199.
    4. Fai clic su Prenota.
  8. Imposta il campo Porta su 80.
  9. Fai clic su Fine.

Per HTTPS:

Se utilizzi HTTPS tra il client e il bilanciatore del carico, sono necessarie una o più risorse del certificato SSL per configurare il proxy. Per informazioni su come creare risorse dei certificati SSL, consulta la pagina Certificati SSL. I certificati gestiti da Google non sono attualmente 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 Fammi scegliere.
    3. Nella sezione Indirizzo IP personalizzato, inserisci 10.1.2.199.
    4. Fai clic su Prenota.
  8. Assicurati che la porta sia impostata su 443 per consentire il traffico HTTPS.
  9. Fai clic sull'elenco a discesa Certificato.
    1. Se hai già una risorsa certificato SSL autogestita che vuoi utilizzare come certificato SSL principale, selezionala dal menu a discesa.
    2. In alternativa, seleziona Crea un nuovo certificato.
      1. Inserisci un Nome di l7-ilb-cert.
      2. Nei campi appropriati, carica i file in formato PEM:
        • Certificato di chiave pubblica
        • Catena di certificati
        • Chiave privata
      3. Fai clic su Crea.
  10. Per aggiungere risorse dei certificati 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 riportate sopra.
  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=us-west1 \
        --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=us-west1 \
        --region=us-west1
    
  3. Imposta la variabile DEPLOYMENT_NAME:

    export DEPLOYMENT_NAME=NEG_NAME
    

    Sostituisci NEG_NAME con il nome del NEG.

  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=us-west1-b \
        --region=us-west1 \
        --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=us-west1
    
  6. Crea il proxy di destinazione.

    Per HTTP:

    Usa 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=us-west1 \
        --region=us-west1
    

    Per HTTPS:

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

    Assegna i percorsi dei 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=us-west1
    

    Utilizza il certificato SSL a livello di regione 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=us-west1 \
        --ssl-certificates=l7-ilb-cert
    
  7. Crea la regola di forwarding.

    Per le reti personalizzate, devi fare riferimento alla subnet nella regola di forwarding. Tieni presente che questa è la subnet della VM, non la 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=us-west1 \
        --target-http-proxy=l7-ilb-gke-proxy \
        --target-http-proxy-region=us-west1
    

    Per HTTPS:

    Utilizza il comando gcloud compute forwarding-rulescreate 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=us-west1 \
        --target-https-proxy=l7-ilb-gke-proxy \
        --target-https-proxy-region=us-west1
    

Server

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/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 a livello di area geografica inviando una richiesta POST al metodo regionBackendServices.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices
{
  "name": "l7-ilb-gke-backend-service",
  "backends": [
    {
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-b/networkEndpointGroups/NEG_NAME",
      "balancingMode": "RATE",
      "maxRatePerEndpoint": 5
    }
  ],
  "healthChecks": [
    "projects/PROJECT_ID/regions/us-west1/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/us-west1/urlMaps
{
  "name": "l7-ilb-gke-map",
  "defaultService": "projects/PROJECT_ID/regions/us-west1/backendServices/l7-ilb-gke-backend-service"
}

Sostituisci PROJECT_ID con l'ID progetto.

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/targetHttpProxy
{
  "name": "l7-ilb-gke-proxy",
  "urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-gke-map",
  "region": "us-west1"
}

Sostituisci PROJECT_ID con l'ID progetto.

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules
{
  "name": "l7-ilb-gke-forwarding-rule",
  "IPAddress": "10.1.2.199",
  "IPProtocol": "TCP",
  "portRange": "80-80",
  "target": "projects/PROJECT_ID/regions/us-west1/targetHttpProxies/l7-ilb-gke-proxy",
  "loadBalancingScheme": "INTERNAL_MANAGED",
  "subnetwork": "projects/PROJECT_ID/regions/us-west1/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-us-west1-b \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --zone=us-west1-b \
    --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 tramite l'indirizzo IP della regola di forwarding HTTP(S) interno del bilanciatore del traffico e che il traffico venga bilanciato del carico tra gli endpoint nel NEG.

Connettiti a ogni istanza client tramite SSH:

gcloud compute ssh l7-ilb-client-us-west1-b \
    --zone=us-west1-b

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

curl 10.1.2.199

Per il test HTTPS, esegui il comando seguente:

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 non ignori la convalida del certificato.

Esegui 100 richieste e verifica che siano bilanciate del 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
}

Implementare servizi eterogenei (VM e container)

I bilanciatori del carico possono essere frontend per carichi di lavoro misti Kubernetes e non Kubernetes. Questa parte potrebbe far parte di una migrazione dalle VM ai container o un'architettura permanente che trae vantaggio da un bilanciatore del carico condiviso. A tale scopo, puoi creare bilanciatori del carico che abbiano 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 punti 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 unico bilanciatore del carico bilancia i dati tra VM e container GKE.

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

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

Diagramma che mostra l'architettura descritta. Il bilanciatore del carico creato in precedenza punta a due NEG, il NEG per i container creati in precedenza e un nuovo NEG contenente un indirizzo IP di VM

Quando utilizzi un NEG come backend per un servizio di backend, anche tutti gli altri backend in quel servizio 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, quindi devono essere sempre configurati con NEG separati.

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

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

    Sostituisci quanto segue:

    • 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=ZONE \
        --command="docker run -d --rm --network=host k8s.gcr.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 container Docker, ma questo non è essenziale. È richiesto il comando iptables per consentire l'accesso al firewall in esecuzione al container in esecuzione.

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

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

    Il server dovrebbe rispondere con vm1.

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

    gcloud compute network-endpoint-groups create vm-neg \
        --subnet=SUBNET \
        --zone=ZONE
    
  5. Collega l'endpoint della VM al NEG:

    gcloud compute network-endpoint-groups update vm-neg \
        --zone=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 della VM:

    gcloud compute network-endpoint-groups list-network-endpoints vm-neg \
        --zone ZONE
    
  7. Collega il NEG al servizio di backend utilizzando lo stesso comando che hai utilizzato per aggiungere un backend del container:

    gcloud compute backend-services add-backend my-bes
        --global \
        --network-endpoint-group vm-neg \
        --network-endpoint-group-zone 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 al nuovo backend di vm1 e al backend del container esistente inviando il traffico di prova:

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

    Dovresti vedere le risposte sia dagli endpoint container (neg-demo-app) che dagli endpoint VM (vm1).

VM e container per diversi servizi di backend

Questo esempio mostra come creare un NEG che punti 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 container e VM siano servizi diversi, ma debbano condividere lo stesso bilanciatore del carico L7, ad esempio se i servizi condividono lo stesso indirizzo IP o lo stesso nome di dominio.

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

Poiché gli endpoint a livello di container e di VM sono raggruppati in servizi di backend separati, sono considerati servizi diversi. Ciò significa che la mappa URL corrisponderà ai backend e indirizza 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:

L'architettura prevede due NEG, uno per il servizio implementato con container e un altro per il servizio implementato con VM. È presente un oggetto servizio di backend per ogni NEG. L'oggetto mappa URL indirizza il traffico al servizio di backend corretto in base all'URL richiesto.

  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 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 dei 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 sulla 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 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

Prezzi

Per maggiori dettagli sui prezzi del bilanciatore del carico, consulta la sezione sul bilanciamento del carico della pagina dei prezzi. Non sono previsti costi aggiuntivi per i NEG.

Risolvere i problemi

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 in formato JSON valido e che le porte esposte corrispondano alle porte esistenti nella specifica del servizio.
  • Verifica l'annotazione di stato del NEG e verifica 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 versione 1.18 o successiva, verifica se la risorsa svcneg per il servizio esiste. In questo caso, controlla la condizione Initialized per verificare la presenza di eventuali informazioni sull'errore.
  • Se utilizzi nomi NEG personalizzati, assicurati che ogni nome NEG sia univoco nella sua area geografica.

Il traffico non raggiunge gli endpoint

Sintomo: errori 502 o connessioni rifiutate.

Potenziale risoluzione:

  • Dopo la configurazione del servizio, i nuovi endpoint saranno generalmente raggiungibili dopo essere stati collegati a NEG, a condizione che rispondano ai controlli di integrità.
  • Se trascorso questo periodo di tempo il traffico non è ancora in grado di raggiungere gli endpoint causando il codice di errore 502 per HTTP(S) o il rifiuto delle connessioni per i bilanciatori del carico TCP/SSL, verifica 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 i tuoi endpoint siano integri utilizzando l'interfaccia a riga di comando di Google Cloud o chiamando l'API getHealth su backendService o l'API listEndpoints nel NEG con il parametro showHealth impostato su SHOW.

Implementazione bloccata

Sintomo: il deployment di un deployment aggiornato di deployment e il numero di repliche aggiornate non corrisponde al numero di repliche desiderato.

Potenziale risoluzione:

I controlli di integrità del deployment non vanno a buon fine. L'immagine container potrebbe essere errata o il controllo di integrità potrebbe essere configurato in modo errato. La sostituzione continua dei pod attende che il pod appena avviato non superi il relativo gate di idoneità. Questo 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à non è configurato correttamente, 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 gate di idoneità 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 PRONTO potrebbe avere un gate di idoneità non riuscito. Per verificarlo, utilizza il comando seguente:

    kubectl get my-pod -o yaml
    

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

  • 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 è la garbage collection

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

Potenziale risoluzione:

  • Il NEG non è la garbage collection se il NEG fa riferimento a un servizio di backend. Per maggiori dettagli, vedi Evitare NEG di divulgazione.
  • Se utilizzi la versione 1.18 o versioni successive, puoi controllare gli eventi nella risorsa ServiceNetworkEndpointGroup utilizzando questa procedura.
  • Verifica se un NEG è ancora necessario per un servizio. Controlla la risorsa svcneg per il servizio che corrisponde al NEG e verifica se esiste un'annotazione di 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, consulta la risorsa svcneg per informazioni:

  • Controlla il valore status.lastSyncTime per verificare se il NEG si è sincronizzato di recente.
  • Controlla la condizione Synced per verificare se sono presenti errori verificatisi nella sincronizzazione più recente.

Se utilizzi GKE 1.19.9 o versioni successive, controlla se esiste un NEG il cui nome e la 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 nella zona del cluster (o una delle zone del cluster). In questo caso, devi eliminare il NEG esistente prima che il controller NEG possa sincronizzare i suoi endpoint. La creazione e l'appartenenza a NEG autonomi sono progettate per essere gestite dal controller NEG.

Passaggi successivi