Istio és Kubernetes gyártásban. 2. rész. Nyomkövetés

Az utolsóban cikk Megnéztük a Service Mesh Istio alapvető összetevőit, megismerkedtünk a rendszerrel és megválaszoltuk azokat a főbb kérdéseket, amelyek általában felmerülnek az Istióval való munka megkezdésekor. Ebben a részben megvizsgáljuk, hogyan lehet megszervezni a nyomkövetési információk hálózaton keresztüli gyűjtését.

Az első dolog, ami sok fejlesztőnek és rendszergazdának eszébe jut, amikor meghallja, hogy a Service Mesh nyomkövetés. Valójában minden hálózati csomóponthoz hozzáadunk egy speciális proxyszervert, amelyen az összes TCP-forgalom áthalad. Úgy tűnik, hogy most már könnyen el lehet küldeni információkat a hálózaton lévő összes hálózati interakcióról. Sajnos a valóságban sok árnyalatot kell figyelembe venni. Nézzük meg őket.

Első számú tévhit: ingyen juthatunk online túrázási adatokhoz.

Valójában viszonylag ingyen csak nyilakkal és a szolgáltatások között áthaladó adatsebességgel (sőt, csak az időegységenkénti bájtok számát) tudjuk összekapcsolni a rendszerünk csomópontjait. A legtöbb esetben azonban szolgáltatásaink valamilyen alkalmazási réteg protokollon keresztül kommunikálnak, például HTTP, gRPC, Redis stb. És természetesen szeretnénk látni a nyomkövetési információkat kifejezetten ezekhez a protokollokhoz; a kérési sebességet akarjuk látni, nem az adatsebességet. Szeretnénk megérteni a kérések késleltetését a protokollunk segítségével. Végül látni szeretnénk a teljes útvonalat, amelyet a kérés a rendszerünkbe való bejelentkezéstől a felhasználó válaszának megérkezéséig tart. Ezt a problémát már nem olyan egyszerű megoldani.

Először nézzük meg, hogyan néz ki a nyomkövetési szakaszok küldése építészeti szempontból Istióban. Ahogy az első részből emlékszünk, az Istionak van egy külön komponense, a Mixer a telemetria gyűjtésére. A jelenlegi 1.0.* verzióban azonban a küldés közvetlenül proxyszerverről történik, nevezetesen az envoy proxyról. Az Envoy proxy támogatja a nyomkövetési szakaszok küldését a zipkin protokoll használatával. Lehetőség van más protokollok csatlakoztatására is, de csak bővítményen keresztül. Az Istio-val azonnal kapunk egy összerakott és konfigurált envoy proxyt, ami csak a zipkin protokollt támogatja. Ha például a Jaeger protokollt akarjuk használni, és UDP-n keresztül nyomkövetési tartományokat szeretnénk küldeni, akkor létre kell hoznunk saját istio-proxy képet. Támogatják az istio-proxy egyéni bővítményeit, de még mindig az alfa verzióban van. Ezért ha nagyszámú egyéni beállítás nélkül akarunk lenni, akkor a nyomkövetési tartományok tárolására és fogadására használt technológiák köre lecsökken. A fő rendszerek közül tulajdonképpen most már magát a Zipkin-t, vagy a Jaegert is használhatjuk, de oda mindent a zipkin-kompatibilis protokoll segítségével küldhetünk (ami sokkal kevésbé hatékony). Maga a zipkin protokoll magában foglalja az összes nyomkövetési információ elküldését a gyűjtőknek a HTTP protokollon keresztül, ami meglehetősen drága.

Ahogy már mondtam, az alkalmazás szintű protokollokat szeretnénk nyomon követni. Ez azt jelenti, hogy az egyes szolgáltatások mellett álló proxyszervereknek meg kell érteniük, hogy most milyen interakció történik. Alapértelmezés szerint az Istio minden portot sima TCP-re konfigurál, ami azt jelenti, hogy nem küld nyomkövetést. A nyomkövetések elküldéséhez először engedélyeznie kell ezt az opciót a fő mesh konfigurációban, és ami nagyon fontos, el kell neveznie a kubernetes szolgáltatás entitásainak összes portját a szolgáltatásban használt protokollnak megfelelően. Ez például így van:

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

Használhat összetett neveket is, például http-magic (az Istio látni fogja a http-t, és ezt a portot http-végpontként ismeri fel). A formátum: proto-extra.

Annak érdekében, hogy ne kelljen rengeteg konfigurációt javítani a protokoll meghatározásához, használhat egy piszkos megoldást: javítsa a Pilot összetevőt abban a pillanatban, amikor az éppen protokolldefiníciós logikát hajt végre. A végén természetesen ezt a logikát szabványossá kell tenni, és minden portnál elnevezési konvencióra kell váltani.

Annak megértéséhez, hogy a protokoll valóban helyesen van-e definiálva, be kell lépnie bármelyik oldalkocsis konténerbe envoy proxy-val, és kérést kell küldenie az envoy interfész adminisztrátori portjához a /config_dump hellyel. A kapott konfigurációban meg kell nézni a kívánt szolgáltatás műveleti mezőjét. Az Istio-ban a kérés helyének azonosítójaként használják. Ennek a paraméternek az értékének testreszabásához az Istio-ban (majd látni fogjuk a nyomkövetési rendszerünkben), meg kell adni a serviceCluster jelzőt az oldalkocsis konténer elindításának szakaszában. Például a következőképpen számítható ki a downward kubernetes API-ból származó 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 megértsük, hogyan működik a nyomkövetés a küldöttben itt.

Magát a végpontot a követési tartományok küldéséhez szintén meg kell adni a küldött proxy indítási jelzőiben, például: --zipkinAddress tracing-collector.tracing:9411

Második tévhit: olcsón megkaphatjuk a kérések teljes nyomait a rendszeren keresztül a dobozból

Sajnos nem az. A megvalósítás összetettsége attól függ, hogyan valósította meg már a szolgáltatások interakcióját. Miert van az?

A helyzet az, hogy ahhoz, hogy az istio-proxy megértse a szolgáltatáshoz beérkező kérések és az ugyanazon szolgáltatásból kilépő kérések megfelelését, nem elég egyszerűen lehallgatni az összes forgalmat. Valamilyen kommunikációs azonosítóval kell rendelkeznie. A HTTP envoy proxy speciális fejléceket használ, amelyek segítségével a megbízott megérti, hogy a szolgáltatás melyik kérése generál konkrét kéréseket más szolgáltatások felé. Az ilyen fejlécek listája:

• x-request-id
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentsspanid,
• x-b3-mintás,
• x-b3-zászlók,
• x-ot-span-context.

Ha van egyetlen pontja, például egy alapkliens, amelybe felvehet ilyen logikát, akkor minden rendben van, csak meg kell várnia, hogy ez a könyvtár minden kliens számára frissüljön. De ha nagyon heterogén rendszered van, és nincs egységesség a hálózaton keresztüli szolgáltatásról szolgáltatásra való átállásban, akkor ez valószínűleg nagy probléma lesz. Ilyen logika hozzáadása nélkül minden nyomkövetési információ csak „egyszintű” lesz. Ez azt jelenti, hogy megkapjuk az összes szolgálatok közötti interakciót, de nem lesznek egyetlen áthaladási láncba ragasztva a hálózaton.

Következtetés

Az Istio kényelmes eszközt biztosít a nyomkövetési információk hálózaton keresztüli gyűjtéséhez, de meg kell értenie, hogy a megvalósításhoz hozzá kell igazítania a rendszert, és figyelembe kell vennie az Istio megvalósítás jellemzőit. Ebből kifolyólag két fő szempontot kell megoldani: az alkalmazás szintű protokoll definiálását (amelyet az envoy proxynak támogatnia kell) és a szolgáltatástól érkező kérések szolgáltatáshoz való kapcsolódási információinak továbbítását (fejlécek segítségével). , a HTTP protokoll esetén). Ha ezek a problémák megoldódnak, egy hatékony eszköz áll rendelkezésünkre, amely lehetővé teszi számunkra, hogy átláthatóan gyűjtsünk információkat a hálózatról, még nagyon heterogén rendszerekben is, amelyek sok különböző nyelven és keretrendszerben íródnak.

A Service Mesh-ről szóló következő cikkben megvizsgáljuk az Istio egyik legnagyobb problémáját – az oldalkocsis proxykonténerek nagy RAM-fogyasztását, és megvitatjuk, hogyan kezelheti ezt.

Forrás: will.com