Istio è Kubernetes in pruduzzione. Part 2. Tracing

In l'ultimu articulu Fighjemu à i cumpunenti basi di Service Mesh Istio, cunniscenza di u sistema è rispose à e dumande principali chì sò generalmente sorgi quandu si cumincianu à travaglià cù Istio. In questa parte, avemu da vede cumu urganizà a cullizzioni di l'infurmazioni di traccia nantu à una reta.

A prima cosa chì vene in mente per parechji sviluppatori è amministratori di sistema quandu sentenu e parolle Service Mesh hè traccia. In verità, aghjustemu un servitore proxy speciale à ogni nodu di a rete attraversu quale passa tuttu u trafficu TCP. Sembra chì avà hè pussibule di mandà facilmente infurmazioni nantu à tutte l'interazzione di a rete in a reta. Sfurtunatamente, in a realità ci sò parechje sfumature chì deve esse cunsideratu. Fighjemu à elli.

Misconception numeru unu: pudemu uttene dati di caminata in linea gratuitamente.

In fattu, per relativamente liberu, pudemu solu ottene i nodi di u nostru sistema cunnessi da frecce è a tarifa di dati chì passa trà i servizii (in fattu, solu u numeru di bytes per unità di tempu). In ogni casu, in a maiò parte di i casi, i nostri servizii cumunicanu annantu à qualchì tipu di protokollu di capa d'applicazione, cum'è HTTP, gRPC, Redis, etc. E, sicuru, vulemu vede l'infurmazioni di traccia specificamente per questi protokolli; vulemu vede a tarifa di dumanda, micca a tarifa di dati. Vulemu capisce a latenza di e dumande utilizendu u nostru protocolu. Infine, vulemu vede u percorsu sanu chì una dumanda piglia da u logu in u nostru sistema à riceve una risposta da l'utilizatore. Stu prublema ùn hè più cusì faciule da risolve.

Prima, fighjemu ciò chì l'invio di spans di traccia s'assumiglia da un puntu di vista architettonicu in Istio. Cumu ricurdamu da a prima parte, Istio hà un cumpunente separatu chjamatu Mixer per a cullizzioni di telemetria. In ogni casu, in a versione attuale 1.0.*, l'inviu hè fattu direttamente da i servitori proxy, à dì, da u proxy mandatu. Envoy proxy supporta l'invio di spans di traccia cù u protokollu zipkin fora di a scatula. Hè pussibule di cunnette altri protokolli, ma solu per un plugin. Cù Istio ricevemu immediatamente un proxy mandatu assemblatu è cunfiguratu, chì sustene solu u protocolu zipkin. Se vulemu usà, per esempiu, u protokollu Jaeger è mandà tracing spans via UDP, allora avemu bisognu di custruisce a nostra propria image istio-proxy. Ci hè supportu per i plugins persunalizati per istio-proxy, ma hè sempre in a versione alfa. Dunque, se vulemu fà senza un gran numaru di paràmetri persunalizati, a gamma di tecnulugia utilizata per almacenà è riceve spazii di traccia hè ridutta. Di i sistemi principali, in fattu, avà pudete aduprà Zipkin stessu, o Jaeger, ma mandate tuttu quì cù u protocolu compatible zipkin (chì hè assai menu efficace). U protokollu zipkin stessu implica l'inviu di tutte l'infurmazioni di traccia à i cullezzione via u protocolu HTTP, chì hè abbastanza caru.

Cumu l'aghju digià dettu, vulemu tracciate protokolli à livellu di l'applicazione. Questu significa chì i servitori proxy chì si trovanu accantu à ogni serviziu devenu capisce chì tipu d'interazzione succede avà. Per automaticamente, Istio cunfigurà tutti i porti per esse TCP pianu, chì significa chì nisuna traccia serà mandata. Per esse mandati tracce, deve, prima, attivà sta opzione in a cunfigurazione di a rete principale è, ciò chì hè assai impurtante, nome tutti i porti di l'entità di serviziu di kubernetes in cunfurmità cù u protocolu chì hè utilizatu in u serviziu. Questu hè, per esempiu, cusì:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

Pudete ancu aduprà nomi cumposti cum'è http-magic (Istio vede http è ricunnosce quellu portu cum'è un endpoint http). U furmatu hè: proto-extra.

Per ùn patch un gran numaru di cunfigurazioni per determinà u protokollu, pudete aduprà una soluzione brutta: patch u cumpunente Pilot in u mumentu quandu hè ghjustu. esegue a logica di definizione di u protocolu. À a fine, sicuru, serà necessariu di cambià sta logica à standard è cambià à una cunvenzione di nomi per tutti i porti.

Per capisce chì u protokollu hè veramente definitu currettamente, avete bisognu à andà in qualsiasi di i cuntenituri sidecar cù proxy d'envoy è fà una dumanda à u portu amministratore di l'interfaccia di l'envoy cù locu /config_dump. In a cunfigurazione resultanti, avete bisognu à guardà u campu di operazione di u serviziu desideratu. Hè utilizatu in Istio cum'è identificatore per induve a dumanda hè fatta. Per persunalizà u valore di stu paràmetru in Istio (veremu dopu in u nostru sistema di traccia), hè necessariu di specificà a bandiera serviceCluster in u stadiu di lanciazione di u containeru sidecar. Per esempiu, pò esse calculatu cusì da variàbili ottenuti da l'API downward kubernetes:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

Un bon esempiu per capisce cumu u travagliu di traccia in envoy hè ccà.

L'endpoint stessu per mandà spazii di traccia deve esse ancu specificatu in i bandieri di lanciamentu di proxy di l'envoy, per esempiu: --zipkinAddress tracing-collector.tracing:9411

Misconception numeru dui: pudemu ottene tracce cumplete di richieste attraversu u sistema fora di a scatula

Sfurtunatamente, ùn hè micca. A cumplessità di l'implementazione dipende da cumu avete digià implementatu l'interazzione di servizii. Perchè hè questu?

U fattu hè chì, per istio-proxy per pudè capisce a currispundenza di e dumande entrate à un serviziu cù quelli chì abbandunonu u stessu serviziu, ùn hè micca abbastanza per interceptà tuttu u trafficu. Avete bisognu di avè qualchì tipu d'identificatore di cumunicazione. U proxy di l'envoy HTTP usa intestazioni speciali, per quale l'envoy capisce quale dumanda specifica à u serviziu genera richieste specifiche à altri servizii. Lista di tali intestazioni:

• x-request-id,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-sampled,
• x-b3-bandiere,
• x-ot-span-context.

Se tenete un puntu unicu, per esempiu, un cliente basicu, in quale pudete aghjunghje una tale logica, allora tuttu hè bè, basta à aspittà chì sta biblioteca sia aghjurnata per tutti i clienti. Ma s'ellu avete un sistema assai eterogeneu è ùn ci hè micca unificazione in u muvimentu da u serviziu à u serviziu nantu à a reta, allora questu serà probabilmente un grande prublema. Senza aghjunghje una tale logica, tutte l'infurmazioni di traccia seranu solu "livellu unicu". Questu hè, riceveremu tutte l'interazzione inter-serviziu, ma ùn saranu micca incollati in catene uniche di passaghju per a reta.

cunchiusioni

Istio furnisce un strumentu convenientu per cullà l'infurmazioni di traccia nantu à una reta, ma duvete capisce chì per l'implementazione vi tuccherà à adattà u vostru sistema è piglià in contu e caratteristiche di l'implementazione Istio. In u risultatu, dui punti principali anu da esse risolti: definisce u protocolu di livellu di l'applicazione (chì deve esse supportatu da u proxy di l'envoy) è stabilisce l'invio di l'infurmazioni nantu à a cunnessione di e dumande à u serviziu da e dumande da u serviziu (usendu headers). , in u casu di u protocolu HTTP). Quandu sti prublemi sò risolti, avemu un strumentu putente chì ci permette di cullà in modu trasparente l'infurmazioni da a reta, ancu in sistemi assai eterogenei scritti in parechje lingue è frameworks diffirenti.

In u prossimu articulu nantu à Service Mesh, fighjemu unu di i più grandi prublemi cù Istio - u grande cunsumu di RAM da ogni containeru proxy sidecar è discute cumu si pò trattà cun ella.

Source: www.habr.com