Onko Kafka Kubernetesissa hyvä?

Tervehdys, Habr!

Kerran olimme ensimmäiset, jotka toivat aiheen Venäjän markkinoille Kafka ja jatka seurata sen kehittämiseksi. Erityisesti löysimme aiheen vuorovaikutuksesta Kafkan ja Kubernetes. Havaittava (ja melko varovainen) artikkeli tämä aihe julkaistiin Confluent-blogissa viime vuoden lokakuussa Gwen Shapiran kirjoittamana. Tänään haluamme kiinnittää huomionne uudempaan huhtikuun artikkeliin Johann Gygeriltä, ​​joka, vaikka otsikossa ei ole kysymysmerkkiä, tarkastelee aihetta asiallisemmin ja liittää tekstiin mielenkiintoisia linkkejä. Anna meille anteeksi ilmainen käännös sanalle "kaaosapina", jos voit!

Esittely

Kubernetes on suunniteltu käsittelemään tilattomia työkuormia. Tyypillisesti tällaiset työmäärät esitetään mikropalveluarkkitehtuurin muodossa, ne ovat kevyitä, skaalautuvat hyvin vaakasuoraan, noudattavat 12-faktoristen sovellusten periaatteita ja toimivat katkaisijoiden ja kaaosapinoiden kanssa.

Kafka puolestaan ​​toimii pohjimmiltaan hajautettuna tietokantana. Siten työskennellessään joutuu käsittelemään tilaa, ja se on paljon raskaampaa kuin mikropalvelu. Kubernetes tukee tilallisia kuormia, mutta kuten Kelsey Hightower huomauttaa kahdessa twiitissä, niitä tulee käsitellä varoen:

Jotkut ihmiset ajattelevat, että jos siirrät Kubernetesin tilallisen työtaakan, siitä tulee täysin hallittu tietokanta, joka kilpailee RDS:n kanssa. Tämä on väärin. Jos työskentelet tarpeeksi kovasti, lisäät lisäkomponentteja ja houkuttelet SRE-insinööritiimin, pystyt rakentamaan RDS:n Kubernetesin päälle.

Suosittelen aina, että kaikki noudattavat äärimmäistä varovaisuutta ajaessaan tilallisia työkuormia Kubernetesissa. Useimmilla ihmisillä, jotka kysyvät "Voinko suorittaa tilapitoisia työkuormia Kubernetesissa", ei ole tarpeeksi kokemusta Kubernetesista, ja usein heidän kysyttävästä työkuormasta.

Joten, pitäisikö sinun ajaa Kafkaa Kubernetesissa? Vastakysymys: toimiiko Kafka paremmin ilman Kubernetesia? Siksi haluan tässä artikkelissa korostaa, kuinka Kafka ja Kubernetes täydentävät toisiaan ja mitä sudenkuoppia niiden yhdistäminen voi aiheuttaa.

Valmistumisaika

Puhutaanpa perusasiasta - itse ajonaikaisesta ympäristöstä

prosessi

Kafka-välittäjät ovat prosessoriystävällisiä. TLS saattaa aiheuttaa yleiskustannuksia. Kafka-asiakkaat voivat kuitenkin olla prosessoriintensiivisempiä, jos he käyttävät salausta, mutta tämä ei vaikuta välittäjiin.

Память

Kafka-välittäjät syövät muistia. JVM-keon koko on yleensä rajoitettu 4-5 Gt:iin, mutta tarvitset myös paljon järjestelmämuistia, koska Kafka käyttää sivuvälimuistia erittäin voimakkaasti. Aseta Kubernetesissa säilöresurssi ja pyyntörajat sen mukaisesti.

Tietovarasto

Tietojen tallennus säilöissä on lyhytaikaista - tiedot menetetään uudelleenkäynnistyksen yhteydessä. Kafka-datalle voit käyttää äänenvoimakkuutta emptyDir, ja vaikutus on samanlainen: välittäjätietosi menetetään valmistumisen jälkeen. Viestisi voidaan edelleen tallentaa muille välittäjille replikoina. Siksi epäonnistuneen välittäjän on uudelleenkäynnistyksen jälkeen ensin kopioitava kaikki tiedot, ja tämä prosessi voi viedä paljon aikaa.

Tästä syystä sinun tulee käyttää pitkäaikaista tietojen tallennusta. Olkoon se ei-paikallinen pitkäaikainen tallennus XFS-tiedostojärjestelmällä tai tarkemmin sanottuna ext4. Älä käytä NFS:ää. Varoitin sinua. NFS-versiot v3 tai v4 eivät toimi. Lyhyesti sanottuna Kafka-välittäjä kaatuu, jos se ei pysty poistamaan tietohakemistoa NFS:n "tyhmän uudelleennimeämis"-ongelman vuoksi. Jos en ole vielä vakuuttanut sinua, niin huolellisesti lue tämä artikkeli. Tietosäilön tulee olla ei-paikallinen, jotta Kubernetes voi joustavammin valita uuden solmun uudelleenkäynnistyksen tai siirron jälkeen.

Сеть

Kuten useimpien hajautettujen järjestelmien kohdalla, Kafkan suorituskyky riippuu suuresti verkon latenssin pitämisestä minimissä ja kaistanleveyden maksimoinnissa. Älä yritä isännöidä kaikkia välittäjiä samassa solmussa, koska tämä heikentää saatavuutta. Jos Kubernetes-solmu epäonnistuu, koko Kafka-klusteri epäonnistuu. Älä myöskään jaa Kafka-klusteria kokonaisiin palvelinkeskuksiin. Sama koskee Kubernetes-klusteria. Hyvä kompromissi tässä tapauksessa on valita eri saatavuusvyöhykkeet.

kokoonpano

Säännölliset manifestit

Kubernetesin verkkosivuilla on erittäin hyvä ohje kuinka ZooKeeper määritetään luetteloiden avulla. Koska ZooKeeper on osa Kafkaa, tämä on hyvä paikka tutustua Kubernetes-konsepteihin täällä. Kun ymmärrät tämän, voit käyttää samoja käsitteitä Kafka-klusterin kanssa.

• alapuolella: Pod on Kubernetesin pienin käyttöön otettava yksikkö. Pod sisältää työkuormasi, ja itse pod vastaa klusterisi prosessia. Pallo sisältää yhden tai useamman säiliön. Jokainen ZooKeeper-palvelin ryhmässä ja jokainen välittäjä Kafka-klusterissa toimivat erillisessä kotelossa.
• StatefulSet: StatefulSet on Kubernetes-objekti, joka käsittelee useita tilallisia työkuormia, ja tällaiset työkuormat vaativat koordinointia. StatefulSets antaa takuun podien tilauksesta ja niiden ainutlaatuisuudesta.
• Päättömät palvelut: Palvelujen avulla voit irrottaa podeja asiakkaista käyttämällä loogista nimeä. Kubernetes vastaa tässä tapauksessa kuormituksen tasapainottamisesta. Kuitenkin käytettäessä tilallisia työkuormia, kuten ZooKeeper ja Kafka, asiakkaiden on kommunikoitava tietyn esiintymän kanssa. Tässä päättömät palvelut ovat hyödyllisiä: tässä tapauksessa asiakkaalla on edelleen looginen nimi, mutta sinun ei tarvitse ottaa yhteyttä suoraan podiin.
• Pitkäaikainen varastointitilavuus: Näitä taltioita tarvitaan yllä mainitun ei-paikallisen lohkon pysyvän tallennustilan määrittämiseen.

Päälle Yolean Tarjoaa kattavan luettelon, jonka avulla voit aloittaa Kafkan käytön Kubernetesissa.

Ruorikaaviot

Helm on Kubernetesin paketinhallinta, jota voidaan verrata käyttöjärjestelmän paketinhallintaohjelmiin, kuten yum, apt, Homebrew tai Chocolatey. Sen avulla on helppo asentaa valmiita ohjelmistopaketteja, jotka on kuvattu Helm kaavioissa. Hyvin valittu Helm-kaavio helpottaa kaikkien parametrien oikein konfigurointia Kafkan käyttöä varten Kubernetesissa. Kafka-kaavioita on useita: virallinen sijaitsee inkubaattorikunnossa, on yksi osoitteesta yhtyviä, vielä yksi - alkaen Bitnami.

toimijoiden

Koska Helmissä on tiettyjä puutteita, toinen työkalu on saavuttamassa huomattavaa suosiota: Kubernetes-operaattorit. Operaattori ei vain pakkaa ohjelmistoja Kubernetesille, vaan myös mahdollistaa tällaisten ohjelmistojen käyttöönoton ja hallinnan.

Luettelossa hämmästyttäviä operaattoreita Kaksi Kafkan operaattoria mainitaan. Yksi heistä - Strimzi. Strimzin avulla Kafka-klusterisi saa helposti käyntiin muutamassa minuutissa. Käytännössä konfigurointia ei vaadita, lisäksi operaattori itse tarjoaa joitain mukavia ominaisuuksia, esimerkiksi point-to-point TLS-salauksen klusterin sisällä. Confluent tarjoaa myös oma operaattori.

Suorituskyky

On tärkeää testata suorituskykyä vertaamalla Kafka-esiintymääsi. Tällaiset testit auttavat sinua löytämään mahdolliset pullonkaulat ennen kuin ongelmia ilmenee. Onneksi Kafka tarjoaa jo kaksi suorituskyvyn testaustyökalua: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Käytä niitä aktiivisesti. Viitteeksi voit katsoa kohdassa kuvatut tulokset Tämä postaus Jay Kreps, tai keskittyä tämä arvostelu Amazon MSK, kirjoittanut Stéphane Maarek.

toiminnot

seuranta

Järjestelmän läpinäkyvyys on erittäin tärkeää - muuten et ymmärrä, mitä siinä tapahtuu. Nykyään on olemassa vankka työkalupakki, joka tarjoaa mittauspohjaista seurantaa pilvipohjaisella tyylillä. Kaksi suosittua työkalua tähän tarkoitukseen ovat Prometheus ja Grafana. Prometheus voi kerätä mittareita kaikista Java-prosesseista (Kafka, Zookeeper, Kafka Connect) JMX-vientiohjelman avulla - yksinkertaisimmalla tavalla. Jos lisäät cAdvisor-mittareita, voit ymmärtää paremmin, kuinka resursseja käytetään Kubernetesissa.

Strimzillä on erittäin kätevä esimerkki Grafana-kojelaudasta Kafkalle. Se visualisoi keskeisiä mittareita, esimerkiksi alikopioituista tai offline-tilassa olevista sektoreista. Siellä kaikki on hyvin selvää. Näitä mittareita täydentävät resurssien käyttö- ja suorituskykytiedot sekä vakausindikaattorit. Joten saat Kafka-klusterin perusvalvonnan turhaan!

Lähde: streamzi.io/docs/master/#kafka_dashboard

Kaikkea tätä olisi kiva täydentää asiakasseurannalla (mittarit kuluttajista ja tuottajista) sekä latenssiseurannalla (tätä varten on kolo) ja päästä päähän -valvonta - tähän käyttöön Kafka näyttö.

Kirjaaminen

Kirjaus on toinen tärkeä tehtävä. Varmista, että kaikki Kafka-asennuksesi säiliöt on kirjattu sisään stdout и stderr, ja varmista myös, että Kubernetes-klusterisi kokoaa kaikki lokit keskitettyyn lokiinfrastruktuuriin, esim. Elasticsearch.

Toiminnallinen testaus

Kubernetes käyttää elävyys- ja valmiusantureita tarkistaakseen, toimivatko podit normaalisti. Jos elävyyden tarkistus epäonnistuu, Kubernetes pysäyttää kyseisen säilön ja käynnistää sen sitten automaattisesti uudelleen, jos uudelleenkäynnistyskäytäntö on asetettu vastaavasti. Jos valmiustarkastus epäonnistuu, Kubernetes eristää podin huoltopyynnöistä. Tällaisissa tapauksissa manuaalista puuttumista ei siis enää tarvita, mikä on iso plussa.

Otetaan käyttöön päivityksiä

StatefulSets tukee automaattisia päivityksiä: jos valitset RollingUpdate-strategian, jokainen Kafka-kohdassa päivitetään vuorotellen. Tällä tavalla seisokit voidaan vähentää nollaan.

Skaalaus

Kafka-klusterin skaalaus ei ole helppo tehtävä. Kubernetes tekee kuitenkin erittäin helpoksi skaalata podit tiettyyn määrään replikoita, mikä tarkoittaa, että voit määritellä deklaratiivisesti niin monta Kafka-välittäjää kuin haluat. Vaikeinta tässä tapauksessa on sektoreiden uudelleenjako skaalauksen jälkeen tai ennen pienentämistä. Jälleen Kubernetes auttaa sinua tässä tehtävässä.

antaminen

Kafka-klusterin hallintaan liittyvät tehtävät, kuten aiheiden luominen ja sektoreiden uudelleenmäärittely, voidaan tehdä käyttämällä olemassa olevia shell-skriptejä avaamalla komentoriviliittymä podeissasi. Tämä ratkaisu ei kuitenkaan ole kovin kaunis. Strimzi tukee aiheiden hallintaa eri operaattorilla. Tässä on parantamisen varaa.

Varmuuskopiointi ja palautus

Nyt Kafkan saatavuus riippuu myös Kubernetesin saatavuudesta. Jos Kubernetes-klusterisi epäonnistuu, pahimmassa tapauksessa myös Kafka-klusterisi epäonnistuu. Murphyn lain mukaan tämä tapahtuu varmasti, ja menetät tietoja. Tämäntyyppisen riskin vähentämiseksi on hyvä varmuuskopiointikonsepti. Voit käyttää MirrorMakeria, toinen vaihtoehto on käyttää S3:a tässä kuvatulla tavalla lähettää Zalandosta.

Johtopäätös

Pienten ja keskikokoisten Kafka-klustereiden kanssa työskennellessä kannattaa ehdottomasti käyttää Kubernetesia, sillä se lisää joustavuutta ja yksinkertaistaa käyttökokemusta. Jos sinulla on erittäin merkittäviä ei-toiminnallisia viive- ja/tai suoritustehovaatimuksia, voi olla parempi harkita jotain muuta käyttöönottovaihtoehtoa.

Lähde: will.com