Illustrazione di evv da Shutterstock
Istio Ambient Mesh è stato presentato a settembre 2022, ma all'epoca non vi ho dedicato la giusta attenzione. Per chi però già utilizza o intende adottare Istio come service mesh, questa novità punta a colmare alcuni dei limiti del modello sidecar tradizionale, di cui parleremo nelle prossime sezioni.
Nota: Istio Ambient Mesh è ancora in fase alpha e non andrebbe utilizzato in ambienti di produzione fino al rilascio in General Availability (GA).
Prima di entrare nel vivo, è bene chiarire alcuni concetti di base: senza di essi, il resto dell'articolo rischia di risultare incomprensibile come un testo in geroglifici.
Cos'è una service mesh?
Molte applicazioni moderne si basano su un'architettura di microservizi distribuiti, in cui ogni microservizio assolve una funzione specifica e dialoga spesso con gli altri. Per usare un'analogia, si possono immaginare come mattoncini Lego modulari assemblati per comporre una statua, anziché una statua monolitica scolpita nella pietra.
Una service mesh è uno strato che si aggiunge sopra queste applicazioni (o microservizi) e abilita funzionalità come traffic management, observability e sicurezza, senza richiedere alcuna modifica alle applicazioni stesse.
Le funzionalità di Istio Service Mesh
Istio è una service mesh open-source che si integra in modo trasparente con le applicazioni distribuite esistenti. La modalità di comunicazione predefinita tra i servizi all'interno di un cluster avviene in chiaro, una scelta non ottimale dal punto di vista della sicurezza. Istio service mesh protegge questo traffico cifrando le comunicazioni con mTLS (mutual TLS). Offre inoltre numerose funzionalità aggiuntive, tra cui:
- Load balancing per HTTP, gRPC, WebSocket e TCP
- Controllo granulare del traffico
- Controlli di accesso, rate limit e quote
- Service discovery
- Observability totale (metriche e dati di telemetria, log e trace per tutto il traffico interno al cluster)
Ora che abbiamo chiaro cos'è una service mesh e quali vantaggi offre, mettiamo a confronto il modello sidecar tradizionale di Istio con il nuovo modello Ambient Mesh.
L'architettura di Istio senza Ambient Mesh
Istio si basa su 2 componenti fondamentali: un Control Plane e un Data Plane.
Il Data Plane rappresenta le comunicazioni tra i servizi nella mesh. La service mesh utilizza un proxy Envoy distribuito accanto a ciascun servizio (come sidecar) e tutto il traffico in entrata e in uscita transita attraverso questi proxy Envoy.
Il Control Plane raccoglie i dati da questi proxy, ne definisce e ne controlla la configurazione, riconciliando lo stato corrente dell'ambiente con quello desiderato.
fonte: https://istio.io/latest/docs/ops/deployment/architecture/
Svantaggi di questo modello:
- Resilienza: apportare modifiche, ad esempio aggiornare i proxy tramite il control plane, richiede il riavvio di ogni container sidecar, con possibili disservizi.
- Elevato consumo di risorse: per i sidecar le risorse vanno riservate sullo scenario peggiore, una soluzione poco efficiente che fa storcere il naso a chi gestisce la fatturazione.
- Interruzioni del traffico: in particolare con applicazioni che presentano implementazioni HTTP non conformi.
Il sidecar gestisce sia l'elaborazione del traffico di Layer 4 sia di Layer 7. Un problema rilevante è che l'elaborazione L7 è molto onerosa in termini di calcolo e questa funzionalità viene di fatto imposta ai servizi anche quando a questi serve solo una semplice transport security. Inoltre, la maggior parte delle Common Vulnerabilities and Exposures (CVE) critiche del proxy Envoy si manifesta proprio a livello L7: aggiungere il fardello del filtraggio L7 a servizi che non ne hanno bisogno significa quindi ampliare inutilmente la superficie di attacco.
L'architettura di Istio con Ambient Mesh
Istio Ambient Mesh introduce alcune modifiche radicali all'architettura del Data Plane. Questo modello separa le funzionalità L4 e L7 che, con i sidecar, costituivano un pacchetto inscindibile, tutto-o-niente.
fonte: https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/#slicing-the-layers
Al posto dei sidecar abbiamo ora un overlay sicuro creato dagli ztunnel (zero-trust tunnel). Questi ztunnel agiscono da agenti condivisi, distribuiti come DaemonSet: un agente per ogni nodo del cluster Kubernetes.
Lo ztunnel utilizza un programma eBPF compilato all'interno del componente istio-cni per instradare il traffico, con diversi vantaggi in termini di performance e flessibilità rispetto all'uso di iptables per il routing.
Ogni ztunnel si occupa di mettere in sicurezza il traffico L4 per i workloads del proprio nodo.
Per le funzionalità L7, ambient mesh consente di distribuire waypoint proxy basati su Envoy, applicati a livello di namespace: in questo modo i workloads di quel namespace possono sfruttare l'intera gamma di funzionalità di Istio.
fonte: https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/#slicing-the-layers
Questi waypoint proxy scalano in funzione della domanda effettiva dei workloads del namespace in cui operano. Un approccio decisamente più efficiente ed economico rispetto al riservare risorse per i sidecar sullo scenario peggiore di utilizzo.
Questa architettura consente per sua natura un utilizzo più ergonomico ed economicamente vantaggioso della service mesh Istio: i proxy L7 vengono applicati solo dove necessario, sfruttano le risorse in modo più efficiente e scalano in maniera più dinamica e indipendente.
Garantisce inoltre l'interoperabilità con il modello sidecar tradizionale, lasciando libertà di scelta.
Vi sono 2 aspetti critici di questo nuovo modello di data plane che non affronterò direttamente qui:
- Performance (a causa dei salti aggiuntivi):
Istio sostiene che, eliminando il filtraggio L7 ridondante bidirezionale del modello sidecar, l'eventuale degrado delle performance di ambient mesh dovuto al salto aggiuntivo verrà più che compensato. Pubblicheranno inoltre un articolo dedicato alle performance, presumibilmente in collaborazione con Solo.io e Google, con cui hanno sviluppato questa innovazione. 2. Sicurezza (a causa del modello ad agente condiviso):
A chi nutre dubbi sulle implicazioni di sicurezza di un Data Plane senza sidecar, consiglio la lettura dell'articolo Ambient Mesh Security Deep Dive.
Non vedo l'ora di vedere Ambient Mesh in un ambiente di produzione: promette di portare risparmi sui costi ed efficienze sostanziali a chi saprà sfruttarlo.
Alla fine dei conti, però, l'elefante nella stanza resta ben presente e ignorato: il proxy Envoy.
Non credo che i sidecar spariranno a breve, ma forse un giorno avremo un software di elaborazione L7 leggero, sicuro e al tempo stesso potente, capace di curare tutti i mali di chi usa una service mesh. Fino ad allora, ogni passo in quella direzione è un buon motivo per essere grati — e dovreste esserlo anche voi.