Cosa sapere quando si utilizza più di un'interfaccia di rete in Google Cloud
Il Load Balancer di Google Cloud, con un unico IP globale e una pletora di servizi di backend (VM, pod Kubernetes, istanze di Cloud Functions, ecc.), è oggi il modo più diffuso per esporre la propria applicazione sul World Wide Web. Soprattutto se tutto ciò che serve è il caro vecchio HTTP(S). Un solo indirizzo IP per domarli tutti, di solito, è più che sufficiente.
Ogni tanto, però, capita di trovarsi davanti a una configurazione particolare, o se vogliamo tradizionale, in cui occorre che una VM accetti traffico su più IP. Nella maggior parte dei casi tramite protocollo TCP, anche se il primo esempio che viene in mente è il classico virtual hosting HTTP basato su IP.
In sostanza, la domanda è: "Come posso avere una VM su GCP con più IP?". Una ricerca sul web vi indirizzerà quasi sicuramente verso la strada della "VM GCP con più interfacce di rete". L'approccio funziona come descritto qui: associare un IP esterno a ciascuna Network Interface Card (NIC) della VM. Ci sono però diversi limiti da tenere a mente:
- Ogni Network Interface Card (NIC) richiede una rete VPC separata. Non è un problema di per sé, ma comporta sicuramente un po' di lavoro DevOps: non basta creare una VPC e definirne gli intervalli IP senza sovrapposizioni, occorre anche creare regole di firewall per ciascuna VPC.
- Si possono avere fino a 8 NIC per VM. Possono bastare oppure no, dipende dalle esigenze.
- NON è possibile modificare il numero di NIC della VM dopo la sua creazione. Se partite con 5 IP e in seguito volete aggiungerne un altro, dovrete ricreare la VM.
- Il numero di vCPU della VM deve essere almeno pari al numero di NIC. È qui che il conto può salire in fretta. 1–2 vCPU possono bastare per gestire tutto il traffico, ma dovrete comunque pagare macchine da 8 vCPU se volete 8 IP.
Posso condividere con voi un piccolo trucco: create una VM con 8 vCPU e 8 NIC, poi fermatela, riducete il tipo di macchina e infine riavviatela. Procedete con cautela, perché GCP potrebbe chiudere questa scappatoia in qualsiasi momento.
Forwarding rules
La strada più economica e lineare passa per le forwarding rules. Tutto il networking di GCP è software-defined, quindi la vostra VM non può semplicemente prendere degli IP e annunciarli tramite risposte ARP: di ARP, in realtà, ce n'è ben poco. È tutto localhost, oppure il gateway predefinito per il resto. Persino il traffico verso la VM "vicina" nella stessa VPC passa dal gateway predefinito.
me@my-vm:~$ ip route showdefault via 10.128.0.1 dev ens410.128.0.1 dev ens4 scope linkBisogna quindi "spiegare" a GCP che vogliamo più IP per accettare traffico, e il modo per farlo sono le forwarding rules.
Una forwarding rule in GCP è estremamente flessibile. Può ascoltare su qualsiasi combinazione di IP, porte, protocolli, host e percorsi HTTP, e inoltrare il traffico corrispondente a un target che può essere una VM, un pool di VM, un bucket di Cloud Storage, una Cloud Function, un servizio Kubernetes, ecc.
Le forwarding rules hanno un costo. Ne riparleremo più avanti.
Nel nostro caso ci serve solo la forma più semplice: ascoltare su tcp:indirizzo:porta e inoltrare tutto il traffico a una singola istanza target.
Forwarding rules nella loro forma più semplice
La documentazione GCP propone un articolo ottimo e molto dettagliato su come configurare il tutto. Chiamano questo approccio Protocol Forwarding. Nella console UI di GCP non c'è praticamente alcun supporto. Se volete configurarlo in una regione diversa da quella predefinita, dovete prestare particolare attenzione a indicare le regioni e le zone corrette in ciascun comando (fatemi sapere nei commenti se vi interessano maggiori dettagli a riguardo).
Per fortuna, c'è un modo più semplice di farlo dalla UI.
Iniziamo allocando alcuni IP:
NOTA: assicuratevi che gli IP siano regionali e si trovino nella stessa regione della VM target.
La UI vi avverte che gli IP esterni statici inutilizzati hanno un prezzo più alto rispetto a quelli in uso, ma a questo rimediamo a breve.
Procediamo creando una VM: chiamiamola "au-vm" nella regione australia-southeast1. Ricordatevi di selezionare "Consenti traffico HTTP" o di configurare le regole del firewall per consentire la porta in questione su TCP.
Passiamo ora alle forwarding rules. Nel menu Network Services selezionate Load Balancing e avviate la configurazione del nuovo load balancer TCP. I valori predefiniti "Da Internet alle mie VM", "Solo singola regione" e "Target Pool o Target Instance" sono esattamente ciò che ci serve.
Date un nome al load balancer e, nella sezione Backend configuration, selezionate l'istanza au-vm già esistente.
La parte target è completa. Cliccate ora su "Frontend configuration" per occuparvi della parte di "ascolto" e aggiungete tutti gli IP che avete riservato.
Qui ho aggiunto tutti gli IP allocati in precedenza, in ascolto sulla porta 80
Cliccate su "Crea" e il gioco è fatto! Concedete un paio di minuti perché tutto vada online: da quel momento la vostra VM potrà accettare traffico da tutti e tre gli IP indicati sopra. Se non funziona, verificate di avere regole firewall che consentono le porte richieste.
Potete modificare il load balancer per aggiungere o rimuovere IP in qualsiasi momento.
I processi sulla vostra VM possono addirittura fare il bind sull'indirizzo IP target desiderato, anche se questo indirizzo non risulta configurato su alcuna interfaccia di rete Linux (come potete verificare con ip address show). In questo esempio, il comando seguente funzionerà:
nc -s 34.87.204.138 -l -p 80Il segreto dietro questa magia sono i daemon GCP in esecuzione sulla macchina, che configurano le route Linux per far accettare i pacchetti destinati agli indirizzi in questione:
me@au-vm:~$ ip route show table all...local 34.87.204.138 dev ens4 table local proto 66 scope hostlocal 34.87.228.28 dev ens4 table local proto 66 scope hostlocal 34.116.108.163 dev ens4 table local proto 66 scope host...Parliamo di soldi
Le forwarding rules funzionano alla grande e sembrano la risposta più naturale al problema. Non sono però gratuite.
Google vi addebita una tariffa fissa di 0,025 $/ora per le prime cinque regole: in pratica pagate sempre 0,025 $/ora in totale, sia che ne abbiate 1 sia che ne abbiate 5. Per ogni forwarding rule aggiuntiva il prezzo sale a 0,01 $/ora. Tenere quindi 10 IP per una VM per un intero mese costa 55 $/mese, solo per le forwarding rules.
Purtroppo non finisce qui. Non molto tempo fa GCP ha iniziato a far pagare anche gli IP esterni in uso (e a prescindere dal fatto che siano utilizzati da VM o da forwarding rules). Il prezzo di 0,004 $/h per IP può sembrare trascurabile, ma equivale a 0,004 $*730h = 2,92 $/mese che, moltiplicati per i 10 IP del nostro caso, portano il costo totale di 10 IP instradati alla nostra VM a:
55 $ + 29,2 $ ~= 85 $/mese, solo per gli IP, prima ancora di pagare la VM
Se sia caro o no, lascio decidere a voi :-)
Grazie per la lettura! Per restare in contatto, seguiteci sul DoiT Engineering Blog , sul canale LinkedIn DoiT e sul canale Twitter DoiT . Per scoprire le opportunità di carriera, visitate https://careers.doit.com .