Istio och Kubernetes i produktion. Del 2. Spårning

Förr artikeln Vi tittade på grundkomponenterna i Service Mesh Istio, bekantade oss med systemet och svarade på huvudfrågorna som brukar dyka upp när man börjar arbeta med Istio. I den här delen kommer vi att titta på hur man organiserar insamlingen av spårningsinformation över ett nätverk.

Det första som kommer att tänka på för många utvecklare och systemadministratörer när de hör orden Service Mesh spårar. Faktum är att vi lägger till en speciell proxyserver till varje nätverksnod genom vilken all TCP-trafik passerar. Det verkar som att det nu är möjligt att enkelt skicka information om alla nätverksinteraktioner på nätverket. Tyvärr finns det i verkligheten många nyanser som måste beaktas. Låt oss titta på dem.

Missuppfattning nummer ett: vi kan få online vandringsdata gratis.

I själva verket, relativt gratis, kan vi bara få noderna i vårt system anslutna med pilar och datahastigheten som passerar mellan tjänster (i själva verket bara antalet byte per tidsenhet). Men i de flesta fall kommunicerar våra tjänster över något slags applikationslagerprotokoll, som HTTP, gRPC, Redis och så vidare. Och naturligtvis vill vi se spårningsinformation specifikt för dessa protokoll; vi vill se förfrågningshastigheten, inte datahastigheten. Vi vill förstå fördröjningen av förfrågningar med vårt protokoll. Slutligen vill vi se den fullständiga vägen som en förfrågan tar från att logga in i vårt system till att få ett svar från användaren. Detta problem är inte längre så lätt att lösa.

Låt oss först titta på hur sändningsspårningsspann ser ut ur en arkitektonisk synvinkel i Istio. Som vi minns från första delen har Istio en separat komponent som heter Mixer för insamling av telemetri. I den nuvarande versionen 1.0.* sker sändningen dock direkt från proxyservrar, nämligen från envoy proxy. Envoy proxy stöder sändning av spårningsintervall med zipkin-protokollet direkt. Det är möjligt att ansluta andra protokoll, men endast genom en plugin. Med Istio får vi omedelbart en monterad och konfigurerad envoy-proxy, som endast stöder zipkin-protokollet. Om vi ​​till exempel vill använda Jaeger-protokollet och skicka spårningsspann via UDP, måste vi bygga vår egen istio-proxy-bild. Det finns stöd för anpassade plugins för istio-proxy, men det finns fortfarande i alfaversionen. Därför, om vi vill klara oss utan ett stort antal anpassade inställningar, reduceras utbudet av teknologier som används för att lagra och ta emot spårningsintervall. Av huvudsystemen kan du faktiskt nu använda Zipkin själv, eller Jaeger, men skicka allt dit med det zipkin-kompatibla protokollet (vilket är mycket mindre effektivt). Själva zipkin-protokollet innebär att all spårningsinformation skickas till samlare via HTTP-protokollet, vilket är ganska dyrt.

Som jag redan sa vill vi spåra protokoll på applikationsnivå. Det betyder att proxyservrarna som står bredvid varje tjänst måste förstå vilken typ av interaktion som sker nu. Som standard konfigurerar Istio alla portar att vara vanlig TCP, vilket innebär att inga spår kommer att skickas. För att spår ska kunna skickas måste du först aktivera detta alternativ i huvudnätkonfigurationen och, vad som är mycket viktigt, namnge alla portar för kubernetes tjänstentiteter i enlighet med protokollet som används i tjänsten. Det är till exempel så här:

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

Du kan också använda sammansatta namn som http-magic (Istio kommer att se http och känna igen den porten som en http-slutpunkt). Formatet är: proto-extra.

För att inte lappa ett stort antal konfigurationer för att bestämma protokollet kan du använda en smutsig lösning: korrigera Pilot-komponenten i det ögonblick då det bara är utför protokolldefinitionslogik. I slutändan kommer det naturligtvis att bli nödvändigt att ändra denna logik till standard och byta till en namnkonvention för alla portar.

För att förstå om protokollet verkligen är korrekt definierat måste du gå in i någon av sidovagnscontainrarna med envoy-proxy och göra en begäran till administratörsporten för envoy-gränssnittet med plats /config_dump. I den resulterande konfigurationen måste du titta på operationsfältet för den önskade tjänsten. Den används i Istio som en identifierare för var begäran görs. För att kunna anpassa värdet på denna parameter i Istio (vi kommer då att se det i vårt spårningssystem), är det nödvändigt att specificera serviceCluster-flaggan vid lanseringen av sidovagnsbehållaren. Till exempel kan det beräknas så här från variabler som erhålls från det nedåtgående kubernetes 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 här.

Själva slutpunkten för att skicka spårningsintervall måste också anges i envoy proxy lanseringsflaggor, till exempel: --zipkinAddress tracing-collector.tracing:9411

Missuppfattning nummer två: vi kan billigt få fullständiga spår av förfrågningar genom systemet ur lådan

Tyvärr är det inte det. Komplexiteten i implementeringen beror på hur du redan har implementerat interaktionen mellan tjänster. Varför är det så?

Faktum är att för att istio-proxy ska kunna förstå överensstämmelsen mellan inkommande förfrågningar till en tjänst med de som lämnar samma tjänst räcker det inte att helt enkelt avlyssna all trafik. Du måste ha någon form av kommunikationsidentifierare. HTTP envoy proxy använder speciella rubriker, genom vilka envoy förstår vilken specifik begäran till tjänsten som genererar specifika förfrågningar till andra tjänster. Lista över sådana rubriker:

• x-request-id
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-samplade,
• x-b3-flaggor,
• x-ot-span-kontext.

Om du har en enda punkt, till exempel en grundläggande klient, där du kan lägga till sådan logik, är allt bra, du behöver bara vänta på att det här biblioteket ska uppdateras för alla klienter. Men om du har ett väldigt heterogent system och det inte finns någon enhet i att flytta från tjänst till tjänst över nätverket, så kommer detta med största sannolikhet att vara ett stort problem. Utan att lägga till sådan logik kommer all spårningsinformation endast att vara "en nivå". Det vill säga, vi kommer att ta emot alla inter-tjänstinteraktioner, men de kommer inte att limmas i enstaka kedjor av passage genom nätverket.

Slutsats

Istio tillhandahåller ett bekvämt verktyg för att samla in spårningsinformation över ett nätverk, men du måste förstå att du för implementering måste anpassa ditt system och ta hänsyn till funktionerna i Istio-implementeringen. Som ett resultat måste två huvudpunkter lösas: att definiera protokollet på applikationsnivå (som måste stödjas av envoy proxy) och ställa in vidarebefordran av information om anslutningen av förfrågningar till tjänsten från förfrågningar från tjänsten (med hjälp av rubriker , i fallet med HTTP-protokollet). När dessa problem är lösta har vi ett kraftfullt verktyg som gör att vi på ett transparent sätt kan samla in information från nätverket, även i mycket heterogena system skrivna på många olika språk och ramar.

I nästa artikel om Service Mesh kommer vi att titta på ett av de största problemen med Istio – den stora förbrukningen av RAM för varje sidovagnsproxycontainer och diskutera hur du kan hantera det.

Källa: will.com