Istio i Kubernetes u produkciji. Dio 2. Trasiranje

U posljednjih članak Pogledali smo osnovne komponente Service Mesh Istio, upoznali se sa sustavom i odgovorili na glavna pitanja koja se obično postavljaju pri početku rada s Istiom. U ovom ćemo dijelu pogledati kako organizirati prikupljanje podataka o praćenju preko mreže.

Prvo što mnogim programerima i administratorima sustava padne na pamet kada čuju riječi Service Mesh je praćenje. Doista, svakom mrežnom čvoru dodajemo poseban proxy poslužitelj kroz koji prolazi sav TCP promet. Čini se da je sada moguće jednostavno slati informacije o svim mrežnim interakcijama na mreži. Nažalost, u stvarnosti postoji mnogo nijansi koje treba uzeti u obzir. Pogledajmo ih.

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

Zapravo, relativno besplatno možemo dobiti samo čvorove našeg sustava povezane strelicama i brzinu prijenosa 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 aplikacijskog sloja, kao što su HTTP, gRPC, Redis i tako dalje. 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 koji koriste naš protokol. Naposljetku, želimo vidjeti puni put kojim zahtjev prolazi od prijave u naš sustav do primanja odgovora od korisnika. Ovaj problem više nije tako lako riješiti.

Prvo, pogledajmo kako izgleda raspon praćenja slanja s arhitektonskog gledišta u Istiu. Kao što se sjećamo iz prvog dijela, Istio ima zasebnu komponentu pod nazivom Mixer za prikupljanje telemetrije. Međutim, u trenutnoj verziji 1.0.* slanje se vrši izravno s proxy poslužitelja, odnosno s envoy proxyja. Envoy proxy podržava slanje raspona praćenja pomoću zipkin protokola odmah po otvaranju. Moguće je spojiti i druge protokole, ali samo preko dodatka. Uz Istio odmah dobivamo sastavljen i konfiguriran envoy proxy, koji podržava samo zipkin protokol. Ako želimo koristiti, na primjer, Jaeger protokol i slati raspone praćenja putem UDP-a, tada ć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 sustava, zapravo, sada možete koristiti sam Zipkin ili Jaeger, ali tamo sve šaljete koristeći zipkin kompatibilni protokol (koji je puno manje učinkovit). Sam zipkin protokol uključuje slanje svih podataka o praćenju sakupljačima putem HTTP protokola, koji je prilično skup.

Kao što sam već rekao, želimo pratiti protokole na razini aplikacije. To znači da proxy poslužitelji koji stoje pokraj svake usluge moraju razumjeti kakva se interakcija sada događa. Prema zadanim postavkama, Istio konfigurira sve portove da budu obični TCP, što znači da se tragovi neće slati. Da bi se tragovi slali, prvo morate omogućiti ovu opciju u konfiguraciji glavnog mesha i, što je vrlo važno, imenovati sve portove entiteta kubernetes servisa u skladu s 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 krajnju točku http). Format je: proto-extra.

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

Kako biste razumjeli je li protokol doista točno definiran, trebate otići u bilo koji od sidecar kontejnera s envoy proxyjem i uputiti zahtjev administratorskom portu envoy sučelja s lokacijom /config_dump. U dobivenoj konfiguraciji trebate pogledati radno polje željene usluge. Koristi se u Istio kao identifikator za mjesto na kojem je zahtjev napravljen. Kako bismo prilagodili vrijednost ovog parametra u Istio (tada ćemo ga vidjeti u našem sustavu praćenja), potrebno je navesti oznaku serviceCluster u fazi pokretanja kontejnera s prikolicom. Na primjer, može se ovako izračunati iz varijabli dobivenih iz kubernetes API-ja prema dolje:

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

Dobar primjer za razumijevanje kako praćenje radi u envoy je ovdje.

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

Zabluda broj dva: možemo jeftino dobiti potpune tragove zahtjeva putem sustava odmah po koraku

Nažalost, nije. Složenost implementacije ovisi o tome kako ste već implementirali interakciju usluga. Zašto je to?

Činjenica je da kako bi istio-proxy mogao razumjeti korespondenciju dolaznih zahtjeva servisu s 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 envoy razumije koji specifični zahtjev prema usluzi generira određene zahtjeve prema drugim uslugama. Popis takvih zaglavlja:

• x-id-zahtjeva,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-uzorkovano,
• x-b3-zastavice,
• x-ot-span-kontekst.

Ako imate jednu toč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 vrlo heterogen sustav i nema unifikacije u prelasku sa usluge na uslugu preko mreže, onda će to najvjerojatnije biti veliki problem. Bez dodavanja takve logike, sve informacije praćenja bit će samo "jednorazinske". To jest, primit ćemo sve interakcije između usluga, ali one neće biti zalijepljene u pojedinačne lance prolaza kroz mrežu.

Zaključak

Istio pruža prikladan alat za prikupljanje podataka o praćenju preko mreže, ali morate razumjeti da ćete za implementaciju morati prilagoditi svoj sustav i uzeti u obzir značajke implementacije Istio. Kao rezultat toga, potrebno je riješiti dvije glavne točke: definiranje protokola na razini aplikacije (koji mora podržavati envoy proxy) i postavljanje prosljeđivanja informacija o povezivanju zahtjeva s uslugom iz zahtjeva iz usluge (pomoću zaglavlja , u slučaju HTTP protokola). Kada se ti problemi riješe, imamo moćan alat koji nam omogućuje transparentno prikupljanje informacija s mreže, čak i u vrlo heterogenim sustavima napisanim na mnogo različitih jezika i okvira.

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

Izvor: www.habr.com