Implementare la resilienza dell'infrastruttura con Kubernetes
Per implementare la resilienza basata sull'infrastruttura, è possibile usare una mesh di servizi. Oltre alla resilienza senza modifica del codice, una mesh di servizi offre vantaggi in termini di gestione del traffico, criteri, sicurezza, identità consolidata e osservabilità. L'app viene dissociata da queste funzionalità operative, che vengono spostate al livello di infrastruttura. In termini di architettura, una mesh di servizi è costituita da due componenti: un piano di controllo e un piano dati.
Il piano di controllo comprende un numero di componenti che supportano la gestione della mesh di servizi. L'inventario dei componenti include in genere:
- Un'interfaccia di gestione, che può essere un'interfaccia utente o un'API.
- Regole e definizioni dei criteri che stabiliscono il modo in cui la mesh di servizi deve implementare funzionalità specifiche.
- Gestione della sicurezza per elementi come identità consolidata e certificati per mTLS.
- Metriche o osservabilità per la raccolta e l'aggregazione di metriche e dati di telemetria dalle app.
Il componente del piano dati è costituito da proxy inseriti in modo trasparente insieme a ogni servizio, noto come modello Sidecar. Ogni proxy è configurato per controllare il traffico di rete all'interno e all'esterno del pod che contiene il servizio. In questo modo ogni proxy può essere configurato per:
- Proteggere il traffico tramite mTLS.
- Instradare dinamicamente il traffico.
- Applicare criteri al traffico.
- Raccogliere le metriche e le informazioni di traccia.
Tra le opzioni comuni delle mesh di servizi per i cluster Kubernetes sono inclusi Linkerd, Istio e Consul. Questo modulo è incentrato su Linkerd. Il diagramma seguente mostra le interazioni tra i componenti all'interno del piano dati e del piano di controllo:
Confronto con gli approcci basati sul codice
La strategia principale di gestione degli errori di Linkerd comprende tentativi e timeout. Poiché Linkerd ha una visione sistemica dell'intero cluster, può adottare strategie di resilienza in modi nuovi. Un esempio consiste nella ripetizione dei tentativi in modo da aggiungere al servizio di destinazione un carico aggiuntivo fino a un massimo del 20%. La visualizzazione basata sulle metriche di Linkerd consente l'adattamento dinamico alle condizioni del cluster in tempo reale. Questo approccio aggiunge un'altra dimensione alla gestione del cluster, ma non aggiunge codice.
Adottando un approccio basato sul codice, come avviene con Polly, è necessario:
- Individuare i parametri appropriati di ripetizione dei tentativi e timeout.
- Concentrarsi su una richiesta HTTP specifica.
Non esiste un modo ragionevole di rispondere a un errore dell'infrastruttura nel codice dell'app. Se si considerano le centinaia o migliaia di richieste elaborate simultaneamente, anche un tentativo con backoff esponenziale (moltiplicato per il numero di richieste) può sovraccaricare un servizio.
Al contrario, gli approcci basati sull'infrastruttura, come Linkerd, non sono consapevoli degli elementi interni dell'app. Le transazioni di database complesse, ad esempio, non sono visibili a Linkerd. Tali transazioni possono essere protette da eventuali errori con Polly.
Nelle unità successive verrà implementata la resilienza per il servizio di gestione dei coupon tramite Polly e Linkerd.