Istio och Kubernetes i produktion. Del 2. Tracing

Tidigare artikeln Vi har granskat de grundläggande komponenterna i Service Mesh Istio, bekantat oss med systemet och besvarat de viktigaste frågor som ofta uppstår i början av arbetet med Istio. I den här delen kommer vi att titta på hur man organiserar insamlingen av tracinginformation över nätverket.

Det första som många utvecklare och systemadministratörer tänker på när de hör orden Service Mesh är tracing. Och faktum är att vi lägger till en speciell proxyserver i varje nod i nätverket, som all TCP-trafik passerar genom. Det verkar som att det nu blir enkelt att skicka information om alla nätverksinteraktioner i nätverket. Tyvärr dyker det upp många nyanser i verkligheten som måste beaktas. Låt oss ta en titt på dem.

Missuppfattning nummer ett: vi kan gratis få data om nätverksanvändning.

I verkligheten kan vi bara relativt gratis få de sammanlänkade noderna i vårt system markerade med pilar och datarate som passerar mellan tjänsterna (i huvudsak bara antalet byte per tidsenhet). Men i de flesta fall kommunicerar våra tjänster över något applikationsprotokoll, som HTTP, gRPC, Redis och så vidare. Och, naturligtvis, vill vi se tracinginformation just för dessa protokoll, vi vill se rate av förfrågningar, snarare än rate av data. Vi vill förstå latensen av förfrågningar enligt vårt protokoll. Slutligen vill vi se hela vägen som förfrågan går från inträde i vårt system till att användaren får svar. Denna uppgift är inte så enkel att lösa.

Först, låt oss titta på hur sändningen av tracing spans ser ut ur ett arkitekturperspektiv i Istio. Som vi minns från första delen, har Istio en separat komponent för insamling av telemetry som kallas Mixer. Men i den nuvarande versionen 1.0.* sker sändningen direkt från proxyservrar, specifikt från envoy proxy. Envoy proxy stödjer sändning av tracing spans via zipkin-protokollet direkt ur lådan. Andra protokoll kan anslutas, men endast via ett plugin. Med Istio får vi omedelbart en konfigurerad och sammanställd envoy proxy, där endast zipkin-protokollet stöds. Om vi vill använda till exempel Jaeger-protokollet och skicka tracing spans via UDP, måste vi bygga vår egen istio-proxy bild. Stödet för anpassade plugins för istio-proxy finns, men är fortfarande i alpha-version. Därför, om vi vill undvika ett stort antal anpassade inställningar, minskar den teknologiska cirkeln för lagring och mottagning av tracing spans. Från de grundläggande systemen kan vi just nu i praktiken använda antingen Zipkin eller Jaeger, men skicka allt via ett zipkin-kompatibelt protokoll (vilket är betydligt mindre effektivt). Zipkin-protokollet innebär att all tracinginformation skickas till insamlare via HTTP-protokollet, vilket är ganska kostsamt.

Som jag redan nämnt, vill vi spåra applikationsprotokoll. Det innebär att proxyservrarna som står bredvid varje tjänst måste förstå vilken interaktion som sker just nu. Som standard konfigurerar Istio alla portar som ren TCP, vilket innebär att inga spans kommer att skickas. För att spans ska skickas måste vi först aktivera den här funktionen i huvud mesh-config och, vilket är mycket viktigt, namnge alla portar i kubernetes service-enheter i enlighet med det protokoll som används i tjänsten. Det vill säga, till exempel så här:

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

Vi kan också använda sammansatta namn, till exempel http-magic (Istio kommer att se http och känna igen den här porten som en http-endpoint). Formatet är: proto-extra.

För att undvika att patcha ett stort antal konfigurationer för att definiera protokoll, kan vi använda en smutsig workaround: patcha Pilot-komponenten just när den utför logiken för protokollbestämning.. I slutändan måste dessa logik självklart justeras till standard och följa namngivningskonventionen för alla portar.

För att verkligen förstå om protokollet är korrekt definierat måste vi gå in i en av sidecar-kontainrarna med envoy proxy och göra en begäran till admin-gränssnittets port för envoy med platsen /config_dump. I den resulterande konfigurationen bör vi titta på operation-fältet för den nödvändiga tjänsten. Den används i Istio som en identifierare för vart begäran går. För att anpassa värdet på denna parameter i Istio (vi kommer sedan att se det i vårt spårningssystem), måste vi ange flaggan serviceCluster vid starten av sidecar-kontainern. Till exempel kan den beräknas på detta sätt från variabler som fåtts från Kubernetes downward API:

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

Ett bra exempel för att förstå hur spårning fungerar i envoy är ). Ett typiskt exempel på användning:.

Själva slutpunkten för att skicka tracing spans måste också anges i flaggorna vid start av envoy proxy, till exempel: --zipkinAddress tracing-collector.tracing:9411

Missuppfattning nummer två: vi kan billigt få fullständiga spår av begärors genomgång genom systemet ur lådan.

Tyvärr är det inte så. Svårighetsgraden av implementeringen beror på hur din nuvarande tjänsteinteraktion är implementerad. Varför är det så?

Tanken är att för att istio-proxy ska kunna förstå kopplingen mellan inkommande begärningar till tjänsten och utgående från samma tjänst är det inte tillräckligt att bara fånga all trafik. Något slags samband-identifierare behövs. I HTTP envoy proxy används speciella rubriker, genom vilka envoy förstår vilken specifik begäran till tjänsten som genererar specifika begärningar till andra tjänster. Listan över sådana rubriker är:

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

Om ni har en enhetlig punkt, till exempel en grundläggande klient där denna logik kan läggas till, så är allt bra, ni behöver bara vänta på att detta bibliotek uppdateras hos alla kunder. Men om ni har ett mycket heterogent system utan enhetlighet i hur tjänsterna interagerar över nätverket kommer detta sannolikt att bli ett stort problem. Utan att lägga till liknande logik kommer all spårningsinformation att vara "endimensionell". Det innebär att vi får alla interaktioner mellan tjänsterna, men de kommer inte att kopplas ihop till en sammanhängande kedja över nätverket.

Slutsats

Istio erbjuder ett användarvänligt verktyg för att samla in spårningsinformation över nätverket, men det är viktigt att förstå att implementeringen kräver anpassningar av ditt system och att man beaktar de unika aspekterna av Istios implementation. I slutändan behöver man lösa två huvudfrågor: definiera applikationsprotokollet (som måste stödjas av envoy proxy) och konfigurera överföringen av information om sammankopplingen av förfrågningar till tjänsten från förfrågningar inom tjänsten (genom headers, i fallet med HTTP-protokollet). När dessa frågor är lösta får vi ett kraftfullt verktyg som gör det möjligt att transparently samla in information från nätverket även i mycket heterogena system skrivna i många olika språk och ramverk.

I nästa artikel om Service Mesh kommer vi att titta på ett av de största problemen med Istio – den stora minnesanvändningen av varje sidecar proxy-container och diskutera hur man kan hantera detta.

Källa: habr.com