Istio és Kubernetes a production-ben. 2. rész. Tracing

A múltban a Spotify döntéshozatali módszertanáról. Egyre több felhasználó preferálja a zenehallgatást mobilon a streaming szolgáltatásban, de a cégnél túlnyomórészt webprogramozók dolgoznak. A Spotify elemezte ezt a helyzetet, és úgy döntött, hogy több mobilfejlesztőt vesz fel, valamint átnevezi a webes szakembereket új irányba: Megvizsgáltuk az Istio Service Mesh alapvető összetevőit, megismertük a rendszert, és válaszoltunk a legfontosabb kérdésekre, amelyek általában felmerülnek az Istio használatának elején. Ebben a részben azt nézzük meg, hogyan szervezhetjük meg a nyomkövetési információk gyűjtését a hálózaton.

Az első dolog, ami sok fejlesztőnek és rendszergazdának eszébe jut, amikor a Service Mesh kifejezést hallja, az a nyomkövetés. Valóban, minden hálózati csomóponthoz speciális proxy-szervert adunk hozzá, amelyen keresztül az összes TCP-forgalom áthalad. Úgy tűnik, hogy most már könnyedén küldhetjük el az összes hálózati interakcióhoz kapcsolódó információt. Sajnos a valóságban számos szempontot figyelembe kell venni. Nézzük meg ezeket.

Első tévhit: ingyen megszerezhetjük a hálózati forgalom adatait.

Valójában, viszonylag ingyenesen csak a rendszerünk csomópontjait összekötő nyilakat és az adatok áramlását tudjuk nyomon követni, ami lényegében csak az időegységek alatt áthaladó byte-ok számát jelenti. Azonban a legtöbb esetben a szolgáltatásaink valamilyen alkalmazás szintű protokollon kommunikálnak, mint például HTTP, gRPC, Redis stb. Természetesen látni szeretnénk a nyomkövetési információt pontosan ezeken a protokollokon, látni szeretnénk a kérések arányát, nem pedig az adatokét. Szeretnénk megérteni a kérdések késlekedését a protokollunk alapján. Végül pedig látni szeretnénk a teljes utat, amelyen a kérés áthalad a rendszerbe lépéstől kezdve a felhasználó válaszáig. Ez a feladat már nem olyan egyszerűen oldható meg.

Kezdjük azzal, hogy megnézzük, hogyan néz ki a trace span-ek küldése az Istio architektúrájának szempontjából. Ahogy az első részben emlékezünk, az Istio rendelkezik egy külön komponenssel a telemetria gyűjtésére, amelynek neve Mixer. Azonban, a jelenlegi 1.0.* verzióban a küldés közvetlenül a proxy szerverekből, nevezetesen az envoy proxy-ból történik. Az envoy proxy alapértelmezés szerint támogatja a tracing span-ek küldését zipkin protokollon. Más protokollokat is lehet integrálni, de csak pluginnal. Az Istio-val azonnal egy beállított és konfigurált envoy proxy-t kapunk, amely csak a zipkin protokollt támogatja. Ha például a Jaeger protokollt szeretnénk használni és a tracing span-eket UDP-n küldeni, akkor saját istio-proxy képet kell építenünk. A testreszabható pluginek támogatása az istio-proxy-nál létezik, de még alpha verzióban van. Ezért, ha el akarjuk kerülni a sok testreszabott beállítást, a tracing span-ek tárolására és fogadására használt technológiák köre csökken. Jelenleg lényegében használható a Zipkin, vagy a Jaeger, de minden adatot a zipkin kompatibilis protokollon kell küldeni (ami jelentősen kevésbé hatékony). A zipkin protokoll azt feltételezi, hogy minden tracing információt HTTP protokollon küldenek a gyűjtőknek, ami elég költséges.

Ahogy már említettem, a trace-elség célja az alkalmazási szintű protokollok nyomon követése. Ez azt jelenti, hogy a proxy szerverek, amelyek minden szolgáltatás mellett állnak, meg kell értsék, hogy milyen interakció zajlik éppen. Alapértelmezés szerint az Istio minden port számára plain TCP típust állít be, ami azt jelenti, hogy nem lesznek küldött trace-ek. Ahhoz, hogy a trace-ek küldve legyenek, először is aktiválni kell ezt az opciót a fő mesh konfigurációban, és ami nagyon fontos, el kell nevezni az összes portot a Kubernetes service entitásoknál a használt protokoll szerint. Tehát például így:

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

Összetett neveket is használhatunk, például http-magic (az Istio észreveszi a http-t és így ismeri fel a portot mint http végpontot). A formátum a következő: proto-extra.

Annak érdekében, hogy ne kelljen rengeteg konfigurációt javítani a protokoll meghatározásához, használhatunk egy piszkos workaround-ot: javítsuk a Pilot komponenst abban a pillanatban, amikor épp a protokoll meghatározási logikát végziA végén természetesen módosítani kell ezt a logikát a standardra, és át kell térni minden port elnevezési konvenciójára.

Ahhoz, hogy megértsük, vajon a protokoll valóban helyesen van definiálva, be kell lépnünk bármelyik sidecar konténerbe az envoy proxy-val, és kérni kell a port admin felületét az /config_dump elérési úton. A kapott konfigurációban meg kell nézni a szükséges szolgáltatás operation mezőjét. Ez az Istio-ban az azonosító, ami alapján a kérés történik. Az Istio-ban ennek a paraméternek az értékét a sidecar konténer indításakor a serviceCluster zászló megadásával testre kell szabni. Például ezt így lehet kiszámítani a downward API-ból kapott változókból:

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

Jó példa arra, hogy hogyan működik a tracing az envoy-ban, itt.

A tracing span-ok küldéséhez szükséges endpoint-ot is meg kell határozni az envoy proxy indítási zászlóiban, például: --zipkinAddress tracing-collector.tracing:9411

A második tévhit: olcsón kaphatunk átfogó trace-eket a rendszeren belüli kérés áthaladásáról dobozból.

Sajnos ez nem igaz. A bevezetés bonyolultsága attól függ, hogy milyen módon valósult meg már a szolgáltatások közötti interakció. Miért van ez így?

Az a helyzet, hogy ahhoz, hogy az istio-proxy megértse a bejövő kérdések és a kimenő kérdések közötti kapcsolatot azonosító, nem elég csupán az összes forgalmat lehallgatni. Valamilyen kapcsolatazonosítóra van szükség. HTTP esetén az envoy proxy speciális fejlécet használ, amelyek alapján az envoy megérti, hogy pontosan melyik kérés indít el egy adott kérést más szolgáltatásokhoz. Az ilyen fejlécetek listája:

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

Ha van egy egységes pont, például egy alap kliens, amelybe be lehet építeni ezt a logikát, akkor minden rendben van, csak meg kell várni, hogy ez a könyvtár frissüljön minden kliensnél. De ha nagyon heterogén rendszerrel rendelkezik, és nincs egységesítés a szolgáltatások közötti hálózati kapcsolatok terén, akkor ez valószínűleg nagy problémát jelent. Ilyen logika hozzáadása nélkül az összes tracing információ 'egyszintű' lesz. Tehát megkapjuk az összes szolgáltatások közötti interakciót, de ezek nem fognak összeállni egyetlen hálózati átjárási lánccá.

Zárás

Az Istio kényelmes eszközt biztosít a hálózati tracing információk gyűjtésére, de fontos megérteni, hogy a bevezetéshez alkalmazkodni kell a rendszerhez, és figyelembe kell venni az Istio végrehajtásának sajátosságait. Végül két alapvető kérdést kell megoldani: az alkalmazási szintű protokoll meghatározását (amelyet az envoy proxy-nak támogatnia kell) és a kérések szolgáltatások közötti kapcsolódásának információjának átirányítását (header-ek használatával, HTTP protokoll esetén). Amikor ezek a kérdések megoldódnak, egy erőteljes eszközt kapunk, amely lehetővé teszi a hálózati információk átlátható gyűjtését még nagyon heterogén rendszerekben is, amelyek különböző nyelveken és keretrendszerekben vannak írva.

A következő cikkben a Service Mesh-ről megvizsgáljuk az Istio egyik legnagyobb problémáját – a memória jelentős fogyasztását minden sidecar proxy konténer által, és megvitatjuk, hogyan lehet ezzel megküzdeni.

Forrás: habr.com