Pod IP, ClusterIP o bilanciatore interno per gli utenti VPN
Un Pod IP è instradabile via VPN finché il Pod non viene sostituito. Confrontate l’accesso diretto al Pod, ClusterIP e un bilanciatore interno, e quanto vi costa ciascuno.
Con il VPC CNI, un Pod può avere un indirizzo del VPC, e un utente VPN con la rotta giusta può raggiungerlo direttamente. Questo fa sembrare l’accesso diretto al Pod l’opzione più semplice, e lo è, finché il Pod non viene sostituito. L’indirizzo che un utente ricorda dovrebbe appartenere all’applicazione, non a una replica. Confrontare i tre ingressi si riduce a quale oggetto possiede l’indirizzo e cosa deve continuare a funzionare quando il carico di lavoro si sposta.
Scegliete prima in base al ciclo di vita, poi in base a ciò che la rete deve fare per rendere l’ingresso raggiungibile.
Tre ingressi, tre cicli di vita
Un Pod IP è di proprietà di un Pod: viene allocato con esso e rilasciato quando termina. Un ClusterIP è di proprietà di un Service ed è virtuale, ha senso solo dove esiste l’instradamento dei servizi del cluster. Un bilanciatore interno è di proprietà di una risorsa cloud che il controller del cluster programma con i backend. Questi modelli di proprietà prevedono il guasto che otterrete: un indirizzo obsoleto, un nome irraggiungibile o un insieme di backend non aggiornato.
Scrivete il confronto prima di scegliere. Una volta nominati il proprietario e il guasto, la scelta di solito si fa da sola.
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
Accesso diretto al Pod: utile, temporaneo
L’accesso diretto è davvero utile per una verifica controllata: un amministratore, una sessione breve, una porta specifica. Ma è un cattivo contratto per gli utenti, perché l’indirizzo è un dettaglio implementativo che cambia a ogni rilascio. E registrarne uno in una wiki è il modo in cui un servizio che funziona diventa una voce di corridoio.
Invita anche a regole ampie. Il permesso per un amministratore di raggiungere un Pod non è un permesso per ogni indirizzo della sottorete del nodo, e di solito è il secondo a essere scritto.
ClusterIP: limitato al cluster per progettazione
Un ClusterIP funziona perché il dataplane del cluster programma l’instradamento per esso all’interno del cluster. Da un portatile sulla VPN l’indirizzo non significa nulla a meno che qualcosa non lo esponga deliberatamente. Un nome che termina in svc.cluster.local appartiene al DNS del cluster, quindi copiarlo su un client con un altro resolver produce un nome che non esiste invece di un errore di instradamento.
ClusterIP resta l’ingresso giusto per i chiamanti interni al cluster, compresi altri carichi di lavoro. Semplicemente non è un meccanismo di pubblicazione per gli utenti fuori dal dominio di instradamento del cluster.
Bilanciatore interno: il percorso pubblicato
Un bilanciatore interno vi dà un indirizzo privato stabile e un nome verso cui la vostra zona può puntare, mentre il controller mantiene aggiornato l’insieme dei backend, come descrive la guida di EKS al bilanciamento del carico. È l’ingresso che sopravvive a una normale sostituzione di Pod senza che nessuno modifichi un documento. Costa una risorsa cloud, una configurazione del controller e una rotta dalla VPN, e sono queste le parti che la gente sottovaluta.
Usate il modello di controller che il cluster esegue davvero. Le annotazioni scritte per un’integrazione non valgono per un’altra.
Chi è l’indirizzo di origine
I gruppi di sicurezza vedono l’origine che arriva al loro confine, e questa può essere il client connesso o un indirizzo tradotto a seconda del percorso VPN e di bilanciamento del carico. Sui nodi basati su EC2, i Pod VPC CNI ordinari ereditano per impostazione predefinita i gruppi dell’ENI del nodo, mentre le configurazioni supportate possono collegare gruppi specifici del Pod. Scrivete regole per il percorso documentato invece che per un indirizzo presunto del portatile.
Tenete il listener e l’autenticazione propri dell’applicazione come controlli separati. Una regola di rete che consente il flusso non è una decisione di autorizzazione e non va trattata come tale.
Cosa consegnare agli utenti
Date agli utenti un nome di servizio, non un indirizzo. Pubblicate il nome nella zona privata, puntatelo all’ingresso interno, poi provate sostituendo un Pod di backend mentre un client tiene aperto lo stesso nome. Quell’esercizio verifica la proprietà che conta: raggiungere la stessa applicazione dopo un deployment di routine.
Tenete l’accesso diretto al Pod come eccezione operativa documentata con il suo ambito, lontano dalle istruzioni per gli utenti.