Un confronto della mesh del servizio Kubernetes

Quando si parla di architettura dei microservizi e containerizzazione, un set di strumenti collaudati in produzione ha catturato la maggior parte dell'attenzione negli ultimi anni: la rete di servizi.

In effetti, l'architettura dei microservizi e Kubernetes (spesso stilizzati "K8") sono diventati rapidamente la norma per le app scalabili, rendendo il problema della gestione delle comunicazioni tra i servizi un argomento caldo e le mesh di servizi una soluzione interessante. Io stesso ho utilizzato service mesh in produzione, in particolare Linkerd, Istio e una precedente forma di Ambassador. Ma cosa fanno esattamente le service mesh? Qual è il migliore da usare? Come fai a sapere se dovresti usarne uno?

Per rispondere a queste domande, è utile capire perché sono state sviluppate le service mesh. Storicamente, l'infrastruttura IT tradizionale prevedeva applicazioni in esecuzione come monoliti. Un servizio eseguito su un server; se aveva bisogno di maggiore capacità, la soluzione era ridimensionarla verticalmente fornendo una macchina più grande.

Raggiungendo i limiti di questo approccio, le grandi aziende tecnologiche hanno adottato rapidamente un'architettura a tre livelli, separando un sistema di bilanciamento del carico dai server delle applicazioni e un livello di database. Sebbene questa architettura sia rimasta in qualche modo scalabile, hanno deciso di suddividere il livello dell'applicazione in microservizi. La comunicazione tra questi servizi è diventata fondamentale per il monitoraggio e la protezione per la scalabilità delle applicazioni.

Per consentire la comunicazione tra i servizi, queste società hanno sviluppato librerie interne: Finagle su Twitter, Hystrix su Netflix e Stubby su Google (diventato gRPC nel 2016). Queste librerie miravano a risolvere i problemi sollevati dall'architettura dei microservizi: sicurezza tra servizi, latenza, monitoraggio e bilanciamento del carico. Ma la gestione di una grande libreria come dipendenza, in più lingue, è complessa e richiede tempo.

Alla fine, quel tipo di libreria è stato sostituito con un proxy leggero e facile da usare. Tali proxy erano esternamente indipendenti dal livello dell'applicazione, potenzialmente trasparenti per l'applicazione, e più facili da aggiornare, mantenere e distribuire. Nasce così la rete di servizi.

Che cos'è una rete di servizi?

Una rete di servizi è un livello di infrastruttura software per il controllo della comunicazione tra i servizi; generalmente è composto da due componenti:

1. Il piano dati , che gestisce le comunicazioni vicino all'applicazione. In genere questo viene distribuito con l'applicazione come un insieme di proxy di rete, come illustrato in precedenza.
2. Il piano di controllo, che è il "cervello" della rete di servizi. Il piano di controllo interagisce con i proxy per eseguire il push delle configurazioni, garantire il rilevamento dei servizi e centralizzare l'osservabilità.

Le service mesh hanno tre obiettivi principali intorno alla comunicazione tra i servizi:

1. Connettività
2. Sicurezza
3. Osservabilità

Connettività

Questo aspetto dell'architettura della rete di servizi consente il rilevamento dei servizi e l'instradamento dinamico. Copre anche la resilienza della comunicazione , come tentativi, timeout, interruzione di circuito e limitazione della velocità.

Una caratteristica fondamentale delle mesh di servizi è il bilanciamento del carico . Tutti i servizi in mesh tramite proxy consentono l'implementazione di politiche di bilanciamento del carico tra i servizi, ad esempio richieste round robin, casuali e minime. Tali politiche sono la strategia utilizzata dalla rete di servizi per decidere quale replica riceverà la richiesta originale, proprio come se si disponessero di piccoli bilanciatori di carico davanti a ciascun servizio.

Infine, le service mesh offrono il controllo dell'instradamento sotto forma di spostamento e mirroring del traffico.

Sicurezza

Nell'architettura tradizionale dei microservizi, i servizi comunicano tra loro con traffico non crittografato. Il traffico interno non crittografato è oggi considerato una cattiva pratica in termini di sicurezza, in particolare per l'infrastruttura di cloud pubblico e le reti zero-trust.

Oltre a proteggere la privacy dei dati dei client dove non c'è un controllo diretto sull'hardware, la crittografia del traffico interno aggiunge un gradito livello di ulteriore complessità in caso di violazione del sistema. Pertanto, tutte le mesh di servizio utilizzano la crittografia TLS (mTLS) reciproca per la comunicazione tra servizi, ovvero tutte le comunicazioni tra proxy.

I service mesh possono anche imporre matrici complesse di policy di autorizzazione , consentendo o rifiutando il traffico in base a policy rivolte ad ambienti e servizi particolari.

Osservabilità

L'obiettivo delle mesh di servizio è dare visibilità alle comunicazioni interservizi. Controllando la rete, una rete di servizi rafforza l'osservabilità, fornendo metriche di livello sette , che a loro volta consentono avvisi automatici quando il traffico raggiunge una soglia personalizzabile.

Solitamente supportato da strumenti o plug-in di terze parti come Jaeger o Zipkin, tale controllo consente anche il tracciamento iniettando intestazioni di traccia HTTP .

Vantaggi della rete di servizi

La rete di servizi è stata creata per compensare parte del carico operativo creato da un'architettura di microservizi. Coloro che hanno esperienza nelle architetture di microservizi sanno che richiedono una notevole quantità di lavoro per operare su base giornaliera. Sfruttare appieno il potenziale dei microservizi normalmente richiede strumenti esterni per gestire la registrazione centralizzata, la gestione della configurazione e i meccanismi di scalabilità, tra gli altri. L'utilizzo di una rete di servizi standardizza queste capacità, nonché la loro configurazione e integrazione .

L'osservabilità della mesh dei servizi, in particolare, fornisce metodi di debug e ottimizzazione estremamente versatili. Grazie alla visibilità granulare e completa sugli scambi tra i servizi, gli ingegneri, in particolare gli SRE, possono risolvere più rapidamente possibili bug e configurazioni errate del sistema. Con la traccia della mesh del servizio, possono seguire una richiesta dal suo ingresso nel sistema (su un bilanciatore del carico o un proxy esterno) fino ai servizi privati ​​all'interno dello stack. Possono utilizzare la registrazione per mappare una richiesta e registrare la latenza che incontra in ciascun servizio. Il risultato finale: approfondimenti dettagliati sulle prestazioni del sistema .

La gestione del traffico offre potenti possibilità prima di passare al rilascio completo di una nuova versione di un servizio:

1. Reindirizzare piccole percentuali di richieste.
2. Ancora meglio, eseguire il mirroring delle richieste di produzione su una nuova versione per testarne il comportamento con il traffico in tempo reale.
3. A/B testare qualsiasi servizio o combinazione di servizi.

Le mesh di servizio semplificano tutti gli scenari di cui sopra, rendendo più facile evitare e/o mitigare eventuali sorprese in produzione.

Confronto della mesh del servizio Kubernetes

In molti modi, le mesh di servizi sono l'ultimo set di strumenti per l'architettura dei microservizi; molti di questi vengono eseguiti su uno dei migliori strumenti di orchestrazione dei container, Kubernetes. Abbiamo selezionato tre delle principali mesh di servizi in esecuzione su Kubernetes oggi: Linkerd (v2), Istio e Consul Connect. Discuteremo anche di altre mesh di servizi: Kuma, Traefik Mesh e AWS App Mesh. Sebbene attualmente meno importanti in termini di utilizzo e community, sono abbastanza promettenti da recensire qui e da tenere d'occhio in generale.

Una breve nota sui proxy sidecar

Non tutte le mesh di servizio Kubernetes adottano lo stesso approccio architetturale, ma uno comune è sfruttare il pattern sidecar. Ciò comporta il collegamento di un proxy (sidecar) all'applicazione principale per intercettare e regolare il traffico di rete in entrata e in uscita dell'applicazione. In pratica, questo viene fatto in Kubernetes tramite un contenitore secondario in ogni pod dell'applicazione che seguirà il ciclo di vita del contenitore dell'applicazione.

Ci sono due vantaggi principali nell'approccio sidecar alle mesh di servizio:

• I proxy sidecar sono indipendenti dal runtime e persino dal linguaggio di programmazione dell'applicazione.
  • Ciò significa che è facile abilitare tutte le funzionalità di una service mesh ovunque venga utilizzata, in tutto lo stack.
• Un sidecar ha lo stesso livello di autorizzazioni e accesso alle risorse dell'applicazione.
  • Il sidecar può aiutare a monitorare le risorse utilizzate dall'applicazione principale, senza la necessità di integrare il monitoraggio nella base di codice dell'applicazione principale.

Ma i sidecar sono una benedizione mista a causa del modo in cui influiscono direttamente su un'applicazione:

• L'inizializzazione del sidecar può bloccare il meccanismo di avvio di un'applicazione.
• I proxy sidecar aggiungono potenziale latenza alla tua applicazione.
• I proxy sidecar aggiungono anche un'impronta di risorse che può costare una notevole quantità di denaro su larga scala.

Dati questi vantaggi e svantaggi, l'approccio sidecar è spesso oggetto di dibattito nella comunità di service mesh. Detto questo, quattro delle sei mesh di servizi qui confrontate utilizzano il proxy sidecar Envoy e Linkerd utilizza la propria implementazione sidecar; Traefik Mesh non utilizza sidecar nel suo design.

Recensione Linkerd

Linkerd, che ha debuttato nel 2017, è la rete di servizi più antica sul mercato. Creato da Buoyant (una società fondata da due ex ingegneri di Twitter), Linkerd v1 era basato su Finagle e Netty.

Linkerd v1 è stato descritto come in anticipo sui tempi poiché era una rete di servizi completa e pronta per la produzione. Allo stesso tempo, era un po' pesante in termini di utilizzo delle risorse. Inoltre, significative lacune nella documentazione hanno reso difficile l'impostazione e l'esecuzione in produzione.

Con ciò, Buoyant ha avuto la possibilità di lavorare con un modello di produzione completo, acquisire esperienza da esso e applicare quella saggezza. Il risultato è stato Conduit, la riscrittura completa di Linkerd rilasciata dalla società nel 2018 e ribattezzata Linkerd v2 nello stesso anno. Linkerd v2 ha portato con sé diversi interessanti miglioramenti; poiché lo sviluppo attivo di Linkerd v1 da parte di Buoyant è cessato molto tempo fa, le nostre menzioni di "Linkerd" nel resto di questo articolo si riferiscono alla v2.

Completamente open source, Linkerd si basa su un proxy fatto in casa scritto in Rust per il piano dati e sul codice sorgente scritto in Go per il piano di controllo.

Connettività

I proxy Linkerd hanno funzionalità di ripetizione e timeout ma non hanno interruzioni di circuito o iniezione di ritardo al momento della stesura di questo documento. Il supporto in ingresso è ampio; Linkerd vanta l'integrazione con i seguenti controller di ingresso:

• Traefik
• Nginx
• GCE
• Ambasciatore
• Glù
• Contorno
• Kong

I profili di servizio in Linkerd offrono funzionalità di instradamento avanzate, fornendo all'utente metriche, ottimizzazione dei tentativi e impostazioni di timeout, il tutto in base alla rotta. Per quanto riguarda il bilanciamento del carico, Linkerd offre l'iniezione automatica del proxy, la propria dashboard e il supporto nativo per Grafana.

Sicurezza

Il supporto mTLS in Linkerd è conveniente in quanto la sua configurazione iniziale è automatica, così come la rotazione automatica giornaliera delle chiavi.

Osservabilità

Per impostazione predefinita, le statistiche e i percorsi di Linkerd sono osservabili tramite una CLI. Sul lato GUI, le opzioni includono dashboard Grafana premade e un dashboard Linkerd nativo.

Linkerd può collegarsi a un'istanza di Prometheus.

La traccia può essere abilitata tramite un componente aggiuntivo con OpenTelemetry (precedentemente OpenCensus) come raccoglitore e Jaeger che esegue la traccia stessa.

Installazione

L'installazione di Linkerd viene eseguita iniettando un proxy sidecar, che viene eseguita aggiungendo un'annotazione alle tue risorse in Kubernetes. Ci sono due modi per farlo:

1. Usando un grafico Helm. (Per molti, Helm è il gestore di modelli e configurazione di riferimento per le risorse Kubernetes.)
2. Installazione della CLI di Linkerd, quindi utilizzo per installare Linkerd in un cluster.

Il secondo metodo inizia con il download e l'esecuzione di uno script di installazione:

 curl -sL https://run.linkerd.io/install | sh

Da lì, lo strumento Linkerd CLI linkerd fornisce un utile toolkit che aiuta a installare il resto di Linkerd e interagire con il cluster di app e il piano di controllo.

linkerd check --pre eseguirà tutti i controlli preliminari necessari per l'installazione di Linkerd, fornendo registri chiari e precisi sul motivo per cui una potenziale installazione di Linkerd potrebbe non funzionare ancora. Senza --pre , questo comando può essere utilizzato per il debug post-installazione.

Il passaggio successivo consiste nell'installare Linkerd nel cluster eseguendo:

 linkerd install | kubectl apply -f -

Linkerd installerà quindi molti componenti diversi con un ingombro di risorse molto ridotto; quindi, essi stessi hanno un approccio di microservizi:

• linkerd-controller , che fornisce l'API pubblica con cui interagiscono CLI e dashboard
• linkerd-identity , che fornisce l'autorità di certificazione per implementare mTLS
• linkerd-proxy-injector , che gestisce l'iniezione del proxy mutando la configurazione di un pod
• linkerd-web , che fornisce un dashboard che consente il monitoraggio di implementazioni e pod, nonché componenti interni di Linkerd

Linkerd basa la maggior parte della sua configurazione su CustomResourceDefinitions (CRD). Questa è considerata la migliore pratica durante lo sviluppo di software aggiuntivo Kubernetes: è come installare in modo duraturo un plug-in in un cluster Kubernetes.

L'aggiunta della traccia distribuita, che potrebbe essere o meno ciò che gli utenti di Linkerd stanno effettivamente cercando, a causa di alcuni miti comuni, richiede un altro passaggio con linkerd-collector e linkerd-jaeger. Per questo, creeremmo prima un file di configurazione:

 cat >> config.yaml << EOF tracing: enabled: true EOF

Per abilitare il tracciamento, eseguiremo:

 linkerd upgrade --config config.yaml | kubectl apply -f -

Come con qualsiasi service mesh basato su proxy sidecar, dovrai modificare il codice dell'applicazione per abilitare la traccia. La maggior parte di questo è semplicemente l'aggiunta di una libreria client per propagare le intestazioni di traccia; deve quindi essere incluso in ogni servizio.

La funzionalità di suddivisione del traffico di Linkerd, esposta tramite la sua API conforme a Service Mesh Interface (SMI), consente già le versioni canary. Ma per automatizzarli e gestire il traffico, avrai anche bisogno di strumenti esterni come Flagger.

Flagger è uno strumento di consegna progressivo che valuterà quelle che Linkerd chiama le metriche "d'oro" : "volume delle richieste, percentuale di successo e distribuzioni di latenza". (Inizialmente, gli SRE di Google usavano il termine segnali d'oro e ne includevano un quarto, la saturazione, ma Linkerd non lo copre perché ciò richiederebbe parametri che non sono direttamente accessibili, come l'utilizzo della CPU e della memoria.) Flagger li tiene traccia mentre suddivide il traffico utilizzando un circuito di feedback; quindi, puoi implementare versioni canary automatizzate e sensibili alle metriche.

Dopo aver approfondito il processo di installazione, diventa chiaro che per avere una rete di servizi Linkerd operativa e che sfrutti le funzionalità comunemente desiderate, è facile ritrovarsi con almeno una dozzina di servizi in esecuzione. Detto questo, più di loro vengono forniti da Linkerd al momento dell'installazione rispetto ad altre reti di servizio.

Riepilogo della mesh del servizio Linkerd

vantaggi:

Linkerd beneficia dell'esperienza dei suoi creatori, due ex ingegneri di Twitter che avevano lavorato allo strumento interno, Finagle, e che in seguito avevano imparato da Linkerd v1. Essendo una delle prime mesh di servizi, Linkerd ha una fiorente comunità (il suo Slack ha più di 5.000 utenti, inoltre ha una mailing list attiva e un server Discord) e un'ampia serie di documentazione e tutorial. Linkerd è maturo con il rilascio della versione 2.9, come dimostra la sua adozione da parte di grandi aziende come Nordstrom, eBay, Strava, Expedia e Subspace. Per Linkerd è disponibile il supporto a pagamento di livello aziendale di Buoyant.

Svantaggi:

C'è una curva di apprendimento piuttosto forte per utilizzare le mesh del servizio Linkerd al massimo delle loro potenzialità. Linkerd è supportato solo all'interno dei contenitori Kubernetes (ovvero, non esiste una modalità "universale" basata su VM). Il proxy sidecar di Linkerd non è Envoy. Sebbene ciò consenta a Buoyant di sintonizzarlo come meglio crede, rimuove l'estensibilità intrinseca offerta da Envoy. Significa anche che a Linkerd manca il supporto per l'interruzione del circuito, l'iniezione di ritardo e la limitazione della velocità. Nessuna API particolare è esposta per controllare facilmente il piano di controllo di Linkerd. (Puoi trovare il binding dell'API gRPC, però.)

Linkerd ha fatto grandi progressi dalla v1 nella sua usabilità e facilità di installazione. La mancanza di un'API ufficialmente esposta è un'omissione notevole. Ma grazie a una documentazione altrimenti ben congegnata, le funzionalità pronte all'uso in Linkerd sono facili da testare.

Recensione di Console Connect

Il nostro prossimo concorrente della rete di servizi, Consul Connect, è un ibrido unico. Consul di HashiCorp è meglio conosciuto per il suo storage a valore chiave per architetture distribuite, che esiste da molti anni. Dopo l'evoluzione di Consul in una suite completa di strumenti di servizio, HashiCorp ha deciso di creare una rete di servizi su di esso: Consul Connect.

Per essere precisi sulla sua natura ibrida:

Il piano dati di Consul Connect è basato su Envoy, che è scritto in C++. Il piano di controllo di Consul Connect è scritto in Go. Questa è la parte supportata da Consul KV, un negozio di valori chiave.

Come la maggior parte delle altre mesh di servizi, Consul Connect funziona iniettando un proxy sidecar all'interno del pod dell'applicazione. In termini di architettura, Consul Connect si basa su agenti e server . Per impostazione predefinita, Consul Connect è pensato per avere un'elevata disponibilità (HA) utilizzando tre o cinque server come StatefulSet che specificano l'anti-affinità del pod. L'anti-affinità dei pod è la pratica per assicurarsi che i pod di un sistema software distribuito non finiscano sullo stesso nodo (server), garantendo così la disponibilità in caso di guasto di un singolo nodo.

Connettività

Non c'è molto che faccia risaltare Consul Connect in quest'area; fornisce ciò che fa qualsiasi service mesh (che è un bel po'), oltre a funzionalità di livello sette per l'instradamento basato sul percorso, lo spostamento del traffico e il bilanciamento del carico.

Sicurezza

Come con le altre mesh di servizio, Consul Connect fornisce funzionalità mTLS di base. Dispone inoltre dell'integrazione nativa tra Consul e Vault (anch'esso di HashiCorp), che può essere utilizzato come provider di CA per gestire e firmare certificati in un cluster.

Osservabilità

Consul Connect adotta l'approccio di osservabilità più comune incorporando Envoy come proxy sidecar per fornire funzionalità di livello sette. La configurazione dell'interfaccia utente di Consul Connect per il recupero delle metriche implica la modifica di un file di configurazione integrato e l'abilitazione di un provider di metriche come Prometheus. È anche possibile configurare alcuni dashboard Grafana per mostrare metriche specifiche del servizio rilevanti.

Installazione

Consul Connect viene installato in un cluster Kubernetes utilizzando un grafico Helm:

 helm repo add hashicorp https://helm.releases.hashicorp.com

Dovrai modificare il default values.yaml se vuoi abilitare l'interfaccia utente o fare in modo che il modulo Consul Connect inietti il ​​suo proxy sidecar:

 helm install -f consul-values.yml hashicorp hashicorp/consul

Per consultare i membri e controllare i vari nodi, Consul consiglia di exec in uno dei container e quindi di utilizzare lo strumento CLI consul .

Per fornire l'interfaccia utente Web pronta all'uso fornita da Consul, esegui kubectl port-forward service/hashicorp-consul-ui 18500:80 .

Riepilogo della rete del servizio Consul Connect

vantaggi:

• Consul è sostenuto da HashiCorp; come prodotto freemium, esiste anche una versione enterprise con funzionalità aggiuntive che offre supporto a livello aziendale. In termini di esperienza del team di sviluppo, Consul è uno degli strumenti più antichi sul mercato.
• Consul ha una solida comunità aziendale ed è noto per funzionare su un'infrastruttura con 50.000 nodi. Inoltre, è in circolazione dal 2014, il che lo rende un prodotto maturo rispetto al mercato.
• Consul Connect funziona bene all'interno di una VM, grazie al supporto nativo.
• Con Consul Connect, è possibile ottenere integrazioni di app profonde quanto le implementazioni mesh pre-servizio presso aziende tecnologiche di alto livello. Questo grazie all'esposizione di un'API a livello di libreria completamente documentata.

Svantaggi:

• Consul Connect ha una curva di apprendimento più ripida rispetto alle altre mesh di servizi e avrà bisogno di una maggiore messa a punto per eseguire dashboard e metriche visive.
• La documentazione di HashiCorp non è semplice, lasciando gli utenti a scavare e sperimentare per configurarla correttamente.
• La documentazione sulla gestione del traffico è difficile da trovare e consiste principalmente in collegamenti alla documentazione di Envoy, che non fornisce dettagli sulla gestione del traffico di Consul Connect in particolare.
• L'interfaccia SMI di Consul Connect è ancora sperimentale.

Consul Connect può essere un'ottima scelta per coloro che cercano un prodotto di livello aziendale. HashiCorp è nota per la qualità dei suoi prodotti e Consul Connect non fa eccezione. Posso vedere due forti vantaggi qui rispetto ad altre mesh di servizi: un forte supporto da parte dell'azienda con la versione enterprise e uno strumento pronto per tutti i tipi di architetture (non solo Kubernetes).

Recensione Istio

Nel maggio 2017, Google, IBM e Lyft hanno annunciato Istio. Quando Istio è entrata nella corsa degli strumenti di service mesh, ha ottenuto un'ottima visibilità nello spazio tecnologico. I suoi autori hanno aggiunto funzionalità basate sul feedback degli utenti fino alla versione 1.9.

Istio ha promesso importanti novità rispetto ai suoi concorrenti dell'epoca: bilanciamento del carico automatico, iniezione dei guasti e molto altro. Ciò gli è valso una copiosa attenzione da parte della comunità, ma come vedremo in dettaglio di seguito, l'utilizzo di Istio è tutt'altro che banale: Istio è stato riconosciuto come particolarmente complesso da mettere in produzione.

Storicamente, il progetto Istio è rimbalzato frequentemente in termini di modifiche al codice sorgente. Dopo aver adottato un'architettura di microservizi per il piano di controllo, Istio è ora tornato (dalla versione 1.5) a un'architettura monolitica. La motivazione di Istio per tornare alla centralizzazione era che i microservizi erano difficili da monitorare per gli operatori, la codebase era troppo ridondante e il progetto aveva raggiunto la maturità organizzativa: non era più necessario che molti piccoli team lavorassero in silos.

Tuttavia, lungo la strada Istio ha acquisito notorietà per avere uno dei più alti volumi di problemi GitHub aperti. Al momento della stesura di questo documento, il conteggio è di circa 800 numeri aperti e circa 12.000 chiusi. Sebbene i conteggi dei problemi possano essere ingannevoli, in questo caso rappresentano un miglioramento significativo in termini di funzionalità precedentemente interrotte e utilizzo fuori controllo delle risorse.

Connettività

Istio è piuttosto forte nella gestione del traffico rispetto a Consul Connect e Linkerd. Ciò è dovuto a un'ampia offerta di funzionalità secondarie: routing delle richieste, inserimento dei guasti, spostamento del traffico, timeout delle richieste, interruzione del circuito e controllo del traffico in ingresso e in uscita verso la rete di servizi. La nozione di servizi virtuali e regole di destinazione lo rende molto completo in termini di gestione del traffico.

Tuttavia, tutte queste possibilità sono accompagnate da una curva di apprendimento, oltre alla gestione di quelle nuove risorse sul tuo cluster Kubernetes.

Sicurezza

Istio vanta un set completo di strumenti relativi alla sicurezza, con due assi principali: autenticazione e autorizzazione. Istio può applicare diversi livelli di policy su diversi ambiti: specifico del carico di lavoro, a livello di spazio dei nomi o a livello di mesh. Tutte queste risorse di sicurezza sono gestite tramite Istio CRD come AuthorizationPolicy o PeerAuthentication .

Oltre al supporto mTLS standard, Istio può anche essere configurato per accettare o rifiutare il traffico non crittografato.

Osservabilità

Qui, Istio è abbastanza avanzato, con diversi tipi di telemetria che offrono solide informazioni sulla rete di servizi. Le metriche si basano sui quattro segnali d'oro (latenza, traffico, errori e, in una certa misura, saturazione).

In particolare, Istio fornisce metriche per il piano di controllo stesso. Serve anche tracce distribuite e registri di accesso, vantando una compatibilità esplicita con Jaeger, Lightstep e Zipkin per abilitare la traccia.

Non esiste una dashboard nativa, ma esiste il supporto ufficiale per la console di gestione di Kiali.

Installazione

L'installazione è semplice come seguire i passaggi ufficiali. Istio è anche integrato in modo nativo in GKE come funzionalità beta, ma lì GKE utilizza Istio 1.4.X, la versione precedente dei microservizi rispetto all'ultima versione monolitica.

Un'installazione nativa inizia con il download dell'ultima versione:

 curl -L https://istio.io/downloadIstio | sh -

Dopo aver eseguito il cd nella cartella istio-* appena creata, puoi aggiungerla al tuo percorso in modo da poter utilizzare lo strumento di utilità istioctl :

 export PATH=$PWD/bin:$PATH

Da lì, puoi installare Istio sul tuo cluster Kubernetes tramite istioctl :

 istioctl install

Questo installerà Istio con un profilo default . I profili istioctl consentono di creare diverse configurazioni di installazione e di passare da una all'altra se necessario. Ma anche in uno scenario a profilo singolo, puoi personalizzare profondamente l'installazione di Istio modificando alcuni CRD.

Le risorse Istio saranno più difficili da gestire poiché dovrai gestire diversi tipi di CRD, come minimo VirtualService , DestinationRule e Gateway , per assicurarti che la gestione del traffico sia in atto.

• Una risorsa VirtualService è una configurazione che dichiara un servizio e le diverse regole di routing applicate alle richieste.
• Una risorsa DestinationRule viene utilizzata per raggruppare e applicare criteri di traffico specifici per la destinazione.
• Viene creata una risorsa Gateway per gestire il traffico mesh di servizi in entrata e in uscita (ad esempio proxy Envoy aggiuntivi, ma in esecuzione a livello perimetrale anziché come sidecar).

I dettagli semantici esulano dallo scopo di questa recensione, ma diamo un'occhiata a un rapido esempio che mostra ciascuno di questi lavorare insieme. Supponiamo di avere un sito di e-commerce con un servizio chiamato products . Il nostro VirtualService potrebbe assomigliare a questo:

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

La corrispondente DestinationRule potrebbe quindi essere:

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

Infine, il nostro Gateway :

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

Con questi tre file in atto, un'installazione Istio sarebbe pronta per gestire il traffico di base.

Riepilogo della mesh del servizio Istio

vantaggi:

• Tra le diverse reti di servizi, Istio è quella con la più grande comunità online al momento della stesura di questo articolo. Con oltre 10 volte i risultati di Stack Overflow come uno dei suoi principali concorrenti, è la rete di servizi più discussa sul web; anche i suoi contributori GitHub sono un ordine di grandezza superiore a quelli di Linkerd.
• Istio supporta entrambe le modalità Kubernetes e VM; quest'ultimo è in versione beta a partire dalla versione 1.9.

Svantaggi:

• Istio non è libero, in due sensi:
  • I suoi requisiti sono elevati in termini di tempo necessario per leggere la documentazione, configurarla, farla funzionare correttamente e mantenerla. A seconda delle dimensioni dell'infrastruttura e del numero di servizi, Istio impiegherà da diverse settimane a diversi mesi di lavoro a tempo pieno per essere pienamente funzionante e integrato nella produzione.
  • Aggiunge anche una notevole quantità di sovraccarico delle risorse: ci vorranno 350 millicore (mCPU) per il container Envoy per 1.000 richieste al secondo (RPS). Anche il piano di controllo stesso può consumare risorse. (In precedenza, l'utilizzo delle risorse sarebbe stato difficile da prevedere, ma dopo qualche sforzo, istiod si è stabilizzato utilizzando 1 vCPU e 1,5 GB di memoria.)
• Non ha dashboard di amministrazione nativa, a differenza di Linkerd.
• Istio richiede l'uso del proprio gateway di ingresso.
• Il piano di controllo Istio è supportato solo all'interno dei contenitori Kubernetes (ovvero, non esiste la modalità VM, a differenza del piano dati di Istio).

Istio è un ottimo esempio di giganti della tecnologia che si uniscono per creare un progetto open source per affrontare una sfida che tutti stanno affrontando. Ci è voluto del tempo prima che il progetto Istio nel suo insieme si strutturasse (richiamando il passaggio dall'architettura dei microservizi al monolito) e risolvesse i suoi numerosi problemi iniziali. Oggi, Istio sta facendo assolutamente tutto ciò che ci si aspetterebbe da una rete di servizi e può essere notevolmente ampliato. Ma tutte queste possibilità comportano requisiti elevati in termini di conoscenza, ore di lavoro e risorse informatiche per supportarne l'utilizzo in un ambiente di produzione.

Recensione rapida di Kuma

Creato da Kong e poi open source, Kuma ha raggiunto 1.0 alla fine del 2020. In una certa misura, è stato creato in risposta al fatto che le prime service mesh erano piuttosto pesanti e difficili da utilizzare.

Il suo elenco di funzionalità suggerisce che sia molto modulare; l'idea alla base di Kuma è di orientarlo verso l'integrazione con le applicazioni già in esecuzione su Kubernetes o altre infrastrutture.

• Nell'area della gestione del traffico , Kuma offre funzionalità di rete di servizi comuni come l'iniezione di guasti e l'interruzione del circuito.
• Oltre alla crittografia mTLS interservizi, gli scambi tra il piano dati e il piano di controllo sono protetti in Kuma tramite un token proxy del piano dati .
• L'osservabilità è definita in Kuma tramite diverse politiche di traffico relative a metriche, traccia e registrazione.
• Il rilevamento dei servizi è disponibile tramite Kuma grazie al proprio resolver DNS in esecuzione sulla porta 5653 del piano di controllo.
• Kuma pone una forte enfasi sulla funzionalità multimesh : puoi combinare facilmente diversi cluster Kubernetes o ambienti VM in un cluster Kuma comune con il suo tipo di distribuzione multizona.
• Kuma si integra facilmente con Kong Gateway per gli utenti Kong esistenti.

La versione universale (non Kubernetes) di Kuma richiede PostgreSQL come dipendenza e il CTO di Kong è stato in particolare contrario al supporto di SMI. Ma Kuma è stato sviluppato con l'idea di implementazioni multicloud e multicluster sin dall'inizio e la sua dashboard lo riflette.

Sebbene Kuma sia ancora giovane nello spazio della rete di servizi, con pochi casi di utilizzo della produzione finora, è un contendente interessante e promettente.

Recensione rapida di Traefik Mesh

Originariamente chiamato Maesh, Traefik Mesh (di Traefik Labs) è un altro nuovo arrivato nella corsa agli strumenti per mesh di servizio. La missione del progetto è di democratizzare la rete di servizi rendendola facile da usare e configurare; l'esperienza degli sviluppatori con il ben congegnato Traefik Proxy li ha messi in una posizione privilegiata per raggiungere questo obiettivo.

• Le funzionalità di gestione del traffico in Traefik Mesh includono l'interruzione del circuito e la limitazione della velocità.
• In termini di osservabilità , Traefik Mesh offre supporto OpenTracing nativo e metriche pronte all'uso (l'installazione standard include automaticamente Prometheus e Grafana), che consente di risparmiare tempo di configurazione.
• Per la sicurezza, a parte mTLS, le specifiche sono conformi a SMI e Traefik Mesh consente la messa a punto dei permessi di traffico attraverso il controllo degli accessi.

Traefik Mesh necessita dell'installazione di CoreDNS sul cluster. (Sebbene Azure utilizzi CoreDNS per impostazione predefinita dalla versione 1.12, GKE utilizza per impostazione predefinita kube-dns al momento della stesura di questo documento, il che significa che in questo caso è coinvolto un passaggio aggiuntivo significativo.) Inoltre manca di funzionalità multicluster.

Detto questo, Traefik Mesh è unico all'interno del nostro confronto di mesh di servizi in quanto non utilizza l'iniezione di sidecar. Viene invece distribuito come DaemonSet su tutti i nodi per fungere da proxy tra i servizi, rendendolo non invasivo. Nel complesso, Traefik Mesh è semplice da installare e utilizzare.

Recensione rapida di AWS App Mesh

Nel mondo dei cloud provider, AWS è il primo ad aver implementato un service mesh nativo collegabile a Kubernetes (o EKS in particolare) ma anche ad altri suoi servizi. AWS App Mesh è stato rilasciato a novembre 2018 e da allora AWS ha continuato a utilizzarlo. Il vantaggio principale di AWS App Mesh è l'ecosistema AWS preesistente e la posizione di mercato; la grande comunità dietro ad AWS in generale continuerà a guidarne l'utilizzo e l'usabilità.

• La gestione del traffico in AWS App Mesh include l'interruzione del circuito oltre alle funzionalità comuni.
• Since AWS App Mesh is hosted by AWS, it's a fully managed service , which means not having to worry about resource usage or control plane availability.
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

Infrastruttura

Traffic Management

Observability

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

Distribuzione

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.