Implementare la resilienza dell'infrastruttura con Kubernetes
Per implementare la resilienza basata sull'infrastruttura, è possibile usare una mesh di servizi. Oltre alla resilienza senza modificare il codice, una mesh di servizi offre gestione del traffico, criteri, sicurezza, identità avanzata e osservabilità. L'app viene disaccoppiata da queste funzionalità operative, che vengono spostate al livello dell'infrastruttura. In termini di architettura, una mesh di servizi è costituita da due componenti: un piano di controllo e un piano dati.
Il componente del piano di controllo include molti componenti che supportano la gestione della mesh di servizi. L'inventario dei componenti include in genere:
- Interfaccia di gestione, che può essere un'interfaccia utente o un'API.
- Regole e definizioni di criteri che definiscono il modo in cui la mesh di servizi deve implementare funzionalità specifiche.
- Gestione della sicurezza per elementi come identità e certificati sicuri per mTLS.
- Metriche o osservabilità per raccogliere e aggregare 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. Questa configurazione consente di configurare ogni proxy per:
- Proteggere il traffico tramite mTLS.
- Instradare dinamicamente il traffico.
- Applicare criteri al traffico.
- Raccogliere metriche e informazioni di traccia.
Alcune opzioni comuni della mesh di servizi per i cluster Kubernetes includono Linkerd, Istio e Consul. Questo modulo è incentrato su Linkerd. Il diagramma seguente mostra le interazioni tra i componenti all'interno dei piani di dati e di controllo:
Confronto con approcci basati su codice
La strategia principale di gestione degli errori di Linkerd comprende ripetizioni dei 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 di adattarsi dinamicamente alle condizioni del cluster in tempo reale. Questo approccio aggiunge un'altra dimensione alla gestione del cluster, ma non aggiunge codice.
Con un approccio basato su codice, ad esempio con Polly, è possibile:
- Sono necessari per indovinare quali parametri di ripetizione e timeout sono appropriati.
- Concentrarsi su una richiesta HTTP specifica.
Non esiste un modo ragionevole per rispondere a un errore dell'infrastruttura nel codice dell'app. Prendere in considerazione centinaia o migliaia di richieste elaborate contemporaneamente. 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 a conoscenza degli elementi interni dell'app. Ad esempio, le transazioni di database complesse sono invisibili a Linkerd. Tali transazioni possono essere protette da eventuali errori con Polly.
Nelle prossime unità si implementerà la resilienza per il servizio di gestione dei coupon usando Polly e Linkerd.