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

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

Vedi Caricamento nativo del container di Google Cloud per informazioni sui vantaggi, sui requisiti e sui limiti dell'architettura il bilanciamento del carico.

Panoramica

Un NEG rappresenta un gruppo degli endpoint. GKE supporta i NEG autonomi Tipo di GCE_VM_IP_PORT. GCE_VM_IP_PORT NEG supporta gli endpoint che utilizzano Indirizzo IP interno principale della VM o un indirizzo IP da uno dei suoi IP alias intervalli di tempo.

Nel contesto di un cluster GKE VPC nativo usando NEG autonomi, ogni endpoint corrisponde a un indirizzo IP del pod e a una porta di destinazione. Pod Gli indirizzi IP provengono dall'intervallo IP alias del nodo per i pod, che viene dall'intervallo di indirizzi IP secondari della subnet del cluster di pod.

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

Il seguente diagramma descrive la corrispondenza degli oggetti dell'API Kubernetes oggetti Compute Engine.

In entrata con NEG

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

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

NEG standalone

Quando viene eseguito il deployment dei NEG con bilanciatori del carico di cui è stato eseguito il provisioning da qualcosa di diverso da In entrata, sono considerati NEG autonomi. Viene eseguito il deployment dei NEG autonomi gestite mediante il controller NEG, ma le regole di forwarding, i controlli di integrità il deployment di altri oggetti con bilanciamento del carico viene eseguito manualmente.

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

L'illustrazione seguente mostra le differenze nel modo in cui il bilanciamento del carico in cui viene eseguito il deployment di oggetti in ciascuno scenario:

Prevenire i NEG trapelati

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

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

I casi d'uso per i NEG autonomi includono:

Servizi eterogenei di container e VM

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

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

Controller Ingress personalizzati

Puoi usare un controller Ingress personalizzato (o nessun controller Ingress) per e configurare bilanciatori del carico che abbiano come target NEG autonomi.

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

Usa bilanciatori del carico di rete proxy esterni con GKE

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

Idoneità dei pod

Recupero le gate sono una funzionalità di estensibilità di Kubernetes che consente l'inserimento di feedback o indicatori aggiuntivi in PodStatus per consentire al pod di passare Stato Pronto. Il controller NEG gestisce un limite di idoneità personalizzato per garantire sia funzionante il percorso di rete completo dal bilanciatore del carico di Compute Engine al pod. Idoneità dei pod in GKE sono spiegate nella sezione sul caricamento nativo del container bilanciato.

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

Requisiti

Il cluster deve essere nativo di VPC. Per saperne di più, vedi Creazione di un cluster nativo di VPC.

Nel cluster deve essere abilitato il componente aggiuntivo HttpLoadBalancing. Nei cluster GKE il componente aggiuntivo HttpLoadBalancing è abilitato predefinito.

Prima di iniziare

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

• Attiva l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine .
• Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi initialize con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.

Utilizzo di NEG autonomi

Le seguenti istruzioni mostrano come utilizzare i NEG autonomi con un su GKE.

Devi creare i seguenti oggetti:

• R Deployment che crea e gestisce i pod.
• Un servizio che crea un NEG.
• Un bilanciatore del carico creato con l'API Compute Engine. È diverso dall'uso dei NEG con Ingress, nel qual caso Ingress crea e configura un bilanciatore del carico per te. Con i NEG autonomi, sei responsabile dell'associazione del NEG e del di 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 di VPC per impostazione predefinita, quindi puoi passa a Deployment di un carico di lavoro.

Per i cluster Standard, crea un cluster nativo di VPC zona 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 seguenti specificano i deployment che eseguono tre istanze di un server HTTP containerizzato. Il server HTTP risponde alle richieste con il parametro nome host del server delle applicazioni, il nome del pod su cui è in esecuzione il server.

Ti consigliamo di usare carichi di lavoro che usano il feedback sull'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
  

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 con il nome neg-demo-app.yaml, quindi crea il deployment eseguendo il seguente comando:

kubectl apply -f neg-demo-app.yaml

Crea un servizio

Il manifest seguente specifica un servizio in cui:

• Qualsiasi pod con l'etichetta run: neg-demo-app è membro di questo servizio.
• Il servizio ha uno ServicePort con la porta 80.
• L'annotazione cloud.google.com/neg specifica che la porta 80 sarà associati a un NEG. Il campo facoltativo name specifica che il NEG denominato NEG_NAME. Se il campo name viene omesso, viene restituito un nome univoco vengono generati automaticamente. Per informazioni dettagliate, consulta la sezione 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 del NEG deve essere univoco nella rispettiva 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 supportare NEG autonomi. Ti consigliamo di usare il tipo predefinito, ClusterIP.

Denominazione dei NEG

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

GKE crea un NEG in ogni zona utilizzata dal cluster. La I NEG utilizzano tutti lo stesso nome.

Specificare un nome

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

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

• Non deve corrispondere al nome di qualsiasi NEG esistente che non è stato creato dalla Controller NEG GKE.
• Non deve contenere trattini bassi.

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

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

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

Utilizzo di un nome generato automaticamente

I nomi NEG generati automaticamente sono garantiti come univoci. Per utilizzare un il 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ò rimanere in ascolto su più di una porta. Per definizione, i NEG hanno solo un un unico indirizzo IP e una porta. Ciò significa che se specifichi un servizio con più porte, creerà 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 è una un numero di porta distinto che faccia riferimento a porte di servizio esistenti del servizio. Per ogni porta di servizio elencata, il controller NEG crea un NEG in ogni zona in un cluster Kubernetes.

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 del mapping network-endpoint-groups è una porta di servizio (come SERVICE_PORT_1) e il nome del corrispondente NEG gestiti (come NEG_NAME_1). Elenco zones contiene ogni zona (come ZONE_1) che include 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 denominato k8s1-cca197ad-default-neg-demo-app-80-4db81e02.

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, quindi, al momento della creazione Il NEG conterrà gli IP dei pod.

Esistono due modi per verificare che il NEG sia stato creato e sia corretto configurato. In GKE 1.18.6-gke.6400 e versioni successive, una risorsa personalizzata ServiceNetworkEndpointGroup archivia le informazioni sullo stato dei NEG creati da il controller del servizio. Nelle versioni precedenti, devi ispezionare i NEG strato Add.

La risorsa ServiceNetworkEndpointGroup

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

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 singolo NEG che hai vuoi esaminare.

L'output di questo comando include una sezione dello stato che potrebbe contenere un errore messaggi. Alcuni errori vengono segnalati come eventi di servizio. Puoi trovare ulteriori 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 il NEG, controlla la campo di stato della risorsa ServiceNetworkEndpointGroup per una condizione con type:Synced. L'ora della sincronizzazione più recente è nel fuso orario di status.lastSyncTime .

Le risorse ServiceNetworkEndpointGroup esistono solo nella versione GKE 1.18 e versioni successive.

Ispeziona direttamente i NEG

Verifica che il NEG esista mediante l'elenco dei NEG in Google Cloud e verificando la presenza di un NEG corrispondente al servizio che hai creato. I NEG nome 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 SIZE del NEG è 3, il che significa che ha tre 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 che vuoi visualizzare i singoli endpoint.

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

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. Creare una regola firewall. I bilanciatori del carico devono accedere al cluster endpoint per eseguire i controlli di integrità. Questo comando crea una regola firewall consenti 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 dell'esecuzione del cluster.
   • GKE_NODE_NETWORK_TAGS: i tag di networking sui nodi GKE.

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

   gcloud compute instances describe INSTANCE_NAME
   

   Sostituisci INSTANCE_NAME con il nome dell'host Istanza VM di Compute Engine che esegue il nodo GKE. Ad esempio: L'output nella sezione precedente mostra nomi di 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 attività dei singoli endpoint all'interno del NEG.

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

4. Creare un servizio di backend che specifica che questo è 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 una destinazione proxy per il bilanciatore del carico. Questo esempio è molto semplice perché l'app serve_hostname utilizzata per questa guida ha un singolo 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 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. 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 firewall
• Il proxy HTTP di destinazione
• La mappa URL del controllo di integrità di Compute Engine
• Il servizio di backend
• Il controllo di integrità di Compute Engine

La relazione tra queste risorse è mostrata nel seguente diagramma:

Insieme, queste risorse sono un bilanciatore del carico. Nel passaggio successivo aggiungerai i backend al bilanciatore del carico.

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

Aggiungi backend al bilanciatore del carico

Utilizza gcloud compute backend-services add-backend per connetti 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 dell'endpoint di rete gruppo. Il nome è il nome che hai specificato durante la creazione del NEG o un nome generato automaticamente. Se non hai specificato un nome per il NEG, consulta le seguenti istruzioni per trovare il nome generato automaticamente.
• NEG_ZONE: la zona della rete gruppo di endpoint incluso. Per trovare questo valore, consulta le seguenti istruzioni.

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

gcloud compute network-endpoint-groups list

L'output è simile al seguente:

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

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

È possibile aggiungere più NEG allo stesso servizio di backend. Servizi di backend globali come my-bes, possono avere backend NEG in diversi mentre i servizi di backend regionali devono avere backend in un'unica regione.

Verifica che il bilanciatore del carico funzioni

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

• Verifica che il controllo di integrità sia configurato correttamente e che i report siano integri.
• Accedi all'applicazione e verifica la sua risposta.

Verifica i controlli di integrità

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

Utilizza questo comando per verificare che il servizio di backend sia associato al tuo controllo di integrità e 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-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

Accedi all'applicazione

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

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. Quindi, invia una richiesta a quell'indirizzo IP (34.98.102.37 in questo esempio):

curl 34.98.102.37

La risposta dall'app serve_hostname dovrebbe essere neg-demo-app.

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

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

Configurazione della subnet solo proxy

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

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

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

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

Configurazione delle regole del firewall

Questo esempio utilizza le seguenti regole firewall:

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

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

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

Senza queste regole firewall, il campo di blocco predefinito una regola in entrata blocca in entrata alle istanze di backend.

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

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

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

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

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

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

Configurazione del bilanciatore del carico

Per l'indirizzo IP della regola di forwarding, utilizza una subnet di backend. Se provi a utilizzare La subnet solo proxy non riesce a creare la regola di forwarding.

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

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

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

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

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

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

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

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

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

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

Test

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

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

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

Connettiti a ogni istanza client tramite SSH:

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

Verifica che l'IP stia gestendo il 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 salti la convalida del certificato.

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

Implementazione di servizi eterogenei (VM e container)

I bilanciatori del carico possono essere frontend per ambienti Kubernetes e non Kubernetes carichi di lavoro con scale out impegnativi. Potrebbe far parte di una migrazione dalle VM ai container permanente che sfrutta un bilanciatore del carico condiviso. Può essere si ottiene 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 punti a una VM esistente che esegue carico di lavoro e come aggiungere questo NEG come un altro backend di un backendService esistente. In questo modo, un singolo bilanciatore del carico bilancia tra le VM e i container GKE.

Questo esempio estende l'esempio precedente che utilizza una richiesta HTTP esterna con il bilanciatore del carico di rete passthrough esterno regionale.

Poiché tutti gli endpoint sono raggruppati per lo stesso backendService, la VM e gli endpoint dei container sono considerati lo stesso servizio. Ciò significa che l'host o il percorso la corrispondenza 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 in anche quel servizio di backend deve essere NEG. Non puoi utilizzare gruppi di istanze e NEG e i backend nello stesso servizio di backend. Inoltre, i container e le VM non possono esistono come endpoint all'interno dello stesso NEG, quindi devono essere sempre configurati con in NEG separati.

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

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

   Sostituisci quanto segue:

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

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

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

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

3. Verifica che l'applicazione venga pubblicata sulla porta 9376 e che esegua report che è in esecuzione su vm1:

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

   Il server dovrebbe rispondere con vm1.

4. Crea un NEG da utilizzare con l'endpoint VM. Sia i container che le VM possono essere NEG ma un singolo NEG non può avere endpoint VM e container.

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

5. Collega l'endpoint VM al NEG:

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

   Sostituisci VM_PRIMARY_IP con l'indirizzo IP principale della VM.

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

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

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

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

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

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

9. Verifica che il bilanciatore del carico inoltri il traffico sia alla nuova VM1 e quello del container esistente inviando traffico di prova:

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

   Dovresti vedere le risposte degli endpoint del container (neg-demo-app) e della VM (vm1).

VM e container per servizi di backend diversi

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

Questo esempio estende l'esempio precedente con un backend VM in lo stesso servizio di backend del backend del container. In questo esempio la VM viene riutilizzata.

Poiché gli endpoint container e VM sono raggruppati in servizi di backend separati, vengono considerati servizi diversi. Ciò significa che la mappa URL creare corrispondenze tra i backend e indirizzare il traffico alla VM o al container in base al nome host.

Il seguente diagramma mostra come un singolo indirizzo IP virtuale corrisponde a due nomi host, che a loro volta corrispondono a un servizio di backend basato su container e a 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 richieste dirette per l'host container.example.com al servizio di backend del container:

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

4. Aggiungi un'altra regola host della mappa URL per indirizzare le richieste per 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
   

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

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

   Sostituisci VIRTUAL_IP con l'indirizzo IP virtuale.

Limitazioni dei NEG autonomi

• Gli errori di convalida delle annotazioni vengono esposti all'utente tramite Kubernetes eventi.
• I limiti della NEG si applicano anche ai NEG autonomi.

• I NEG autonomi non funzionano con le reti legacy.

• I NEG autonomi possono essere utilizzati solo con servizi di rete compatibili, tra cui Cloud Service Mesh e tipi di bilanciatore del carico compatibili.

Prezzi

Fai riferimento alla sezione sul bilanciamento del carico nella pagina dei prezzi. per i dettagli sui prezzi del bilanciatore del carico. Non sono previsti costi aggiuntivi per NEG.

Risoluzione dei problemi

Questa sezione fornisce i passaggi per la risoluzione dei problemi comuni che con i NEG autonomi.

Nessun NEG autonomo configurato

Sintomo: non viene creato alcun NEG.

Potenziale risoluzione:

• Controlla gli eventi associati al servizio e cerca i messaggi di errore.
• Verifica che l'annotazione NEG autonoma sia un JSON in un formato corretto e che l'oggetto esposto che corrispondono a quelle esistenti nella specifica del servizio.
• Verifica l'annotazione dello stato NEG e controlla se le porte di servizio previste sono NEG corrispondenti.
• Verifica che i NEG siano stati creati nelle zone previste, con il comando gcloud compute network-endpoint-groups list.
• Se utilizzi GKE 1.18 o versioni successive, controlla se svcneg risorsa per il servizio esiste. Se si accende, controlla Initialized condizione per eventuali informazioni sull'errore.
• Se utilizzi nomi NEG personalizzati, assicurati che ogni NEG è univoco nella sua regione.

Il traffico non raggiunge gli endpoint

Sintomo:errori 502 o connessioni rifiutate.

Potenziale risoluzione:

• Dopo la configurazione del servizio, i nuovi endpoint diventano generalmente raggiungibili dopo averli collegati al NEG, a condizione che rispondano ai controlli di integrità.
• Se, trascorso questo periodo di tempo, il traffico non è ancora riuscito a raggiungere gli endpoint, generando un errore di 502 codice di errore per HTTP(S) o connessioni rifiutate per il carico TCP/SSL bilanciatori del carico, verifica quanto segue:
  • Verifica che le regole firewall consentano il traffico TCP in entrata verso gli endpoint da seguenti intervalli: 130.211.0.0/22 e 35.191.0.0/16.
  • Verifica che gli endpoint siano integri utilizzando Google Cloud CLI o chiamando API getHealth su backendService o API listEndpoints nel NEG con il parametro showHealth impostato su SHOW.

Implementazione bloccata

Sintomo:l'implementazione di blocchi del deployment aggiornati e il numero le repliche aggiornate non corrispondono al numero scelto di repliche.

Potenziale risoluzione:

I controlli di integrità del deployment non sono riusciti. L'immagine container potrebbe non essere valida il controllo di integrità potrebbe non essere configurato correttamente. La sostituzione in sequenza dei pod attende finché il pod appena avviato non supera il gate di idoneità dei pod. Ciò si verifica solo se il pod risponde ai controlli di integrità del bilanciatore del carico. Se il pod non o se il controllo di integrità non è configurato correttamente, le condizioni del controllo di e l'implementazione non può continuare.

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

  kubectl get my-Pod -o wide
  

  Controlla la colonna GATE DI RECUPERO.

  Questa colonna non esiste in kubectl 1.12 e versioni precedenti. Un pod contrassegnato come se è nello stato PRONTO, potrebbe avere un gate di idoneità non superato. Per verificarlo, utilizza il seguente comando:

  kubectl get my-pod -o yaml
  

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

• Verifica che l'immagine container nella specifica dei pod del deployment sia funziona correttamente ed è in grado di rispondere ai controlli di integrità.

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

Il NEG non è un garbage collection

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

Potenziale risoluzione:

• Il NEG non è garbage collection se un backend fa riferimento al NEG completamente gestito di Google Cloud. Per maggiori dettagli, consulta Prevenire i NEG divulgati.
• Se usi la versione 1.18 o versioni successive, puoi controllare gli eventi nella ServiceNetworkEndpointGroup utilizzando la procedura di neg del servizio.
• Controlla se il NEG è ancora necessario per un servizio. Controlla svcneg risorsa per il servizio corrispondente al NEG e verificare se un Service l'annotazione esiste già.

Il NEG non è sincronizzato con il servizio

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

Potenziale risoluzione:

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

• Controlla il valore status.lastSyncTime per verificare se il NEG è stato sincronizzato di recente.
• Controlla la condizione Synced per verificare la presenza di eventuali errori che si sono verificati nell'evento più recente sincronizzare.

Se utilizzi GKE 1.19.9 o versioni successive, controlla se sono disponibili esiste un NEG il cui nome e la zona corrispondono al nome e alla zona del NEG che È necessario creare il controller NEG GKE. Ad esempio, un NEG con il nome che deve essere utilizzato dal controller NEG potrebbe essere stato creato 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 suoi endpoint. Creazione di NEG autonomo e l'appartenenza sono progettate per essere gestite dal controller NEG.

Passaggi successivi

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