An der leschter Mir hunn d'Basiskomponente vum Service Mesh Istio ugekuckt, eis mam System vertraut gemaach an d'Haaptfroen beäntwert, déi normalerweis entstinn wann Dir mat Istio ufänkt ze schaffen. An dësem Deel wäerte mir kucken wéi d'Sammlung vun Tracing Informatioun iwwer e Netzwierk organiséiert gëtt.
Déi éischt Saach déi fir vill Entwéckler a Systemadministratoren am Kapp kënnt wann se d'Wierder héieren Service Mesh ass Tracing. Tatsächlech addéiere mir e spezielle Proxy-Server fir all Netzknuet, duerch deen all TCP-Traffic passéiert. Et schéngt, datt et elo méiglech ass einfach Informatiounen iwwer all Netzwierkinteraktiounen am Netz ze schécken. Leider sinn et an der Realitéit vill Nuancen, déi berücksichtegt musse ginn. Loosst eis se kucken.
Mëssverständnis Nummer eent: mir kënnen online Spadséier- daten gratis.
Tatsächlech, relativ gratis, kënne mir nëmmen d'Node vun eisem System duerch Pfeile verbonne kréien an d'Datenrate déi tëscht Servicer passéiert (tatsächlech nëmmen d'Zuel vun de Bytes pro Zäitunitéit). Wéi och ëmmer, an de meeschte Fäll kommunizéieren eis Servicer iwwer eng Aart vun Uwendungsschichtprotokoll, wéi HTTP, gRPC, Redis, asw. An natierlech wëlle mir Tracinginformatioun speziell fir dës Protokoller gesinn; mir wëllen den Ufroquote gesinn, net d'Datenquote. Mir wëllen d'Latenz vun Ufroe verstoen mat eisem Protokoll. Schlussendlech wëlle mir de ganze Wee gesinn, deen eng Ufro hëlt vum Umeldung an eise System bis zur Äntwert vum Benotzer. Dëse Problem ass net méi sou einfach ze léisen.
Als éischt kucke mer wéi d'Versend Tracing Spann aus enger architektonescher Siicht an Istio ausgesäit. Wéi mir aus dem éischten Deel erënneren, huet Istio eng separat Komponent genannt Mixer fir Telemetrie sammelen. Wéi och ëmmer, an der aktueller Versioun 1.0.* gëtt d'Sendung direkt vu Proxy-Server gemaach, nämlech vum Envoy Proxy. Envoy Proxy ënnerstëtzt d'Verschécken vun Tracingspann mam Zipkin Protokoll aus der Këscht. Et ass méiglech aner Protokoller ze verbannen, awer nëmmen duerch e Plugin. Mat Istio kréien mir direkt e versammelt a konfiguréiert Envoy Proxy, deen nëmmen den Zipkin Protokoll ënnerstëtzt. Wa mir zum Beispill de Jaeger Protokoll benotze wëllen an Tracingspann iwwer UDP schécken, da musse mir eisen eegene istio-Proxy-Bild bauen. Et gëtt Ënnerstëtzung fir personaliséiert Plugins fir istio-Proxy, awer et ass nach ëmmer an der Alpha Versioun. Dofir, wa mir wëllen ouni eng grouss Zuel vu personaliséierten Astellungen maachen, gëtt d'Gamme vun Technologien, déi benotzt gi fir Tracingspann ze späicheren an ze kréien, reduzéiert. Vun den Haaptsystemer, tatsächlech, kënnt Dir Zipkin selwer benotzen, oder Jaeger, awer schéckt alles dohinner mam Zipkin-kompatibele Protokoll (wat vill manner effizient ass). Den Zipkin-Protokoll selwer beinhalt d'Schécken vun all Tracing-Informatioun un Sammler iwwer den HTTP-Protokoll, wat zimlech deier ass.
Wéi ech scho gesot hunn, wëlle mir Protokoller op Applikatiounsniveau verfollegen. Dëst bedeit datt d'Proxy-Server, déi nieft all Service stinn, musse verstoen wat fir eng Interaktioun elo geschitt. Par défaut konfiguréiert Istio all Häfen fir einfach TCP ze sinn, dat heescht datt keng Spure geschéckt ginn. Fir Spure geschéckt ze ginn, musst Dir als éischt dës Optioun an der Haaptmesh-Konfiguratioun aktivéieren an, wat ganz wichteg ass, all Ports vun de kubernetes-Service-Entitéiten nennen am Aklang mat dem Protokoll deen am Service benotzt gëtt. Dat ass zum Beispill esou:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxDir kënnt och zesummegesate Nimm wéi http-magic benotzen (Istio wäert http gesinn an deen Hafen als http Endpunkt erkennen). Format ass: proto-extra.
Fir net eng grouss Zuel vu Konfiguratiounen ze patchen fir de Protokoll ze bestëmmen, kënnt Dir eng dreckeg Léisung benotzen: Patch de Pilot Komponent am Moment wou et just ass . Um Enn wäert et natierlech néideg sinn dës Logik op Standard z'änneren an op eng Nummkonventioun fir all Häfen ze wiesselen.
Fir ze verstoen ob de Protokoll wierklech richteg definéiert ass, musst Dir an ee vun de Sidecar Container mat Envoy Proxy goen an eng Ufro un den Admin Hafen vun der Envoy Interface mat Location /config_dump maachen. An der resultéierender Konfiguratioun musst Dir d'Operatiounsfeld vum gewënschten Service kucken. Et gëtt an Istio als Identifizéierer benotzt fir wou d'Ufro gemaach gëtt. Fir de Wäert vun dësem Parameter an Istio ze personaliséieren (mir wäerten et dann an eisem Tracing System gesinn), ass et néideg de ServiceCluster Fändel an der Etapp vum Start vum Sidecar Container ze spezifizéieren. Zum Beispill kann et esou berechent ginn aus Variablen, déi aus der downward kubernetes API kritt ginn:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
E gutt Beispill fir ze verstoen wéi Tracing am Envoy funktionnéiert ass .
Den Endpunkt selwer fir Tracing Spann ze schécken muss och an den Envoy Proxy Start Fändelen spezifizéiert ginn, zum Beispill: --zipkinAddress tracing-collector.tracing:9411
Mëssverständnis Nummer zwee: mir kënnen gënschteg komplett Spuere vun Ufroen duerch de System aus der Këscht kréien
Leider ass et net. D'Komplexitéit vun der Ëmsetzung hänkt dovun of wéi Dir d'Interaktioun vu Servicer scho implementéiert hutt. Firwat?
D'Tatsaach ass datt fir datt d'Istio-Proxy d'Korrespondenz vun erakommen Ufroe fir e Service mat deenen déi de selwechte Service verloossen kann verstoen, ass et net genuch fir all Traffic einfach z'ënnerscheeden. Dir musst eng Zort Kommunikatiounsidentifizéierer hunn. HTTP Envoy Proxy benotzt speziell Header, duerch déi den Envoy versteet wéi eng spezifesch Ufro un de Service spezifesch Ufroe fir aner Servicer generéiert. Lëscht vun esou Header:
- x-Ufro-ID
- x-b3-traceid,
- x-b3-spanid,
- x-b3-parentspanid,
- x-b3-probéiert,
- x-b3-Fändele,
- x-ot-span-kontext.
Wann Dir en eenzege Punkt hutt, zum Beispill e Basisclient, an deem Dir esou Logik addéiere kënnt, dann ass alles gutt, Dir musst just waarden bis dës Bibliothéik fir all Client aktualiséiert gëtt. Awer wann Dir e ganz heterogene System hutt an et gëtt keng Vereenegung beim Plënneren vum Service zum Service iwwer dem Netz, da wäert dëst héchstwahrscheinlech e grousse Problem sinn. Ouni esou Logik bäizefügen, wäert all Tracinginformatioun nëmmen "Single-Level" sinn. Dat ass, mir kréien all Inter-Service Interaktiounen, awer si ginn net an eenzel Passageketten duerch d'Netz gekollt.
Konklusioun
Istio bitt e praktescht Tool fir Tracing Informatioun iwwer e Netzwierk ze sammelen, awer Dir musst verstoen datt Dir fir d'Ëmsetzung Äre System unzepassen an d'Features vun der Istio Implementatioun berücksichtegen. Als Resultat mussen zwee Haaptpunkte geléist ginn: d'Definitioun vum Applikatiounsniveau Protokoll (dee muss vum Envoy Proxy ënnerstëtzt ginn) an d'Opstellung vun der Forwarding vun Informatioun iwwer d'Verbindung vun Ufroe mam Service aus Ufroe vum Service (mat Hëllef vun Header) , am Fall vum HTTP-Protokoll). Wann dës Themen geléist ginn, hu mir e mächtegt Tool dat eis erlaabt transparent Informatioun aus dem Netz ze sammelen, och a ganz heterogen Systemer, déi a ville verschiddene Sproochen a Kaderen geschriwwe sinn.
Am nächsten Artikel iwwer Service Mesh wäerte mir op ee vun de gréisste Problemer mat Istio kucken - de grousse Konsum vun RAM vun all Sidecar Proxy Container an diskutéieren wéi Dir mat et ëmgoen kann.
Source: will.com