Istio in Kubernetes v produkciji. Del 2. Sledenje

V prejšnjem članku smo pregledali osnovne komponente Service Mesh Istio, se spoznali s sistemom ter odgovorili na osnovna vprašanja, ki se običajno pojavijo ob začetku dela z Istio. V tem delu bomo pogledali, kako organizirati zbiranje informacij za sledenje po omrežju.

Prvo, kar mnogim razvijalcem in sistemskim administratorjem pride na misel, ko slišijo besede Service Mesh — je sledenje. In res je, dodajamo posebni proxy strežnik v vsak vozlišče omrežja, skozi katerega prehaja ves TCP promet. Zdi se, da lahko zdaj enostavno pošiljamo informacije o vseh omrežnih interakcijah. Na žalost se v resnici pojavi veliko podrobnosti, ki jih je treba upoštevati. Poglejmo jih.

Mit številka ena: lahko brezplačno pridobimo podatke o potovanju po omrežju

V resnici lahko relativno brezplačno pridobimo le povezane vozlišča našega sistema in hitrost podatkov, ki prehajajo med storitvami (v bistvu — le količino bajtov na časovno enoto). Vendar se v večini primerov naše storitve med seboj pogovarjajo po kakšnem protokolu aplikacijske ravni, kot so HTTP, gRPC, Redis itd. In seveda želimo videti informacije za sledenje natančno po teh protokolih, želimo videti hitrost zahtevkov, ne pa hitrost podatkov. Želimo razumeti zakasnitve zahtevkov pri našem protokolu. Končno, želimo videti celotno pot, ki jo zahteva od vhodnega mesta v naš sistem do prejetja odgovora uporabnika. Ta naloga pa ni tako preprosta.

Najpre poglejmo, kako izgleda pošiljanje tracing spanov z vidika arhitekture v Istio. Kot smo si zapomnili iz prvega dela, ima Istio za zbiranje telemetrije poseben komponent, imenovan Mixer. V trenutni različici 1.0.* se pošiljanje izvaja neposredno s proxy strežnikov, torej z envoy proxy. Envoy proxy že podpira pošiljanje tracing spanov preko protokola zipkin. Druge protokole je mogoče povezati, a le prek vtičnika. Z Istio takoj dobimo že zbran in nastavljen envoy proxy, ki podpira le protokol zipkin. Če želimo uporabiti na primer protokol Jaeger in pošiljati tracing spane preko UDP, bomo morali zbrati svojo sliko istio-proxy. Podpirajo se prilagojeni vtičniki za istio-proxy, vendar je ta funkcionalnost trenutno še v alpha različici. Zato, če želimo delati brez velikega števila prilagojenih nastavitev, se zmanjša krog uporabljenih tehnologij za shranjevanje in prejemanje tracing spanov. Od glavni sistemov lahko dejansko teraz uporabimo sam Zipkin ali Jaeger, vendar moramo vse pošiljati po protokolu, združljivim z zipkin (kar je precej manj učinkovito). Sam zipkin protokol predvideva pošiljanje vseh informacij o sledenju kolektorjem preko HTTP protokola, kar je precej obremenjujoče.

Kot sem že omenil, želimo slediti protokolom aplikativne ravni. To pomeni, da morajo proxy strežniki, ki stojijo poleg vsakega storitve, razumeti, katero natančno interakcijo trenutno poteka. Privzeto, Istio nastavi vse porte na tip plain TCP, kar pomeni, da se ne bodo pošiljali nobeni tracevi. Da bi se tracevi pošiljali, je najprej treba omogočiti to možnost v glavnem mesh configu in, kar je zelo pomembno, poimenovati vse porte pri entitetah storitev kubernetes v skladu s protokolom, ki ga uporablja storitev. Torej, na primer, tako:

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

Lahko uporabite tudi sestavljena imena, na primer http-magic (Istio bo prepoznal http in to pristanišče kot http endpoint). Format je tak: proto-extra.

Da ne bi morali popravljati velikega števila konfiguracij za določanje protokola, lahko uporabite umazan workaround: popravite komponento Pilot v trenutku, ko izvaja logiko določanja protokolaNa koncu bo seveda potrebno spremeniti to logiko v standardno in preiti na konvencijo poimenovanja vseh vrat.

Da bi razumeli, ali je protokol resnično definiran pravilno, je treba vstopiti v katerokoli od sidecar kontejnerjev z envoy proxy in poslati zahtevo na vrata admin vmesnika envoy z lokacijo /config_dump. V nastali konfiguraciji je potrebno pogledati polje operation pri ustrezni storitvi. To se uporablja v Istio kot identifikator, kamor poteka zahteva. Da bi prilagodili vrednost tega parametra v Istio (to bomo nato videli v našem sistemu za sledenje), je potrebno ob zagonu sidecar kontejnerja navesti zastavico serviceCluster. Na primer, to lahko izračunamo iz spremenljivk, pridobljenih iz downward API kubernetes:

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

Dober primer za razumevanje, kako deluje sledenje v envoy, je tukaj.

Sam endpoint za pošiljanje tracing spanov je potrebno prav tako navesti v zastavicah za zagon envoy proxy, na primer: --zipkinAddress tracing-collector.tracing:9411

Mit številka dva: lahko poceni pridobimo popolne sledi prehoda zahtevkov po sistemu kar tako.

Žal to ne drži. Kompleksnost implementacije je odvisna od načina, kako že imate izvedeno sodelovanje storitev. Zakaj tako?

Zadeva je v tem, da za to, da lahko istio-proxy razume povezanost prihodnjih zahtevkov v storitvi z odhodnimi iz te iste storitve, ni dovolj, da preprosto zajamete ves promet. Potrebujete nek identifikator povezave. Pri HTTP envoy proxy se uporabljajo posebni headerji, preko katerih envoy razume, kateri zahtevek k storitvi povzroča konkretne zahteve v druge storitve. Seznam teh headerjev:

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

Če imate enotno točko, na primer osnovnega odjemalca, v katerega lahko dodate to logiko, je vse odlično, potrebujete le počakati na posodobitev te knjižnice pri vseh odjemalcih. Vendar, če imate zelo heterogen sistem in ni unifikacije pri prehodih iz storitev v storitve po omrežju, je to verjetno velika težava. Brez dodajanja take logike bo vse informacije za sledenje le 'enotne ravni'. To pomeni, da bomo pridobili vse medstoritvene interakcije, vendar ne bodo združene v enotne verige prehoda po omrežju.

Zaključek

Istio nudi prirodan alat za prikupljanje informacija o praćenju u mreži, međutim, važno je shvatiti da će za implementaciju biti potrebno prilagoditi svoj sistem i uzeti u obzir specifičnosti implementacije Istio. Na kraju, potrebno je rešiti dva osnovna pitanja: definisanje protokola aplikacionog nivoa (koji mora biti podržan od strane envoy proxy) i konfiguraciju propuštanja informacija o povezanosti zahteva u servis iz zahteva iz servisa (korišćenjem header-a, u slučaju HTTP protokola). Kada su ova pitanja rešena, dobijamo moćan alat koji omogućava transparentno prikupljanje informacija iz mreže, čak i u veoma heterogenim sistemima pisanih na mnogim različitim jezicima i okvirima.

U sledećem članku o Service Mesh-u razmotrićemo jedan od najvećih problema Istio - veliko korišćenje radne memorije od strane svake sidecar proxy kontejnera i razgovaraćemo o tome kako se tim problemom može upravljati.

Izvor: habr.com