Viimeisessä Tutustuimme Service Mesh Istion peruskomponentteihin, tutustuimme järjestelmään ja vastasimme tärkeimpiin kysymyksiin, joita yleensä herää aloittaessamme työskennellä Istion kanssa. Tässä osassa tarkastellaan, kuinka jäljitystietojen kerääminen voidaan järjestää verkon kautta.
Ensimmäinen asia, joka tulee monille kehittäjille ja järjestelmänvalvojille mieleen, kun he kuulevat sanat Service Mesh is tracing. Itse asiassa lisäämme erityisen välityspalvelimen jokaiseen verkkosolmuun, jonka kautta kaikki TCP-liikenne kulkee. Näyttää siltä, että nyt on mahdollista helposti lähettää tietoa kaikista verkon vuorovaikutuksista verkossa. Valitettavasti todellisuudessa on monia vivahteita, jotka on otettava huomioon. Katsotaanpa niitä.
Väärinkäsitys numero yksi: voimme saada verkossa vaellustietoja ilmaiseksi.
Itse asiassa suhteellisen ilmaiseksi voimme saada vain järjestelmämme solmut yhdistettyinä nuolilla ja palveluiden välillä kulkevalla tiedonsiirtonopeudella (itse asiassa vain tavujen määrä aikayksikköä kohti). Kuitenkin useimmissa tapauksissa palvelumme kommunikoivat jonkin sovelluskerroksen protokollan, kuten HTTP, gRPC, Redis ja niin edelleen, kautta. Ja tietysti haluamme nähdä seurantatiedot erityisesti näitä protokollia varten; haluamme nähdä pyyntönopeuden, emme tiedonsiirtonopeutta. Haluamme ymmärtää protokollaamme käyttävien pyyntöjen latenssin. Lopuksi haluamme nähdä koko polun, jonka pyyntö vie järjestelmään kirjautumisesta käyttäjän vastauksen saamiseen. Tämä ongelma ei ole enää niin helppo ratkaista.
Katsotaanpa ensin, miltä jäljitysvälien lähettäminen näyttää Istiossa arkkitehtonisesta näkökulmasta. Kuten muistamme ensimmäisestä osasta, Istiossa on erillinen komponentti nimeltä Mixer telemetrian keräämiseen. Nykyisessä versiossa 1.0.* lähetys tapahtuu kuitenkin suoraan välityspalvelimista, nimittäin lähettivälityspalvelimelta. Envoy-välityspalvelin tukee jäljitysjaksojen lähettämistä zipkin-protokollan avulla. On mahdollista yhdistää muita protokollia, mutta vain laajennuksen kautta. Istion avulla saamme heti kootun ja konfiguroidun envoy-välityspalvelimen, joka tukee vain zipkin-protokollaa. Jos haluamme käyttää esimerkiksi Jaeger-protokollaa ja lähettää jäljitysjaksoja UDP:n kautta, meidän on rakennettava oma istio-proxy-kuva. Istio-välityspalvelimen mukautettuja laajennuksia on tuettu, mutta se on edelleen alfaversiossa. Siksi, jos haluamme olla ilman suurta määrää mukautettuja asetuksia, jäljitysvälien tallentamiseen ja vastaanottamiseen käytettävien tekniikoiden valikoima pienenee. Pääjärjestelmistä itse asiassa nyt voit käyttää itse Zipkiniä tai Jaegeriä, mutta lähettää kaikki sinne käyttämällä zipkin-yhteensopivaa protokollaa (joka on paljon vähemmän tehokas). Zipkin-protokolla itsessään sisältää kaiken jäljitystietojen lähettämisen kerääjille HTTP-protokollan kautta, mikä on melko kallista.
Kuten jo sanoin, haluamme jäljittää sovellustason protokollia. Tämä tarkoittaa, että kunkin palvelun vieressä olevien välityspalvelinten on ymmärrettävä, millaista vuorovaikutusta nyt tapahtuu. Oletusarvoisesti Istio määrittää kaikki portit tavalliseksi TCP:ksi, mikä tarkoittaa, että jälkiä ei lähetetä. Jotta jäljitys voidaan lähettää, sinun on ensin otettava tämä vaihtoehto käyttöön main mesh -konfiguraatiossa ja, mikä on erittäin tärkeää, nimettävä kaikki kubernetes-palvelukokonaisuuksien portit palvelussa käytettävän protokollan mukaisesti. Eli esimerkiksi näin:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxVoit myös käyttää yhdistelmiä, kuten http-magic (Istio näkee http:n ja tunnistaa portin http-päätepisteeksi). Muoto on: proto-extra.
Jotta et joutuisi korjaamaan valtavaa määrää konfiguraatioita protokollan määrittämiseksi, voit käyttää likaista kiertotapaa: korjaa Pilot-komponentti sillä hetkellä, kun se on juuri . Lopulta tämä logiikka on tietysti muutettava standardiksi ja vaihdettava kaikkien porttien nimeämiskäytäntöön.
Ymmärtääksesi, onko protokolla todella määritelty oikein, sinun on mentävä mihin tahansa sivuvaunukonttiin lähettiläsvälityspalvelimella ja tehtävä pyyntö lähettiliitännän admin portille sijainnilla /config_dump. Tuloksena olevassa kokoonpanossa sinun on tarkasteltava halutun palvelun toimintakenttää. Sitä käytetään Istiossa pyynnön esittämispaikan tunnisteena. Tämän parametrin arvon mukauttamiseksi Istiossa (näemme sen sitten jäljitysjärjestelmässämme), on tarpeen määrittää serviceCluster-lippu sivuvaunukontin käynnistämisvaiheessa. Se voidaan esimerkiksi laskea näin muuttujista, jotka on saatu alaspäin suuntautuvasta kubernetes API:sta:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
Hyvä esimerkki siitä, miten jäljitys toimii lähettilässä .
Itse jäljitysvälien lähettämisen päätepiste on myös määritettävä lähettiläsvälityspalvelimen käynnistyslipuissa, esimerkiksi: --zipkinAddress tracing-collector.tracing:9411
Väärinkäsitys numero kaksi: voimme saada halvalla täydelliset jäljet pyynnöistä järjestelmän kautta heti laatikosta
Valitettavasti se ei ole. Toteutuksen monimutkaisuus riippuu siitä, kuinka olet jo toteuttanut palveluiden vuorovaikutuksen. Miksi niin?
Tosiasia on, että jotta istio-proxy pystyisi ymmärtämään palveluun saapuvien pyyntöjen vastaavuuden samasta palvelusta lähtevien kanssa, ei riitä, että vain siepataan kaikkea liikennettä. Sinulla on oltava jonkinlainen viestintätunniste. HTTP-lähettilään välityspalvelin käyttää erityisiä otsikoita, joiden avulla lähetti ymmärtää, mikä tietty palvelupyyntö tuottaa erityisiä pyyntöjä muille palveluille. Luettelo tällaisista otsikoista:
- x-pyyntötunnus,
- x-b3-traceid,
- x-b3-spanid,
- x-b3-parentsspanid,
- x-b3-sampled,
- x-b3-liput,
- x-ot-span-konteksti.
Jos sinulla on yksittäinen piste, esimerkiksi perusasiakas, johon voit lisätä tällaista logiikkaa, niin kaikki on kunnossa, sinun tarvitsee vain odottaa, että tämä kirjasto päivitetään kaikille asiakkaille. Mutta jos sinulla on hyvin heterogeeninen järjestelmä, eikä palvelusta toiseen verkon kautta siirrytä yhtenäisyyttä, tämä on todennäköisesti suuri ongelma. Ilman tällaista logiikkaa, kaikki jäljitystiedot ovat vain "yksitasoisia". Toisin sanoen me vastaanotamme kaikki yksiköiden väliset vuorovaikutukset, mutta niitä ei liimaudu yksittäisiksi kulkuketjuiksi verkon läpi.
Johtopäätös
Istio tarjoaa kätevän työkalun jäljitystietojen keräämiseen verkon kautta, mutta sinun on ymmärrettävä, että käyttöönottoa varten sinun on mukautettava järjestelmäsi ja otettava huomioon Istio-toteutuksen ominaisuudet. Tämän seurauksena kaksi pääkohtaa on ratkaistava: sovellustason protokollan määrittely (jota lähettivälityspalvelimen on tuettava) ja pyyntöjen yhteyden palveluun liittyvien tietojen välittämisen asettaminen palvelun pyynnöistä (otsikoiden avulla). , jos kyseessä on HTTP-protokolla). Kun nämä ongelmat on ratkaistu, meillä on tehokas työkalu, jonka avulla voimme läpinäkyvästi kerätä tietoa verkosta jopa hyvin heterogeenisissä järjestelmissä, jotka on kirjoitettu useilla eri kielillä ja kehyksissä.
Seuraavassa Service Meshiä käsittelevässä artikkelissa tarkastelemme yhtä Istion suurimmista ongelmista – kunkin sivuvaunun välityspalvelimen suurta RAM-muistin kulutusta ja keskustelemme siitä, kuinka voit käsitellä sitä.
Lähde: will.com