ProHoster > Блог > Administracija > Istio i Kubernetes u proizvodnji. Dio 2. Tragiranje

Istio i Kubernetes u proizvodnji. Dio 2. Tragiranje

U poslednjem članak Pogledali smo osnovne komponente Service Mesh Istio-a, upoznali se sa sistemom i odgovorili na glavna pitanja koja se obično javljaju kada se počne raditi sa Istiom. U ovom dijelu ćemo pogledati kako organizirati prikupljanje informacija o praćenju preko mreže.

Istio i Kubernetes u proizvodnji. Dio 2. Tragiranje

Prva stvar koja padne na pamet mnogim programerima i sistemskim administratorima kada čuju riječi Service Mesh is tracing. Zaista, dodajemo poseban proxy server svakom mrežnom čvoru kroz koji prolazi sav TCP promet. Čini se da je sada moguće lako slati informacije o svim mrežnim interakcijama na mreži. Nažalost, u stvarnosti postoje mnoge nijanse koje treba uzeti u obzir. Pogledajmo ih.

Zabluda broj jedan: podatke o planinarenju možemo dobiti besplatno.

U stvari, relativno besplatno, možemo dobiti samo čvorove našeg sistema povezane strelicama i brzinu prenosa podataka između usluga (u stvari, samo broj bajtova po jedinici vremena). Međutim, u većini slučajeva, naše usluge komuniciraju preko neke vrste protokola sloja aplikacije, kao što su HTTP, gRPC, Redis itd. I, naravno, želimo vidjeti informacije o praćenju posebno za ove protokole; želimo vidjeti stopu zahtjeva, a ne brzinu podataka. Želimo razumjeti kašnjenje zahtjeva koristeći naš protokol. Konačno, želimo vidjeti punu putanju koju zahtjev prolazi od prijave na naš sistem do primanja odgovora od korisnika. Ovaj problem više nije tako lako riješiti.

Prvo, pogledajmo kako izgleda slanje raspona praćenja sa arhitektonske tačke gledišta u Istio-u. Kao što se sjećamo iz prvog dijela, Istio ima zasebnu komponentu koja se zove Mixer za prikupljanje telemetrije. Međutim, u trenutnoj verziji 1.0.*, slanje se vrši direktno sa proxy servera, odnosno sa proxy servera izaslanika. Envoy proxy podržava slanje raspona praćenja koristeći zipkin protokol iz kutije. Moguće je povezati i druge protokole, ali samo preko dodatka. Sa Istiom odmah dobijamo sastavljen i konfigurisan envoy proxy, koji podržava samo zipkin protokol. Ako želimo koristiti, na primjer, Jaeger protokol i slati raspone praćenja putem UDP-a, onda ćemo morati izgraditi vlastitu istio-proxy sliku. Postoji podrška za prilagođene dodatke za istio-proxy, ali je još uvijek u alfa verziji. Stoga, ako želimo bez velikog broja prilagođenih postavki, smanjuje se raspon tehnologija koje se koriste za pohranjivanje i primanje raspona praćenja. Od glavnih sistema, zapravo, sada možete koristiti sam Zipkin ili Jaeger, ali sve tamo šaljete koristeći zipkin kompatibilan protokol (koji je mnogo manje efikasan). Sam zipkin protokol uključuje slanje svih informacija o praćenju sakupljačima putem HTTP protokola, što je prilično skupo.

Kao što sam već rekao, želimo da pratimo protokole na nivou aplikacije. To znači da proxy serveri koji stoje pored svakog servisa moraju razumjeti kakva se interakcija sada događa. Podrazumevano, Istio konfiguriše sve portove da budu obični TCP, što znači da neće biti poslani tragovi. Da bi se tragovi slali, prvo morate omogućiti ovu opciju u glavnoj mesh konfiguraciji i, što je vrlo važno, imenovati sve portove entiteta kubernetes servisa u skladu sa protokolom koji se koristi u servisu. To je, na primjer, ovako:

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

Također možete koristiti složena imena poput http-magic (Istio će vidjeti http i prepoznati taj port kao http krajnju tačku). Format je: proto-extra.

Kako ne biste zakrpili ogroman broj konfiguracija za određivanje protokola, možete koristiti prljavo rješenje: zakrpite Pilot komponentu u trenutku kada je samo izvodi logiku definicije protokola. Na kraju, naravno, bit će potrebno promijeniti ovu logiku u standardnu ​​i preći na konvenciju imenovanja za sve portove.

Da biste razumjeli da li je protokol zaista ispravno definiran, potrebno je da uđete u bilo koji od bočnih kontejnera sa proxy proxyjem i uputite zahtjev na admin port interfejsa izaslanika sa lokacijom /config_dump. U rezultirajućoj konfiguraciji morate pogledati polje rada željene usluge. Koristi se u Istio-u kao identifikator mjesta gdje je zahtjev napravljen. Da bismo prilagodili vrijednost ovog parametra u Istio-u (tada ćemo ga vidjeti u našem sistemu praćenja), potrebno je navesti serviceCluster zastavicu u fazi pokretanja bočnog kontejnera. Na primjer, može se izračunati ovako iz varijabli dobijenih iz kubernetes API-ja naniže:

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

Dobar primjer za razumijevanje kako funkcionira praćenje u programu Envoy je ovdje.

Sama krajnja točka za slanje raspona praćenja također mora biti navedena u zastavicama za pokretanje proxyja izaslanika, na primjer: --zipkinAddress tracing-collector.tracing:9411

Zabluda broj dva: možemo jeftino dobiti kompletne tragove zahtjeva kroz sistem iz kutije

Nažalost, nije. Složenost implementacije zavisi od toga kako ste već implementirali interakciju usluga. Žašto je to?

Činjenica je da da bi istio-proxy mogao razumjeti korespondenciju dolaznih zahtjeva na servis sa onima koji napuštaju isti servis, nije dovoljno jednostavno presresti sav promet. Morate imati neku vrstu komunikacijskog identifikatora. HTTP envoy proxy koristi posebna zaglavlja, pomoću kojih izaslanik razumije koji specifični zahtjev za uslugu generiše specifične zahtjeve za druge usluge. Spisak takvih zaglavlja:

  • x-request-id
  • x-b3-traceid,
  • x-b3-spanid,
  • x-b3-parentspanid,
  • x-b3-uzorkovano,
  • x-b3-zastave,
  • x-ot-span-context.

Ako imate jednu tačku, na primjer, osnovni klijent, u koji možete dodati takvu logiku, onda je sve u redu, samo trebate pričekati da se ova biblioteka ažurira za sve klijente. Ali ako imate veoma heterogen sistem i nema ujedinjenja u prelasku sa usluge na uslugu preko mreže, onda će to najverovatnije biti veliki problem. Bez dodavanja takve logike, sve informacije o praćenju će biti samo na "jednom nivou". Odnosno, mi ćemo primiti sve međuservisne interakcije, ali one neće biti zalijepljene u jedinstvene lance prolaska kroz mrežu.

zaključak

Istio pruža zgodan alat za prikupljanje informacija o praćenju preko mreže, ali morate razumjeti da ćete za implementaciju morati prilagoditi svoj sistem i uzeti u obzir karakteristike Istio implementacije. Kao rezultat toga, potrebno je riješiti dvije glavne točke: definiranje protokola na nivou aplikacije (koji mora biti podržan od proxyja izaslanika) i postavljanje prosljeđivanja informacija o povezivanju zahtjeva sa servisom iz zahtjeva iz servisa (pomoću zaglavlja , u slučaju HTTP protokola). Kada se ovi problemi riješe, imamo moćan alat koji nam omogućava da transparentno prikupljamo informacije s mreže, čak iu vrlo heterogenim sistemima napisanim na mnogo različitih jezika i okvira.

U sljedećem članku o Service Mesh, osvrnut ćemo se na jedan od najvećih problema s Istiom – veliku potrošnju RAM-a od strane svakog bočnog proxy kontejnera i razgovarati o tome kako se možete nositi s tim.

izvor: www.habr.com

Dodajte komentar