Nel passato Abbiamo esaminato i componenti di base di Service Mesh Istio, abbiamo familiarizzato con il sistema e risposto alle principali domande che di solito sorgono quando si inizia a lavorare con Istio. In questa parte vedremo come organizzare la raccolta di informazioni di tracciamento su una rete.
La prima cosa che viene in mente a molti sviluppatori e amministratori di sistema quando sentono le parole Service Mesh sta tracciando. Infatti, aggiungiamo uno speciale server proxy a ciascun nodo della rete attraverso il quale passa tutto il traffico TCP. Sembra che ora sia possibile inviare facilmente informazioni su tutte le interazioni di rete sulla rete. Sfortunatamente, in realtà ci sono molte sfumature di cui bisogna tenere conto. Diamo un'occhiata a loro.
Idea sbagliata numero uno: i dati escursionistici online possono essere ottenuti gratuitamente.
Infatti, in modo relativamente gratuito, possiamo ottenere solo i nodi del nostro sistema collegati dalle frecce e la velocità dei dati che passano tra i servizi (appunto, solo il numero di byte per unità di tempo). Tuttavia, nella maggior parte dei casi, i nostri servizi comunicano tramite una sorta di protocollo a livello di applicazione, come HTTP, gRPC, Redis e così via. E, naturalmente, vogliamo vedere le informazioni di tracciamento specifiche per questi protocolli; vogliamo vedere la velocità delle richieste, non la velocità dei dati. Vogliamo comprendere la latenza delle richieste utilizzando il nostro protocollo. Infine, vogliamo vedere il percorso completo seguito da una richiesta dall'accesso al nostro sistema alla ricezione di una risposta da parte dell'utente. Questo problema non è più così facile da risolvere.
Innanzitutto, esaminiamo l'aspetto dell'invio degli intervalli di tracciamento da un punto di vista architettonico in Istio. Come ricordiamo dalla prima parte, Istio ha un componente separato chiamato Mixer per la raccolta della telemetria. Tuttavia, nella versione attuale 1.0.*, l'invio avviene direttamente dai server proxy, ovvero da Envoy Proxy. Il proxy Envoy supporta l'invio di intervalli di traccia utilizzando il protocollo zipkin pronto all'uso. È possibile connettere altri protocolli, ma solo tramite plugin. Con Istio otteniamo immediatamente un proxy Envoy assemblato e configurato, che supporta solo il protocollo zipkin. Se vogliamo utilizzare, ad esempio, il protocollo Jaeger e inviare i tracing span tramite UDP, allora dovremo costruire la nostra immagine istio-proxy. È disponibile il supporto per plug-in personalizzati per istio-proxy, ma è ancora nella versione alpha. Pertanto, se vogliamo fare a meno di un gran numero di impostazioni personalizzate, la gamma di tecnologie utilizzate per la memorizzazione e la ricezione dei tracing span si riduce. Tra i principali sistemi, infatti, ora si può usare lo stesso Zipkin, oppure Jaeger, ma mandare lì tutto utilizzando il protocollo compatibile zipkin (che è molto meno efficiente). Lo stesso protocollo zipkin prevede l'invio di tutte le informazioni di tracciamento ai collezionisti tramite il protocollo HTTP, che è piuttosto costoso.
Come ho già detto, vogliamo tracciare i protocolli a livello di applicazione. Ciò significa che i server proxy che si trovano accanto a ciascun servizio devono capire che tipo di interazione sta accadendo in questo momento. Per impostazione predefinita, Istio configura tutte le porte come semplici TCP, il che significa che non verrà inviata alcuna traccia. Affinché le tracce possano essere inviate, è necessario innanzitutto abilitare questa opzione nella configurazione mesh principale e, cosa molto importante, denominare tutte le porte delle entità del servizio Kubernetes in conformità con il protocollo utilizzato nel servizio. Cioè, ad esempio, così:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxPuoi anche utilizzare nomi composti come http-magic (Istio vedrà http e riconoscerà quella porta come endpoint http). Il formato è: proto-extra.
Per non applicare patch a un numero enorme di configurazioni per determinare il protocollo, è possibile utilizzare una soluzione alternativa: applicare una patch al componente Pilot nel momento in cui è appena . Alla fine, ovviamente, sarà necessario modificare questa logica in standard e passare a una convenzione di denominazione per tutte le porte.
Per capire se il protocollo è davvero definito correttamente è necessario entrare in uno qualsiasi dei contenitori sidecar con proxy envoy ed effettuare una richiesta alla porta admin dell'interfaccia envoy con posizione /config_dump. Nella configurazione risultante, è necessario esaminare il campo operativo del servizio desiderato. Viene utilizzato in Istio come identificatore del luogo in cui viene effettuata la richiesta. Per poter personalizzare il valore di questo parametro in Istio (lo vedremo poi nel nostro sistema di tracciamento), è necessario specificare il flag serviceCluster in fase di lancio del contenitore sidecar. Ad esempio, può essere calcolato in questo modo dalle variabili ottenute dall'API Kubernetes discendente:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
Un buon esempio per capire come funziona il tracciamento in Envoy è .
Anche l'endpoint stesso per l'invio degli intervalli di traccia deve essere specificato nei flag di avvio del proxy Envoy, ad esempio: --zipkinAddress tracing-collector.tracing:9411
Equivoco numero due: possiamo ottenere tracce complete delle richieste a basso costo attraverso il sistema e fuori dagli schemi
Sfortunatamente non lo è. La complessità dell'implementazione dipende da come è già stata implementata l'interazione dei servizi. Perché?
Il fatto è che affinché istio-proxy possa comprendere la corrispondenza delle richieste in entrata verso un servizio con quelle in uscita dallo stesso servizio, non è sufficiente semplicemente intercettare tutto il traffico. È necessario disporre di una sorta di identificatore di comunicazione. Il proxy HTTP Envoy utilizza intestazioni speciali, grazie alle quali Envoy comprende quale richiesta specifica al servizio genera richieste specifiche ad altri servizi. Elenco di tali intestazioni:
- ID-richiesta-x,
- x-b3-traceid,
- x-b3-spanico,
- x-b3-parentspanid,
- x-b3-campionato,
- flag x-b3,
- x-ot-span-contesto.
Se hai un singolo punto, ad esempio un client di base, in cui puoi aggiungere tale logica, allora va tutto bene, devi solo attendere che questa libreria venga aggiornata per tutti i client. Ma se hai un sistema molto eterogeneo e non c'è unificazione nel passaggio da un servizio all'altro sulla rete, molto probabilmente questo sarà un grosso problema. Senza aggiungere tale logica, tutte le informazioni di tracciamento saranno solo “a livello singolo”. Cioè riceveremo tutte le interazioni tra servizi, ma non saranno incollate in singole catene di passaggio attraverso la rete.
conclusione
Istio fornisce uno strumento utile per raccogliere informazioni di tracciamento su una rete, ma devi comprendere che per l'implementazione dovrai adattare il tuo sistema e tenere conto delle funzionalità dell'implementazione Istio. Di conseguenza, due punti principali devono essere risolti: definire il protocollo a livello di applicazione (che deve essere supportato dal proxy envoy) e impostare l'inoltro delle informazioni sulla connessione delle richieste al servizio dalle richieste del servizio (utilizzando intestazioni , nel caso del protocollo HTTP). Una volta risolti questi problemi, disponiamo di un potente strumento che ci consente di raccogliere in modo trasparente informazioni dalla rete, anche in sistemi molto eterogenei scritti in molti linguaggi e framework diversi.
Nel prossimo articolo su Service Mesh, esamineremo uno dei maggiori problemi di Istio: il grande consumo di RAM da parte di ciascun contenitore proxy sidecar e discuteremo di come gestirlo.
Fonte: habr.com