Istio i Kubernetes en producció. Part 2. Traçat

En l'últim article Vam analitzar els components bàsics de Service Mesh Istio, vam familiaritzar-nos amb el sistema i vam respondre les principals preguntes que solen sorgir en començar a treballar amb Istio. En aquesta part veurem com organitzar la recopilació d'informació de traça a través d'una xarxa.

El primer que ve al cap a molts desenvolupadors i administradors de sistemes quan escolten les paraules Service Mesh és rastrejar. De fet, afegim un servidor intermediari especial a cada node de xarxa pel qual passa tot el trànsit TCP. Sembla que ara és possible enviar fàcilment informació sobre totes les interaccions de la xarxa a la xarxa. Malauradament, en realitat hi ha molts matisos que cal tenir en compte. Mirem-los.

Concepció errònia número u: podem obtenir dades de senderisme en línia de forma gratuïta.

De fet, de manera relativament gratuïta, només podem connectar els nodes del nostre sistema mitjançant fletxes i la velocitat de dades que passa entre serveis (de fet, només el nombre de bytes per unitat de temps). Tanmateix, en la majoria dels casos, els nostres serveis es comuniquen mitjançant algun tipus de protocol de capa d'aplicació, com ara HTTP, gRPC, Redis, etc. I, per descomptat, volem veure informació de traça específica per a aquests protocols; volem veure la taxa de sol·licitud, no la taxa de dades. Volem entendre la latència de les sol·licituds mitjançant el nostre protocol. Finalment, volem veure el camí complet que pren una sol·licitud des d'iniciar sessió al nostre sistema fins a rebre una resposta de l'usuari. Aquest problema ja no és tan fàcil de resoldre.

En primer lloc, mirem com són els trams de traçat d'enviament des d'un punt de vista arquitectònic a Istio. Com recordem des de la primera part, Istio té un component separat anomenat Mixer per recollir telemetria. Tanmateix, a la versió actual 1.0.*, l'enviament es fa directament des dels servidors proxy, és a dir, des del proxy d'envoy. El proxy d'Envoy admet l'enviament de trams de traça mitjançant el protocol zipkin des de la caixa. És possible connectar altres protocols, però només mitjançant un connector. Amb Istio obtenim immediatament un proxy enviat muntat i configurat, que només admet el protocol zipkin. Si volem utilitzar, per exemple, el protocol de Jaeger i enviar traços de traçat mitjançant UDP, haurem de crear la nostra pròpia imatge d'istio-proxy. Hi ha suport per a connectors personalitzats per a istio-proxy, però encara es troba a la versió alfa. Per tant, si volem prescindir d'un gran nombre de configuracions personalitzades, el ventall de tecnologies utilitzades per emmagatzemar i rebre intervals de traça es redueix. Dels sistemes principals, de fet, ara podeu utilitzar el mateix Zipkin, o Jaeger, però enviar-ho tot mitjançant el protocol compatible amb zipkin (que és molt menys eficient). El protocol zipkin en si implica enviar tota la informació de traça als col·leccionistes mitjançant el protocol HTTP, que és bastant car.

Com ja he dit, volem traçar protocols a nivell d'aplicació. Això vol dir que els servidors intermediaris que es troben al costat de cada servei han d'entendre quin tipus d'interacció està passant ara. De manera predeterminada, Istio configura tots els ports perquè siguin TCP normal, el que significa que no s'enviarà cap rastre. Perquè s'enviïn traces cal, en primer lloc, habilitar aquesta opció a la configuració de la malla principal i, el que és molt important, anomenar tots els ports de les entitats del servei kubernetes d'acord amb el protocol que s'utilitza en el servei. Això és, per exemple, així:

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

També podeu utilitzar noms compostos com http-magic (Istio veurà http i reconeixerà aquest port com a punt final http). El format és: proto-extra.

Per no aplicar un pedaç a un gran nombre de configuracions per determinar el protocol, podeu fer servir una solució bruta: apliqueu el component Pilot en el moment en què només realitza la lògica de definició del protocol. Al final, per descomptat, caldrà canviar aquesta lògica a estàndard i canviar a una convenció de nomenclatura per a tots els ports.

Per entendre si el protocol està realment definit correctament, heu d'anar a qualsevol dels contenidors sidecar amb proxy d'envoy i fer una sol·licitud al port d'administració de la interfície d'envoy amb la ubicació /config_dump. A la configuració resultant, heu de mirar el camp d'operació del servei desitjat. S'utilitza a Istio com a identificador d'on es fa la sol·licitud. Per personalitzar el valor d'aquest paràmetre a Istio (després ho veurem al nostre sistema de traça), cal especificar la bandera serviceCluster en l'etapa de llançament del contenidor sidecar. Per exemple, es pot calcular així a partir de variables obtingudes de l'API de Kubernetes a la baixa:

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

Un bon exemple per entendre com funciona el rastreig en enviat aquí.

El punt final per a l'enviament dels intervals de traça també s'ha d'especificar als indicadors de llançament del servidor intermediari d'envoy, per exemple: --zipkinAddress tracing-collector.tracing:9411

Concepció errònia número dos: podem obtenir rastres complets de sol·licituds a través del sistema de manera econòmica

Malauradament, no ho és. La complexitat de la implementació depèn de com ja hàgiu implementat la interacció dels serveis. Per què això?

El cas és que perquè istio-proxy pugui entendre la correspondència de les peticions entrants a un servei amb les que surten del mateix servei, no n'hi ha prou amb simplement interceptar tot el trànsit. Heu de tenir algun tipus d'identificador de comunicació. El servidor intermediari HTTP Envoy utilitza capçaleres especials, mitjançant les quals l'envoy entén quina sol·licitud específica al servei genera sol·licituds específiques a altres serveis. Llista d'aquestes capçaleres:

• x-request-id
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• mostreig x-b3,
• x-b3-banderes,
• x-ot-span-context.

Si teniu un únic punt, per exemple, un client bàsic, al qual podeu afegir aquesta lògica, aleshores tot està bé, només heu d'esperar que aquesta biblioteca s'actualitzi per a tots els clients. Però si teniu un sistema molt heterogeni i no hi ha cap unificació per passar d'un servei a un altre a través de la xarxa, és probable que això sigui un gran problema. Sense afegir aquesta lògica, tota la informació de traça només serà "d'un sol nivell". És a dir, rebrem totes les interaccions entre serveis, però no estaran enganxades en cadenes úniques de pas per la xarxa.

Conclusió

Istio proporciona una eina convenient per recopilar informació de traça a través d'una xarxa, però heu d'entendre que per a la implementació haureu d'adaptar el vostre sistema i tenir en compte les característiques de la implementació d'Istio. Com a resultat, s'han de resoldre dos punts principals: definir el protocol a nivell d'aplicació (que ha de ser compatible amb el proxy d'envoy) i configurar el reenviament d'informació sobre la connexió de sol·licituds al servei a partir de sol·licituds del servei (utilitzant capçaleres). , en el cas del protocol HTTP). Quan es resolen aquests problemes, disposem d'una potent eina que ens permet recollir de manera transparent informació de la xarxa, fins i tot en sistemes molt heterogenis escrits en molts llenguatges i marcs diferents.

Al següent article sobre Service Mesh, analitzarem un dels problemes més grans amb Istio: el gran consum de memòria RAM de cada contenidor de proxy sidecar i parlarem de com podeu fer-hi front.

Font: www.habr.com