Questa pagina mostra come creare un servizio Kubernetes supportato da un
gruppo di endpoint di rete GCE_VM_IP_PORT
a livello di zona
(NEG) in un
cluster nativo di VPC Google Kubernetes Engine (GKE).
Consulta 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 NEG autonomi di tipo GCE_VM_IP_PORT
. GCE_VM_IP_PORT
I NEG supportano gli endpoint utilizzando l'indirizzo IP interno principale della VM o un indirizzo IP di uno dei suoi intervalli IP alias.
Nel contesto di un cluster GKE VPC nativo che utilizza NEG autonomi, ogni endpoint è un indirizzo IP del pod e una porta di destinazione. Gli indirizzi IP dei pod provengono dall'intervallo IP alias del nodo per i pod, che deriva dall'intervallo di indirizzi IP secondari della subnet per i pod del cluster.
GKE fornisce un controller NEG per gestire l'appartenenza dei NEG GCE_VM_IP_PORT
. Puoi aggiungere i NEG creati come backend ai servizi di backend per i bilanciatori del carico che configuri al di fuori dell'API GKE.
Il seguente diagramma descrive in che modo gli oggetti dell'API Kubernetes corrispondono agli 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 bilanciatore del carico. Ciò include la creazione di indirizzo IP virtuale, regole di forwarding, controlli di integrità, regole firewall e altro ancora.
Ingress è il modo consigliato per utilizzare il bilanciamento del carico nativo del container, in quanto offre molte funzionalità che semplificano la gestione dei NEG. I NEG autonomi sono un'opzione se i NEG gestiti da Ingress non sono adatti al tuo caso d'uso.
NEG standalone
Quando i NEG vengono distribuiti con bilanciatori del carico di cui è stato eseguito il provisioning da altri elementi da Ingress, sono considerati NEG autonomi. Il deployment dei NEG autonomi viene eseguito e gestito tramite il controller NEG, mentre il deployment delle regole di forwarding, dei controlli di integrità e di altri oggetti di bilanciamento del carico viene eseguito manualmente.
I NEG autonomi non sono in conflitto con il bilanciamento del carico nativo del container abilitato per Ingress.
L'illustrazione seguente mostra le differenze nel modo in cui viene eseguito il deployment degli oggetti di bilanciamento del carico in ogni scenario:
Prevenzione dei NEG divulgati
Con i NEG autonomi, sei responsabile della gestione dei cicli di vita dei NEG e delle risorse che costituiscono il bilanciatore del carico. Potresti perdere NEG in questi modi:
- Quando un servizio GKE viene eliminato, il NEG associato non verrà garbage collection se il servizio di backend fa ancora riferimento al NEG. Dereferenzia il NEG dal servizio di backend per consentire l'eliminazione del NEG.
- Quando viene eliminato un cluster, 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. A differenza di Ingress (con o senza NEG), che definisce un insieme specifico di oggetti di bilanciamento del carico che sono stati scelti in modo "guidato" per renderli di facile utilizzo.
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 un singolo indirizzo IP virtuale può puntare a un backend composto da carichi di lavoro Kubernetes e non Kubernetes. Può essere usata anche per eseguire la migrazione di carichi di lavoro esistenti a un cluster GKE.
I NEG autonomi possono puntare agli IP delle VM, il che rende possibile la configurazione manuale dei 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 bilanciatori del carico che hanno come target NEG autonomi.
Utilizzare 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 gestiti.
Utilizza bilanciatori del carico di rete proxy esterni con GKE
Puoi utilizzare NEG autonomi per bilanciare il carico direttamente nei container con il bilanciatore del carico di rete proxy esterno, che non è supportato in modo nativo da Kubernetes/GKE.
Preparazione pod
Le gates di idoneità sono una funzionalità di estensibilità di Kubernetes che consente l'inserimento di feedback o segnali aggiuntivi in PodStatus per consentire al pod di passare allo stato Pronto. Il controller NEG gestisce un gate di idoneità personalizzato per garantire che l'intero percorso di rete 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.
In entrata con NEG esegue il deployment e gestisce i controlli di integrità di Compute Engine per conto del bilanciatore del carico. Tuttavia, i NEG autonomi non fanno ipotesi sui controlli di integrità di Compute Engine perché sono previsti per il deployment e la gestione separatamente. I controlli di integrità di Compute Engine devono essere sempre configurati insieme al bilanciatore del carico per impedire l'invio del traffico ai backend non pronti a ricevere. Se non esiste uno stato di controllo di integrità associato al NEG (di solito perché non è configurato alcun controllo di integrità), il controller NEG contrassegna il valore del gate di idoneità del pod su True quando l'endpoint corrispondente è programmato in NEG.
Requisiti
Il cluster deve essere nativo di VPC. Per scoprire di più, consulta Creazione di un cluster nativo di VPC.
Nel cluster deve essere abilitato il componente aggiuntivo HttpLoadBalancing
.
Il componente aggiuntivo HttpLoadBalancing
è abilitato per impostazione predefinita nei cluster GKE.
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 initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo
gcloud components update
.
Utilizzo di NEG autonomi
Le istruzioni seguenti mostrano come utilizzare NEG autonomi con un bilanciatore del carico HTTP esterno su GKE.
Devi creare i seguenti oggetti:
- Un deployment che crea e gestisce i pod.
- Un servizio che crea un NEG.
- Un bilanciatore del carico creato con l'API Compute Engine. È diverso dall'utilizzo dei NEG con Ingress, nel qual caso Ingress crea e configura un bilanciatore del carico per te. Con i NEG autonomi è necessario associare il NEG e il servizio di backend per connettere i pod al bilanciatore del carico. Il bilanciatore del carico è costituito da diversi componenti, mostrati nel seguente diagramma:
Crea un cluster nativo di VPC
I cluster Autopilot sono nativi di VPC per impostazione predefinita, quindi puoi passare a Eseguire il deployment di un carico di lavoro.
Per i cluster standard, crea un cluster nativo di VPC nella zona us-central1-a
:
gcloud container clusters create neg-demo-cluster \
--create-subnetwork="" \
--network=default \
--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 nome host del server delle applicazioni, il nome del pod su cui è in esecuzione il server.
Ti consigliamo di utilizzare carichi di lavoro che utilizzano il feedback sull'idoneità dei pod.
Utilizzo del 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
Utilizzo del ritardo impostato come hardcoded
apiVersion: apps/v1 kind: Deployment metadata: labels: run: neg-demo-app # Label for the Deployment name: neg-demo-app # Name of Deployment spec: minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready replicas: 3 selector: matchLabels: run: neg-demo-app template: # Pod template metadata: labels: run: neg-demo-app # Labels Pods from this Deployment spec: # Pod specification; each Pod created by this Deployment has this specification containers: - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods name: hostname
Salva il manifest come neg-demo-app.yaml
, quindi crea il deployment eseguendo questo comando:
kubectl apply -f neg-demo-app.yaml
Crea un servizio
Il seguente manifest specifica un servizio in cui:
- Qualsiasi pod con l'etichetta
run: neg-demo-app
è membro di questo servizio. - Il servizio ha un campo ServicePort con la porta 80.
- L'annotazione
cloud.google.com/neg
specifica che la porta 80 sarà associata a un NEG. Il campo facoltativoname
specifica che il NEG verrà denominatoNEG_NAME
. Se il camponame
viene omesso, verrà generato automaticamente un nome univoco. Per informazioni dettagliate, consulta l'articolo sulla 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 sua regione.
Salva il manifest come neg-demo-svc.yaml
, quindi crea il servizio eseguendo questo comando:
kubectl apply -f neg-demo-svc.yaml
Un NEG viene creato entro pochi minuti dalla creazione del servizio.
Tipi di servizi
Sebbene in questo esempio venga utilizzato un servizio ClusterIP
, tutti e cinque i tipi di servizi supportano NEG autonomi. Ti 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.
Specifica di un nome
La specifica di un nome NEG personalizzato semplifica la configurazione del bilanciatore del carico, perché conosci già il nome e le zone dei NEG. I nomi NEG personalizzati devono soddisfare i seguenti requisiti:
- Essere univoca per la zona del cluster per i cluster di zona o univoco per la regione per i cluster a livello di regione.
- Non deve corrispondere al nome di un NEG esistente che non è stato creato dal controller NEG GKE.
- Non deve contenere trattini bassi.
Utilizza il campo name
nell'annotazione cloud.google.com/neg
del servizio per specificare un nome NEG:
cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'
Sostituisci NEG_NAME
con il nome del NEG. Il nome del NEG
deve essere univoco nella sua regione.
Utilizzo di un nome generato automaticamente
I nomi NEG generati automaticamente sono garantiti che siano 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ò rimanere in ascolto su più di una porta. Per definizione, i NEG hanno solo un indirizzo IP e una porta. Ciò significa che se specifichi un servizio con più porte, verrà creato un NEG per ogni porta.
Il formato dell'annotazione cloud.google.com/neg
è:
cloud.google.com/neg: '{
"exposed_ports":{
"SERVICE_PORT_1":{},
"SERVICE_PORT_2":{},
"SERVICE_PORT_3":{},
...
}
}'
In questo esempio, ogni istanza di SERVICE_PORT_N
è un
numero di porta distinto che fa riferimento alle porte di servizio esistenti del servizio. Per ogni porta di servizio elencata, il controller NEG crea un NEG in ogni zona occupata dal cluster.
Recuperare gli stati 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 nel mapping di network-endpoint-groups
è una porta di servizio
(come SERVICE_PORT_1
) e il nome dei NEG gestiti corrispondenti (come NEG_NAME_1
). L'elenco zones
contiene ogni zona (come ZONE_1
) che contiene un NEG.
L'output è simile al seguente:
apiVersion: v1
kind: Service
metadata:
annotations:
cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
cloud.google.com/neg-status: '{"network_endpoint_groups":{"80":"k8s1-cca197ad-default-neg-demo-app-80-4db81e02"},"zones":["ZONE_1", "ZONE_2"]}'
labels:
run: neg-demo-app
name: neg-demo-app
namespace: default
selfLink: /api/v1/namespaces/default/services/neg-demo-app
...
spec:
clusterIP: 10.0.14.252
ports:
- port: 80
protocol: TCP
targetPort: 9376
selector:
run: neg-demo-app
sessionAffinity: None
status:
loadBalancer: {}
In questo esempio, l'annotazione mostra che la porta del servizio 80 è esposta ai NEG denominati k8s1-cca197ad-default-neg-demo-app-80-4db81e02
.
Convalida creazione NEG
Un NEG viene creato entro pochi minuti dalla creazione del servizio. Se esistono pod che corrispondono all'etichetta specificata nel manifest del servizio, al momento della creazione il NEG conterrà gli IP dei pod.
Esistono due modi per verificare che il NEG sia stato creato e configurato correttamente. In GKE 1.18.6-gke.6400 e versioni successive, una risorsa personalizzata ServiceNetworkEndpointGroup
archivia le informazioni sullo stato dei NEG creati dal controller di servizio. Nelle versioni precedenti, devi controllare direttamente i NEG.
La risorsa ServiceNetworkEndpointGroup
Elenca i NEG in un cluster recuperando tutte le risorse ServiceNetworkEndpointGroup
:
kubectl get svcneg
Osserva lo stato di un NEG controllando lo stato della risorsa ServiceNetworkEndpointGroup
:
kubectl get svcneg NEG_NAME -o yaml
Sostituisci NEG_NAME
con il nome del singolo NEG che vuoi controllare.
L'output di questo comando include una sezione di stato che potrebbe contenere messaggi di errore. Alcuni errori vengono segnalati come evento di servizio. Puoi trovare ulteriori dettagli eseguendo una query sull'oggetto Service:
kubectl describe service SERVICE_NAME
Sostituisci SERVICE_NAME
con il nome del servizio pertinente.
Per verificare che il controller NEG stia sincronizzando correttamente il NEG, controlla se nel campo dello stato della risorsa ServiceNetworkEndpointGroup
è presente una condizione con type:Synced
. L'ora della sincronizzazione più recente è nel campo status.lastSyncTime
.
Le risorse ServiceNetworkEndpointGroup
esistono solo in GKE versione 1.18 e successive.
Ispezione diretta dei NEG
Verifica che il NEG esista elencando i NEG nel tuo progetto Google Cloud e controllando se è presente un NEG che corrisponda al servizio creato. Il nome del NEG ha il seguente formato:
k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH
Utilizza il seguente comando per elencare i NEG:
gcloud compute network-endpoint-groups list
L'output è simile al seguente:
NAME LOCATION ENDPOINT_TYPE SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f ZONE_NAME GCE_VM_IP_PORT 3
Questo output mostra che il 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 cui vuoi visualizzare i singoli endpoint.
L'output mostra tre endpoint, ciascuno dei quali ha un indirizzo IP e una porta del pod:
INSTANCE IP_ADDRESS PORT
gke-cluster-3-default-pool-4cc71a15-qlpf 10.12.1.43 9376
gke-cluster-3-default-pool-4cc71a15-qlpf 10.12.1.44 9376
gke-cluster-3-default-pool-4cc71a15-w9nk 10.12.2.26 9376
Collegamento di un bilanciatore del carico delle applicazioni esterno a NEG autonomi
Puoi utilizzare i NEG come backend per un bilanciatore del carico delle applicazioni esterno utilizzando l'API Compute Engine.
Creare una regola firewall. I bilanciatori del carico devono accedere agli endpoint dei 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 nodi, GKE genera automaticamente tag per te. Puoi cercare questi tag generati eseguendo questo comando:
gcloud compute instances describe INSTANCE_NAME
Sostituisci
INSTANCE_NAME
con il nome dell'istanza VM di Compute Engine dell'host che esegue il nodo GKE. Ad esempio, l'output nella sezione precedente mostra i nomi delle istanze nella colonnaINSTANCE
per i nodi GKE. Per i cluster standard, puoi anche eseguiregcloud compute instances list
per elencare tutte le istanze del tuo progetto.Crea un indirizzo IP virtuale globale per il bilanciatore del carico:
gcloud compute addresses create hostname-server-vip \ --ip-version=IPV4 \ --global
Creare un controllo di integrità. Viene utilizzato dal bilanciatore del carico per rilevare l'attività dei singoli endpoint all'interno del NEG.
gcloud compute health-checks create http http-basic-check \ --use-serving-port
Crea un servizio di backend che specifichi che si tratta di un bilanciatore del carico delle applicazioni esterno globale:
gcloud compute backend-services create my-bes \ --protocol HTTP \ --health-checks http-basic-check \ --global
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
Crea una regola di forwarding. Questo è ciò 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
- L'URL mappa il 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 costituiscono un bilanciatore del carico. Nel passaggio successivo aggiungerai backend al bilanciatore del carico.
Uno dei vantaggi dei NEG autonomi qui illustrati è 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 può essere 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 tuo gruppo di endpoint di rete. Per trovare questo valore, segui le istruzioni riportate di seguito.
Utilizza questo comando per ottenere il nome e la posizione del NEG:
gcloud compute network-endpoint-groups list
L'output è simile al seguente:
NAME LOCATION ENDPOINT_TYPE SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f ZONE_NAME GCE_VM_IP_PORT 3
In questo output di esempio, il nome del NEG è k8s1-70aa83a6-default-my-service-80-c9710a6f
.
È possibile aggiungere più NEG allo stesso servizio di backend. I servizi di backend globali come my-bes
possono avere backend NEG in regioni diverse, mentre i servizi di backend regionali devono avere backend in un'unica 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 i report siano integri.
- 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 di endpoint di rete e che i singoli endpoint siano integri.
Utilizza questo comando per verificare che il servizio di backend sia associato al controllo di integrità e al gruppo di endpoint di rete:
gcloud compute backend-services describe my-bes --global
L'output è simile al seguente:
backends:
- balancingMode: RATE
capacityScaler: 1.0
group: ... /networkEndpointGroups/k8s1-70aa83a6-default-my-service-80-c9710a6f
...
healthChecks:
- ... /healthChecks/http-basic-check
...
name: my-bes
...
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
Accedere all'applicazione
Accedi all'applicazione tramite l'indirizzo IP del bilanciatore del carico per verificare che tutto funzioni.
Per prima cosa, 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. Poi, 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
deve essere neg-demo-app
.
Collegamento di un bilanciatore del carico delle applicazioni interno a NEG autonomi
Puoi utilizzare i NEG per configurare un bilanciatore del carico delle applicazioni interno per i servizi in esecuzione in pod GKE autonomi.
Configurazione della subnet solo proxy
La subnet solo proxy è per tutti gli Application Load Balancer interni regionali nella regione del bilanciatore del carico.
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=COMPUTE_REGION \
--network=lb-network \
--range=10.129.0.0/23
Sostituisci COMPUTE_REGION
con
Compute Engine per la subnet.
API
Crea la subnet solo proxy con il metodo subnetworks.insert
.
POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks
{
"name": "proxy-only-subnet",
"ipCidrRange": "10.129.0.0/23",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"region": "projects/PROJECT_ID/regions/COMPUTE_REGION",
"purpose": "REGIONAL_MANAGED_PROXY",
"role": "ACTIVE"
}
Sostituisci quanto segue:
PROJECT_ID
: il tuo ID progetto.COMPUTE_REGION
: Compute Engine per la subnet.
Configurazione delle regole del firewall
In questo esempio vengono utilizzate le seguenti regole firewall:
fw-allow-ssh
: una regola in entrata, applicabile alle istanze con bilanciamento del carico, che consente la connettività SSH in entrata sulla porta TCP 22 da qualsiasi indirizzo. Puoi scegliere un intervallo IP di origine più restrittivo per questa regola. Ad esempio, puoi specificare solo gli intervalli IP del sistema da cui avvii le sessioni SSH. Questo esempio utilizza il tag di destinazioneallow-ssh
per identificare le VM a cui si applica la regola firewall.fw-allow-health-check
: una regola in entrata, applicabile alle istanze con bilanciamento del carico, che consente tutto il traffico TCP dai sistemi di controllo di integrità di Google Cloud (in130.211.0.0/22
e35.191.0.0/16
). Questo esempio utilizza il tag di destinazioneload-balanced-backend
per identificare le istanze a cui deve essere applicato.fw-allow-proxies
: una regola in entrata, applicabile alle istanze con bilanciamento del carico, che consente il traffico TCP sulla porta9376
dai proxy gestiti del bilanciatore del carico HTTP(S) interno. In questo esempio viene utilizzato il tag di destinazioneload-balanced-backend
per identificare le istanze a cui deve essere applicato.
Senza queste regole firewall, la regola predefinita nega il traffico in entrata blocca il traffico in entrata verso le istanze di backend.
Console
Vai alla pagina Criteri firewall nella console Google Cloud.
Fai clic su Crea regola firewall
per creare la regola che consente le connessioni SSH in entrata:- Nome:
fw-allow-ssh
- Rete:
lb-network
- Direzione del traffico: in entrata
- Azione in caso di corrispondenza: consenti
- Target: Tag di destinazione specificati
- Tag di destinazione:
allow-ssh
- Filtro di origine:
IPv4 ranges
- Intervalli IPv4 di origine:
0.0.0.0/0
- Protocolli e porte:
- Seleziona Protocolli e porte specificati.
- Seleziona la casella di controllo
tcp
e specifica la porta22
.
- Nome:
Fai clic su Crea.
Fai di nuovo clic su Crea regola firewall
per creare la regola e consentire i controlli di integrità di Google Cloud:- Nome:
fw-allow-health-check
- Rete:
lb-network
- Direzione del traffico: in entrata
- Azione in caso di corrispondenza: consenti
- Target: Tag di destinazione specificati
- Tag di destinazione:
load-balanced-backend
- Filtro di origine:
IPv4 ranges
- Intervalli IPv4 di origine:
130.211.0.0/22
e35.191.0.0/16
- Protocolli e porte:
- Seleziona Protocolli e porte specificati
- Seleziona la casella di controllo
tcp
e specifica la porta80
. Come best practice, limita questa regola solo ai protocolli e alle porte corrispondenti a quelli utilizzati dal controllo di integrità. Se utilizzitcp:80
per il protocollo e la porta, Google Cloud può contattare le tue VM utilizzando HTTP sulla porta 80, ma non può contattarle tramite HTTPS sulla porta 443.
- Nome:
Fai clic su Crea.
Fai di nuovo clic su Crea regola firewall
per creare la regola e 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 di destinazione specificati
- Tag di destinazione:
load-balanced-backend
- Filtro di origine:
IPv4 ranges
- Intervalli IPv4 di origine:
10.129.0.0/23
- Protocolli e porte:
- Seleziona Protocolli e porte specificati.
- Seleziona la casella di controllo
tcp
e specifica la porta9376
.
- Nome:
Fai clic su Crea.
gcloud
Crea la regola firewall
fw-allow-ssh
per consentire la connettività SSH alle VM con il tag di reteallow-ssh
. Se omettisource-ranges
, Google Cloud interpreta la regola in modo che indichi qualsiasi origine.gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
Crea la regola
fw-allow-health-check
per consentire i controlli di integrità di Google Cloud. Questo esempio consente tutto il traffico TCP dai prober del controllo di integrità. Tuttavia, puoi configurare un insieme più ristretto di porte 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
Crea la regola
fw-allow-proxies
per consentire ai proxy del bilanciatore del carico HTTP(S) interno di connettersi ai tuoi backend.gcloud compute firewall-rules create fw-allow-proxies \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=10.129.0.0/23 \ --target-tags=load-balanced-backend \ --rules=tcp:9376
API
Crea la regola firewall fw-allow-ssh
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 va a buon fine.
Console
Seleziona un tipo di bilanciatore del carico
- Vai alla pagina Crea un bilanciatore del carico nella console Google Cloud. Vai a Creare un bilanciatore del carico
- In Bilanciamento del carico HTTP(S), fai clic su Avvia configurazione.
- Seleziona Solo tra le mie VM. Questa impostazione indica che il bilanciatore del carico è interno.
- Fai clic su Continua.
prepara il bilanciatore del carico
- Come Nome del bilanciatore del carico, inserisci
l7-ilb-gke-map
. - Per Regione, seleziona la regione in cui hai creato la subnet.
- In corrispondenza di Rete, seleziona
lb-network
.
Prenota una subnet solo proxy
Prenota una subnet solo proxy:
- Fai clic su Prenota una subnet.
- In Nome, inserisci
proxy-only-subnet
. - In Intervallo di indirizzi IP, inserisci
10.129.0.0/23
. - Fai clic su Aggiungi.
Configura il servizio di backend
- Fai clic su Configurazione backend.
- Dal menu Crea o seleziona servizi di backend, scegli Crea un servizio di backend.
- Imposta il Nome del servizio di backend su
l7-ilb-gke-backend-service
. - In Tipo di backend, seleziona Gruppi di endpoint di rete.
- Nella scheda Nuovo backend della sezione Backend:
- Impostare il Gruppo di endpoint di rete sul NEG creato da GKE. Per ottenere il nome NEG, consulta Convalidare la creazione di NEG.
- Per Numero massimo di RPS, specifica una frequenza massima di
5
RPS per endpoint. Google Cloud supererà questo limite massimo, se necessario. - Fai clic su Fine.
- Nell'elenco a discesa Controllo di integrità, seleziona Crea un controllo di integrità, quindi specifica i seguenti parametri:
- Nome:
l7-ilb-gke-basic-check
- Protocollo: HTTP
- Specifica della porta: Porta per la pubblicazione
- Fai clic su Save and Continue.
- Nome:
- Fai clic su Crea.
Configura la mappa URL
- 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 percorso senza corrispondenza.
Configura il frontend
Fai clic su Configurazione frontend ed esegui questi passaggi:
Per HTTP:
- Fai clic su Configurazione frontend.
- Fai clic su Aggiungi IP e porta frontend.
- Imposta il campo Nome su l7-ilb-gke-forwarding-rule.
- Imposta Protocollo su HTTP.
- Imposta la Subnet su backend-subnet.
- In IP interno, seleziona Prenota un indirizzo IP interno statico.
- Nel riquadro visualizzato, fornisci i seguenti dettagli:
- Nome:
l7-ilb-gke-ip
- Nella sezione Indirizzo IP statico, seleziona Fammi scegliere.
- Nella sezione Indirizzo IP personalizzato, inserisci
10.1.2.199
. - Fai clic su Prenota.
- Nome:
- Imposta la Porta su
80
. - 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. Vedi Certificati SSL per informazioni su come creare risorse dei certificati SSL. I certificati gestiti da Google non sono supportati con i bilanciatori del carico HTTP(S) interni.
- Fai clic su Configurazione frontend.
- Fai clic su Aggiungi IP e porta frontend.
- Nel campo Nome, inserisci
l7-ilb-gke-forwarding-rule
. - Nel campo Protocollo, seleziona
HTTPS (includes HTTP/2)
. - Imposta la Subnet su backend-subnet.
- In IP interno, seleziona Prenota un indirizzo IP interno statico.
- Nel riquadro visualizzato, fornisci i seguenti dettagli:
- Nome:
l7-ilb-gke-ip
- Nella sezione Indirizzo IP statico, seleziona Fammi scegliere.
- Nella sezione Indirizzo IP personalizzato, inserisci
10.1.2.199
. - Fai clic su Prenota.
- Nome:
- Assicurati che la Porta sia impostata su
443
, per consentire il traffico HTTPS. - Fai clic sull'elenco a discesa Certificato.
- Se disponi già di una risorsa del certificato SSL autogestita che vuoi utilizzare come certificato SSL principale, selezionala dal menu a discesa.
- Altrimenti, seleziona Crea un nuovo certificato.
- Inserisci il Nome
l7-ilb-cert
. - Nei campi appropriati, carica i file in formato PEM:
- Certificato di chiave pubblica
- Catena di certificati
- Chiave privata
- Fai clic su Crea.
- Inserisci il Nome
- Per aggiungere risorse di certificato oltre alla risorsa del certificato SSL principale:
- Fai clic su Aggiungi certificato.
- Seleziona un certificato dall'elenco Certificati oppure fai clic su Crea un nuovo certificato e segui le istruzioni.
- Fai clic su Fine.
Completare la configurazione
Fai clic su Crea.
gcloud
Definisci il controllo di integrità HTTP con il comando gcloud compute health-checks create http.
gcloud compute health-checks create http l7-ilb-gke-basic-check \ --region=COMPUTE_REGION \ --use-serving-port
Definisci il servizio di backend con il comando gcloud compute backend-services create.
gcloud compute backend-services create l7-ilb-gke-backend-service \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=HTTP \ --health-checks=l7-ilb-gke-basic-check \ --health-checks-region=COMPUTE_REGION \ --region=COMPUTE_REGION
Imposta la variabile
DEPLOYMENT_NAME
:export DEPLOYMENT_NAME=NEG_NAME
Sostituisci
NEG_NAME
con il nome del NEG.Aggiungi backend NEG al servizio di backend con il comando gcloud compute backend-services add-backend.
gcloud compute backend-services add-backend l7-ilb-gke-backend-service \ --network-endpoint-group=$DEPLOYMENT_NAME \ --network-endpoint-group-zone=COMPUTE_ZONE-b \ --region=COMPUTE_REGION \ --balancing-mode=RATE \ --max-rate-per-endpoint=5
Crea la mappa degli URL con il comando gcloud compute url-mapscreate.
gcloud compute url-maps create l7-ilb-gke-map \ --default-service=l7-ilb-gke-backend-service \ --region=COMPUTE_REGION
Crea il proxy di destinazione.
Per HTTP:
Usa il comando gcloud compute target-http-proxiescreate.
gcloud compute target-http-proxies create l7-ilb-gke-proxy \ --url-map=l7-ilb-gke-map \ --url-map-region=COMPUTE_REGION \ --region=COMPUTE_REGION
Per HTTPS:
Vedi Certificati SSL per informazioni su come creare risorse dei 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=COMPUTE_REGION
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=COMPUTE_REGION \ --ssl-certificates=l7-ilb-cert
Crea la regola di forwarding.
Per le reti personalizzate, devi fare riferimento alla subnet nella regola di forwarding. Tieni presente che si tratta della subnet della VM, non del proxy.
Per HTTP:
Utilizza il comando gcloud compute forwarding-rules create con i flag corretti.
gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.199 \ --ports=80 \ --region=COMPUTE_REGION \ --target-http-proxy=l7-ilb-gke-proxy \ --target-http-proxy-region=COMPUTE_REGION
Per HTTPS:
Utilizza il comando gcloud compute forwarding-rules create con i flag corretti.
gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.199 \ --ports=443 \ --region=COMPUTE_REGION \ --target-https-proxy=l7-ilb-gke-proxy \ --target-https-proxy-region=COMPUTE_REGION
API
Crea il controllo di integrità inviando una richiesta POST
al metodo
regionHealthChecks.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks
{
"name": "l7-ilb-gke-basic-check",
"type": "HTTP",
"httpHealthCheck": {
"portSpecification": "USE_SERVING_PORT"
}
}
Sostituisci PROJECT_ID
con l'ID progetto.
Crea il servizio di backend a livello di regione inviando una richiesta POST
al metodo
regionBackendServices.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices
{
"name": "l7-ilb-gke-backend-service",
"backends": [
{
"group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/networkEndpointGroups/NEG_NAME",
"balancingMode": "RATE",
"maxRatePerEndpoint": 5
}
],
"healthChecks": [
"projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks/l7-ilb-gke-basic-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}
Sostituisci quanto segue:
PROJECT_ID
: l'ID progetto.NEG_NAME
: il nome del NEG.
Crea la mappa URL inviando una richiesta POST
al metodo
regionUrlMaps.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/urlMaps
{
"name": "l7-ilb-gke-map",
"defaultService": "projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices/l7-ilb-gke-backend-service"
}
Sostituisci PROJECT_ID
con l'ID progetto.
Crea il proxy HTTP di destinazione inviando una richiesta POST
al metodo regionTargetHttpProxies.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxy
{
"name": "l7-ilb-gke-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-gke-map",
"region": "COMPUTE_REGION"
}
Sostituisci PROJECT_ID
con l'ID progetto.
Crea la regola di forwarding effettuando una richiesta POST
al metodo forwardingRules.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/forwardingRules
{
"name": "l7-ilb-gke-forwarding-rule",
"IPAddress": "10.1.2.199",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxies/l7-ilb-gke-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks/backend-subnet",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"networkTier": "PREMIUM",
}
Sostituisci PROJECT_ID
con l'ID progetto.
Test
Crea un'istanza VM nella zona per verificare 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 del client per verificare che i servizi HTTP(S) nei backend siano raggiungibili utilizzando l'indirizzo IP della regola di forwarding del bilanciatore del carico delle applicazioni interno e che il traffico venga bilanciato del carico tra gli endpoint nel NEG.
Connettiti a ciascuna istanza client tramite SSH:
gcloud compute ssh l7-ilb-client \
--zone=COMPUTE_ZONE-b
Verifica che l'IP fornisca il nome host:
curl 10.1.2.199
Per il test su HTTPS, esegui questo comando:
curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
Il flag -k
fa sì che curl
ignori la convalida del certificato.
Eseguire 100 richieste e verificare 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 carichi di lavoro misti Kubernetes e non Kubernetes. Questo potrebbe far parte di una migrazione dalle VM ai container o di un'architettura permanente che beneficia di un bilanciatore del carico condiviso. A tal fine, si possono creare bilanciatori del carico che hanno come target diversi tipi di backend, inclusi NEG autonomi.
VM e container nello stesso servizio di backend
Questo esempio mostra come creare un NEG che punta a una VM esistente che esegue un carico di lavoro e come aggiungere questo NEG come altro backend di un backendService
esistente.
In questo modo, un singolo bilanciatore del carico bilancia le VM e i container GKE.
Questo esempio estende l'esempio precedente in cui viene utilizzato un bilanciatore del carico HTTP esterno.
Poiché tutti gli endpoint sono raggruppati dallo stesso backendService
, gli endpoint della VM e del container sono considerati allo stesso servizio. Ciò significa che la corrispondenza dell'host o del percorso tratterà tutti i backend in modo identico in base alle regole della mappa URL.
Quando utilizzi un NEG come backend per un servizio di backend, anche tutti gli altri backend in quel servizio di backend devono essere NEG. Non puoi usare gruppi di istanze e NEG come backend nello stesso servizio di backend. Inoltre, i container e le VM non possono esistere come endpoint nello stesso NEG, quindi devono essere sempre configurati con NEG separati.
Esegui il deployment di una VM in Compute Engine con questo comando:
gcloud compute instances create vm1 \ --zone=COMPUTE_ZONE \ --network=NETWORK \ --subnet=SUBNET \ --image-project=cos-cloud \ --image-family=cos-stable --tags=vm-neg-tag
Sostituisci quanto segue:
COMPUTE_ZONE
: il nome della zona.NETWORK
: il nome della rete.SUBNET
: il nome della subnet associata alla rete.
Esegui il deployment di un'applicazione sulla VM:
gcloud compute ssh vm1 \ --zone=COMPUTE_ZONE \ --command="docker run -d --rm --network=host registry.k8s.io/serve_hostname:v1.4 && sudo iptables -P INPUT ACCEPT"
Questo comando esegue il deployment sulla VM della stessa applicazione di esempio utilizzata nell'esempio precedente. Per semplicità, l'applicazione viene eseguita come container Docker, ma non è essenziale. Il comando
iptables
è necessario per consentire l'accesso firewall al container in esecuzione.Convalida che l'applicazione sia in esecuzione sulla porta 9376 e segnala che è in esecuzione su vm1:
gcloud compute ssh vm1 \ --zone=COMPUTE_ZONE \ --command="curl -s localhost:9376"
Il server dovrebbe rispondere con
vm1
.Crea un NEG da utilizzare con l'endpoint VM. I container e le VM possono essere entrambi endpoint NEG, ma un singolo NEG non può avere endpoint VM e container.
gcloud compute network-endpoint-groups create vm-neg \ --subnet=SUBNET \ --zone=COMPUTE_ZONE
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.Conferma che il NEG abbia l'endpoint VM:
gcloud compute network-endpoint-groups list-network-endpoints vm-neg \ --zone COMPUTE_ZONE
Collega il NEG al servizio di backend utilizzando lo stesso comando utilizzato per aggiungere il backend di un 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
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
Verifica che il bilanciatore del carico inoltri il traffico sia al nuovo backend vm1 che al backend del container esistente inviando traffico di prova:
for i in `seq 1 100`; do curl ${VIP};echo; done
Dovresti vedere le risposte degli endpoint container (
neg-demo-app
) e VM (vm1
).
VM e container per servizi di backend diversi
Questo esempio mostra come creare un NEG che punta a una VM esistente che esegue un carico di lavoro e come aggiungere questo NEG come backend a un nuovo backendService
. Questo è utile nei casi in cui i container e le VM sono servizi diversi ma devono condividere lo stesso bilanciatore del carico L7, ad esempio se i servizi condividono lo stesso indirizzo IP o nome di dominio.
Questo esempio estende l'esempio precedente con un backend VM nello stesso servizio di backend del container. In questo esempio viene riutilizzata la VM.
Poiché gli endpoint del container e delle VM sono raggruppati in servizi di backend separati, sono considerati servizi diversi. Ciò significa che la mappa URL corrisponderà ai backend e indirizzerà il traffico alla VM o al container in base al nome host.
Il seguente diagramma mostra come un singolo indirizzo IP virtuale corrisponde 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:
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
Collega il NEG per la VM,
vm-neg
, al servizio 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
Aggiungi una regola host alla mappa URL per indirizzare le richieste per l'host
container.example.com
al servizio di backend del container:gcloud compute url-maps add-path-matcher web-map \ --path-matcher-name=container-path --default-service=my-bes \ --new-hosts=container.example.com --global
Aggiungi un'altra regola host della mappa URL per indirizzare le richieste per l'host
vm.example.com
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
Verifica che il bilanciatore del carico invii il traffico al backend della VM in base al percorso richiesto:
curl -H "HOST:vm.example.com" VIRTUAL_IP
Sostituisci
VIRTUAL_IP
con l'indirizzo IP virtuale.
Limitazioni dei NEG autonomi
- Gli errori di convalida delle annotazioni sono esposti all'utente tramite gli eventi Kubernetes.
- Le limitazioni dei NEG si applicano anche ai NEG autonomi.
- I NEG autonomi non funzionano con le reti legacy.
- I NEG autonomi possono essere utilizzati solo con servizi di rete compatibili, tra cui Traffic Director e i tipi di bilanciatori del carico compatibili.
Prezzi
Per i dettagli sui prezzi del bilanciatore del carico, consulta la sezione relativa al bilanciamento del carico nella pagina dei prezzi. Non sono previsti costi aggiuntivi per i NEG.
Risoluzione dei problemi
Questa sezione fornisce la procedura di risoluzione dei problemi comuni che potresti riscontrare con i NEG autonomi.
Nessun NEG autonomo configurato
Sintomo:non viene creato nessun NEG.
Potenziale risoluzione:
- Controlla gli eventi associati al servizio e cerca i messaggi di errore.
- Verifica che l'annotazione NEG autonoma sia JSON nel formato corretto e che le porte esposte corrispondano alle porte esistenti nella specifica del servizio.
- Verifica l'annotazione dello stato NEG e controlla se le porte di servizio previste hanno NEG corrispondenti.
- Verifica che i NEG siano stati creati nelle zone previste,
con il comando
gcloud compute network-endpoint-groups list
. - Se utilizzi GKE versione 1.18 o successiva, verifica se la risorsa
svcneg
per il servizio esiste. In caso affermativo, controlla la condizioneInitialized
per verificare se ci sono informazioni sull'errore. - Se utilizzi nomi NEG personalizzati, assicurati che ogni nome NEG sia univoco nella relativa regione.
Il traffico non raggiunge gli endpoint
Sintomo:errori 502 o connessioni rifiutate.
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 riesce ancora a raggiungere gli endpoint, con conseguente codice di errore 502 per HTTP(S) o connessioni rifiutate per i bilanciatori del carico TCP/SSL, 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
e35.191.0.0/16
. - Verifica che gli endpoint siano integri utilizzando Google Cloud CLI o chiamando l'API
getHealth
subackendService
o l'API listEndpoints sul NEG con il parametro showHealth impostato suSHOW
.
- Verifica che le regole firewall consentano il traffico TCP in entrata verso i tuoi endpoint dai seguenti intervalli:
Implementazione bloccata
Sintomo: l'implementazione di un deployment aggiornato si blocca e il numero di repliche aggiornate non corrisponde al numero di repliche scelto.
Potenziale risoluzione:
I controlli di integrità del deployment non sono riusciti. L'immagine container potrebbe essere errata o il controllo di integrità potrebbe essere configurato in modo errato. La sostituzione in sequenza dei pod attende che il pod appena avviato non superi il limite di idoneità del pod. Ciò si verifica solo se il pod risponde ai controlli di integrità del bilanciatore del carico. Se il pod non risponde o se il controllo di integrità non è configurato correttamente, non è possibile soddisfare le condizioni della porta di idoneità e l'implementazione non può continuare.
Se utilizzi kubectl 1.13 o versioni successive, puoi controllare lo stato delle porte di idoneità di un pod con il comando seguente:
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 PRONTO potrebbe avere un gateway di idoneità non riuscito. Per verificarlo, utilizza il seguente comando:
kubectl get my-pod -o yaml
Le porte 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.
NEG non è garbage collection
Sintomo:esiste ancora un NEG che avrebbe dovuto essere eliminato.
Potenziale risoluzione:
- Il NEG non è una garbage collection se viene fatto riferimento al NEG da un servizio di backend. Per maggiori dettagli, consulta Prevenire i NEG divulgati.
- Se utilizzi la versione 1.18 o successiva, puoi verificare la presenza di eventi nella risorsa
ServiceNetworkEndpointGroup
utilizzando la procedura di negazione del servizio. - Verifica se il NEG è ancora necessario per un servizio. Controlla la risorsa
svcneg
per il servizio corrispondente al NEG e verifica se esiste un'annotazione servizio.
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 la presenza di eventuali errori che si sono verificati nella sincronizzazione più recente.
Se utilizzi GKE 1.19.9 o versioni successive, verifica se esiste un NEG il cui nome e la cui zona corrispondono al nome e alla zona del NEG che il controller NEG GKE deve creare. Ad esempio, un NEG con il nome che deve essere utilizzato dal controller NEG potrebbe essere stato creato utilizzando gcloud CLI o la console Google Cloud nella zona del cluster (o in una delle zone del cluster). In questo caso, devi eliminare il NEG esistente prima che il controller NEG possa sincronizzare i propri endpoint. La creazione e l'appartenenza di NEG autonomi sono progettate per essere gestite dal controller NEG.
Passaggi successivi
- Panoramica dei gruppi di endpoint di rete a livello di zona
- Servizi di backend
- Creazione di controlli di integrità
- Utilizzo dei proxy di destinazione
- Utilizzare le regole di forwarding