🥇Istio og Kubernetes i produksjon. Del 2. Sporing

I den siste artikkel Vi så på de grunnleggende komponentene i Service Mesh Istio, ble kjent med systemet og svarte på hovedspørsmålene som vanligvis dukker opp når man begynner å jobbe med Istio. I denne delen skal vi se på hvordan man organiserer innsamlingen av sporingsinformasjon over et nettverk.

Det første som kommer til hjernen for mange utviklere og systemadministratorer når de hører ordene Service Mesh sporer. Faktisk legger vi til en spesiell proxy-server til hver nettverksnode som all TCP-trafikk går gjennom. Det ser ut til at det nå er mulig å enkelt sende informasjon om alle nettverksinteraksjoner på nettverket. Dessverre er det i virkeligheten mange nyanser som må tas i betraktning. La oss se på dem.

Misforståelse nummer én: vi kan få online turdata gratis.

Faktisk, relativt gratis, kan vi bare koble nodene til systemet vårt med piler og datahastigheten som går mellom tjenester (faktisk bare antall byte per tidsenhet). Men i de fleste tilfeller kommuniserer tjenestene våre over en slags applikasjonslagsprotokoll, som HTTP, gRPC, Redis og så videre. Og selvfølgelig ønsker vi å se sporingsinformasjon spesifikt for disse protokollene; vi ønsker å se forespørselshastigheten, ikke datahastigheten. Vi ønsker å forstå ventetiden til forespørsler ved å bruke protokollen vår. Til slutt ønsker vi å se hele veien som en forespørsel tar fra å logge på systemet vårt til å motta et svar fra brukeren. Dette problemet er ikke lenger så lett å løse.

La oss først se på hvordan sendingssporingsspenn ser ut fra et arkitektonisk synspunkt i Istio. Som vi husker fra første del har Istio en egen komponent kalt Mixer for innsamling av telemetri. I gjeldende versjon 1.0.* skjer imidlertid sending direkte fra proxy-servere, nemlig fra envoy proxy. Envoy proxy støtter sending av sporingsspenn ved bruk av zipkin-protokollen ut av esken. Det er mulig å koble til andre protokoller, men kun gjennom en plugin. Med Istio får vi umiddelbart en samlet og konfigurert envoy proxy, som kun støtter zipkin-protokollen. Hvis vi vil bruke for eksempel Jaeger-protokollen og sende sporingsspenn via UDP, må vi bygge vårt eget istio-proxy-bilde. Det er støtte for tilpassede plugins for istio-proxy, men den er fortsatt i alfaversjonen. Derfor, hvis vi ønsker å klare oss uten et stort antall tilpassede innstillinger, reduseres utvalget av teknologier som brukes til å lagre og motta sporingsspenn. Av hovedsystemene kan du faktisk nå bruke Zipkin selv, eller Jaeger, men sende alt dit ved å bruke den zipkin-kompatible protokollen (som er mye mindre effektiv). Selve zipkin-protokollen innebærer å sende all sporingsinformasjon til samlere via HTTP-protokollen, som er ganske dyr.

Som jeg allerede har sagt, ønsker vi å spore protokoller på applikasjonsnivå. Dette betyr at proxy-serverne som står ved siden av hver tjeneste må forstå hva slags interaksjon som skjer nå. Som standard konfigurerer Istio alle porter til å være vanlig TCP, noe som betyr at ingen spor vil bli sendt. For at spor skal sendes, må du først aktivere dette alternativet i hovedmaskekonfigurasjonen og, det som er veldig viktig, navngi alle portene til kubernetes-tjenesteenheter i samsvar med protokollen som brukes i tjenesten. Det er for eksempel slik:

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

Du kan også bruke sammensatte navn som http-magic (Istio vil se http og gjenkjenne porten som et http-endepunkt). Formatet er: proto-ekstra.

For ikke å lappe et stort antall konfigurasjoner for å bestemme protokollen, kan du bruke en skitten løsning: lapp Pilot-komponenten i det øyeblikket det bare er utfører protokolldefinisjonslogikk. Til slutt vil det selvfølgelig være nødvendig å endre denne logikken til standard og bytte til en navnekonvensjon for alle porter.

For å forstå om protokollen virkelig er riktig definert, må du gå inn i en av sidevognsbeholderne med envoy proxy og sende en forespørsel til adminporten til envoy-grensesnittet med plassering /config_dump. I den resulterende konfigurasjonen må du se på operasjonsfeltet til ønsket tjeneste. Den brukes i Istio som en identifikator for hvor forespørselen gjøres. For å tilpasse verdien av denne parameteren i Istio (vi vil da se den i sporingssystemet vårt), er det nødvendig å spesifisere serviceCluster-flagget på scenen for lansering av sidevognsbeholderen. For eksempel kan det beregnes slik fra variabler hentet fra nedadgående kubernetes API:

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

Et godt eksempel for å forstå hvordan sporing fungerer i envoy er her.

Selve endepunktet for å sende sporingsspenn må også spesifiseres i utsendings proxy-lanseringsflagg, for eksempel: --zipkinAddress tracing-collector.tracing:9411

Misforståelse nummer to: vi kan billig få fullstendige spor av forespørsler gjennom systemet ut av esken

Dessverre er det ikke det. Kompleksiteten i implementeringen avhenger av hvordan du allerede har implementert samspillet mellom tjenester. Hvorfor det?

Faktum er at for at istio-proxy skal kunne forstå korrespondansen mellom innkommende forespørsler til en tjeneste med de som forlater den samme tjenesten, er det ikke nok å bare avskjære all trafikk. Du må ha en slags kommunikasjonsidentifikator. HTTP envoy proxy bruker spesielle overskrifter, som utsending forstår hvilken spesifikk forespørsel til tjenesten som genererer spesifikke forespørsler til andre tjenester. Liste over slike overskrifter:

x-forespørsel-id
x-b3-traceid,
x-b3-spanid,
x-b3-parentspanid,
x-b3-samplet,
x-b3-flagg,
x-ot-span-kontekst.

Hvis du har et enkelt punkt, for eksempel en grunnleggende klient, der du kan legge til slik logikk, så er alt bra, du trenger bare å vente på at dette biblioteket blir oppdatert for alle klienter. Men hvis du har et veldig heterogent system og det ikke er noen enhet i å gå fra tjeneste til tjeneste over nettverket, så vil dette mest sannsynlig være et stort problem. Uten å legge til slik logikk, vil all sporingsinformasjon bare være "enkeltnivå". Det vil si at vi vil motta alle inter-service interaksjoner, men de vil ikke limes inn i enkelt kjeder for passasje gjennom nettverket.

Konklusjon

Istio gir et praktisk verktøy for å samle sporingsinformasjon over et nettverk, men du må forstå at for implementering må du tilpasse systemet og ta hensyn til funksjonene til Istio-implementeringen. Som et resultat må to hovedpunkter løses: definering av applikasjonsnivåprotokollen (som må støttes av utsendingsfullmektig) og sette opp videresending av informasjon om tilkobling av forespørsler til tjenesten fra forespørsler fra tjenesten (ved hjelp av overskrifter) , når det gjelder HTTP-protokollen). Når disse problemene er løst, har vi et kraftig verktøy som lar oss på en transparent måte samle informasjon fra nettverket, selv i svært heterogene systemer skrevet på mange forskjellige språk og rammer.

I den neste artikkelen om Service Mesh skal vi se på et av de største problemene med Istio – det store forbruket av RAM for hver sidevogn proxy-beholder og diskutere hvordan du kan håndtere det.

Kilde: www.habr.com