Istio og Kubernetes i produktion. Del 2. Sporing

I fortiden artiklen Vi kiggede på de grundlæggende komponenter i Service Mesh Istio, stiftede bekendtskab med systemet og besvarede de vigtigste spørgsmål, der normalt opstår, når man begynder at arbejde med Istio. I denne del vil vi se på, hvordan man organiserer indsamlingen af ​​sporingsinformation over et netværk.

Det første, der kommer til at tænke på for mange udviklere og systemadministratorer, når de hører ordene Service Mesh sporer. Faktisk tilføjer vi en speciel proxyserver til hver netværksknude, som al TCP-trafik passerer igennem. Det ser ud til, at det nu er muligt nemt at sende information om alle netværksinteraktioner på netværket. Desværre er der i virkeligheden mange nuancer, der skal tages i betragtning. Lad os se på dem.

Misforståelse nummer et: vi kan få online vandredata gratis.

Faktisk, relativt gratis, kan vi kun få vores systems noder forbundet med pile og datahastigheden, der passerer mellem tjenester (faktisk kun antallet af bytes pr. tidsenhed). I de fleste tilfælde kommunikerer vores tjenester dog over en form for applikationslagsprotokol, såsom HTTP, gRPC, Redis og så videre. Og selvfølgelig ønsker vi at se sporingsoplysninger specifikt for disse protokoller; vi ønsker at se anmodningshastigheden, ikke datahastigheden. Vi ønsker at forstå forsinkelsen af ​​anmodninger ved hjælp af vores protokol. Endelig ønsker vi at se den fulde vej, som en anmodning tager fra at logge på vores system til at modtage et svar fra brugeren. Dette problem er ikke længere så let at løse.

Lad os først se på, hvordan afsendelsessporingsspænder ser ud fra et arkitektonisk synspunkt i Istio. Som vi husker fra første del, har Istio en separat komponent kaldet Mixer til opsamling af telemetri. I den nuværende version 1.0.* sker afsendelsen dog direkte fra proxyservere, nemlig fra envoy proxy. Envoy proxy understøtter afsendelse af sporingsspænd ved hjælp af zipkin-protokollen ud af kassen. Det er muligt at forbinde andre protokoller, men kun via et plugin. Med Istio får vi straks en samlet og konfigureret envoy proxy, som kun understøtter zipkin protokollen. Hvis vi for eksempel vil bruge Jaeger-protokollen og sende sporingsspænd via UDP, så bliver vi nødt til at bygge vores eget istio-proxy-billede. Der er understøttelse af brugerdefinerede plugins til istio-proxy, men det er stadig i alfa-versionen. Derfor, hvis vi ønsker at undvære et stort antal brugerdefinerede indstillinger, reduceres rækken af ​​teknologier, der bruges til lagring og modtagelse af sporingsspænd. Af hovedsystemerne kan du faktisk nu bruge Zipkin selv eller Jaeger, men send alt dertil ved hjælp af den zipkin-kompatible protokol (som er meget mindre effektiv). Selve zipkin-protokollen involverer at sende al sporingsinformation til samlere via HTTP-protokollen, hvilket er ret dyrt.

Som jeg allerede har sagt, ønsker vi at spore protokoller på applikationsniveau. Det betyder, at de proxy-servere, der står ved siden af ​​hver tjeneste, skal forstå, hvilken slags interaktion, der sker nu. Som standard konfigurerer Istio alle porte til at være almindelig TCP, hvilket betyder, at der ikke sendes spor. For at spor kan sendes, skal du for det første aktivere denne mulighed i hovedmesh-konfigurationen og, hvad der er meget vigtigt, navngive alle porte af kubernetes-tjenesteenheder i overensstemmelse med den protokol, der bruges i tjenesten. Det er for eksempel sådan her:

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

Du kan også bruge sammensatte navne som http-magic (Istio vil se http og genkende denne port som et http-slutpunkt). Formatet er: proto-ekstra.

For ikke at lappe et stort antal konfigurationer for at bestemme protokollen, kan du bruge en beskidt løsning: patch Pilot-komponenten i det øjeblik, hvor det bare er udfører protokoldefinitionslogik. I sidste ende vil det selvfølgelig være nødvendigt at ændre denne logik til standard og skifte til en navnekonvention for alle porte.

For at forstå, om protokollen virkelig er defineret korrekt, skal du gå ind i en af ​​sidevognsbeholderne med envoy-proxy og lave en anmodning til admin-porten på envoy-grænsefladen med placering /config_dump. I den resulterende konfiguration skal du se på driftsfeltet for den ønskede tjeneste. Det bruges i Istio som en identifikator for, hvor anmodningen er lavet. For at tilpasse værdien af ​​denne parameter i Istio (vi vil derefter se den i vores sporingssystem), er det nødvendigt at specificere serviceCluster-flaget på tidspunktet for lanceringen af ​​sidevognsbeholderen. For eksempel kan det beregnes sådan ud fra variabler opnået fra den nedadgående kubernetes API:

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

Et godt eksempel til at forstå, hvordan sporing fungerer i envoy er her.

Selve endepunktet til afsendelse af sporingsspænd skal også angives i udsendings proxy-lanceringsflag, for eksempel: --zipkinAddress tracing-collector.tracing:9411

Misforståelse nummer to: vi kan billigt få fuldstændige spor af anmodninger gennem systemet ud af boksen

Det er det desværre ikke. Kompleksiteten af ​​implementeringen afhænger af, hvordan du allerede har implementeret interaktionen af ​​tjenester. Hvorfor det?

Faktum er, at for at istio-proxy skal kunne forstå korrespondancen af ​​indgående anmodninger til en tjeneste med dem, der forlader den samme tjeneste, er det ikke nok blot at opsnappe al trafik. Du skal have en form for kommunikations-id. HTTP envoy proxy bruger specielle headers, som envoy forstår, hvilken specifik anmodning til tjenesten, der genererer specifikke anmodninger til andre tjenester. Liste over sådanne overskrifter:

• x-anmodnings-id
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-samplet,
• x-b3-flag,
• x-ot-span-kontekst.

Hvis du har et enkelt punkt, for eksempel en grundlæggende klient, hvor du kan tilføje sådan logik, så er alt fint, du skal bare vente på, at dette bibliotek bliver opdateret for alle klienter. Men hvis du har et meget heterogent system, og der ikke er nogen ensartethed i at flytte fra tjeneste til tjeneste over netværket, så vil dette højst sandsynligt være et stort problem. Uden at tilføje en sådan logik vil al sporingsinformation kun være "enkeltniveau". Det vil sige, at vi vil modtage alle inter-service interaktioner, men de vil ikke blive limet ind i enkelte kæder af passage gennem netværket.

Konklusion

Istio giver et praktisk værktøj til at indsamle sporingsoplysninger over et netværk, men du skal forstå, at du for implementering skal tilpasse dit system og tage højde for funktionerne i Istio-implementeringen. Som følge heraf skal to hovedpunkter løses: definering af applikationsniveauprotokollen (som skal understøttes af udsendingsfuldmægtigen) og opsætning af videresendelse af information om forbindelsen af ​​anmodninger til tjenesten fra anmodninger fra tjenesten (ved hjælp af overskrifter) , i tilfælde af HTTP-protokollen). Når disse problemer er løst, har vi et kraftfuldt værktøj, der giver os mulighed for transparent at indsamle information fra netværket, selv i meget heterogene systemer skrevet på mange forskellige sprog og rammer.

I den næste artikel om Service Mesh vil vi se på et af de største problemer med Istio – det store forbrug af RAM ved hver sidevogn proxy-beholder og diskutere, hvordan du kan håndtere det.

Kilde: www.habr.com