Lep pozdrav, Habr!
Nekoč smo bili prvi, ki smo to temo predstavili ruskemu trgu
Predstavitev
Kubernetes je zasnovan za obvladovanje delovnih obremenitev brez stanja. Običajno so takšne delovne obremenitve predstavljene v obliki arhitekture mikrostoritev, so lahke, dobro vodoravno skalirane, sledijo načelom 12-faktorskih aplikacij in lahko delujejo z odklopniki in opicami kaosa.
Kafka pa v bistvu deluje kot porazdeljena baza podatkov. Tako se morate pri delu ukvarjati s stanjem, ki je veliko težje od mikrostoritve. Kubernetes podpira obremenitve s stanjem, a kot poudarja Kelsey Hightower v dveh tvitih, je treba z njimi ravnati previdno:
Nekateri menijo, da če Kubernetes vključite v delovno obremenitev s stanjem, postane popolnoma upravljana baza podatkov, ki tekmuje z RDS. To je narobe. Če boste dovolj trdo delali, dodali dodatne komponente in pritegnili ekipo SRE inženirjev, boste morda lahko zgradili RDS na vrhu Kubernetesa.
Vsem vedno priporočam, da so zelo previdni pri izvajanju delovnih obremenitev s stanjem v Kubernetesu. Večina ljudi, ki vprašajo, ali lahko izvajam delovne obremenitve s stanjem v Kubernetesu, nima dovolj izkušenj s Kubernetesom in pogosto z delovno obremenitvijo, o kateri sprašujejo.
Bi torej morali zagnati Kafko na Kubernetesu? Nasprotno vprašanje: ali bo Kafka deloval bolje brez Kubernetesa? Zato želim v tem članku poudariti, kako se Kafka in Kubernetes dopolnjujeta in kakšne pasti lahko prinese njuno združevanje.
Čas dokončanja
Pogovorimo se o osnovni stvari – samem izvajalnem okolju
Postopek
Posredniki Kafka so prijazni do procesorja. TLS lahko povzroči nekaj dodatnih stroškov. Vendar so odjemalci Kafka morda bolj obremenjeni s procesorjem, če uporabljajo šifriranje, vendar to ne vpliva na posrednike.
spomin
Kafka posredniki žrejo spomin. Velikost kopice JVM je običajno omejena na 4–5 GB, vendar boste potrebovali tudi veliko sistemskega pomnilnika, saj Kafka zelo močno uporablja predpomnilnik strani. V Kubernetesu nastavite vir vsebnika in ustrezno omejite zahteve.
Shranjevanje podatkov
Shranjevanje podatkov v vsebnikih je kratkotrajno – podatki se ob ponovnem zagonu izgubijo. Za podatke Kafka lahko uporabite obseg emptyDir
, učinek pa bo podoben: vaši posredniški podatki bodo po zaključku izgubljeni. Vaša sporočila se lahko še vedno shranijo pri drugih posrednikih kot replike. Zato mora po ponovnem zagonu neuspeli posrednik najprej ponoviti vse podatke, ta postopek pa lahko traja precej časa.
Zato bi morali uporabljati dolgoročno shranjevanje podatkov. Naj bo to nelokalno dolgoročno shranjevanje z datotečnim sistemom XFS ali natančneje ext4. Ne uporabljajte NFS. Posvaril sem te. Različice NFS v3 ali v4 ne bodo delovale. Skratka, posrednik Kafka se bo zrušil, če ne bo mogel izbrisati podatkovnega imenika zaradi problema "neumnega preimenovanja" v NFS. Če vas še nisem prepričal, zelo previdno
Сеть
Kot pri večini porazdeljenih sistemov je delovanje Kafke zelo odvisno od ohranjanja minimalne zakasnitve omrežja in maksimalne pasovne širine. Ne poskušajte gostiti vseh posrednikov na istem vozlišču, saj bo to zmanjšalo razpoložljivost. Če odpove vozlišče Kubernetes, bo odpovedala celotna gruča Kafka. Prav tako ne razpršite gruče Kafka po celih podatkovnih centrih. Enako velja za gručo Kubernetes. Dober kompromis v tem primeru je izbira različnih območij razpoložljivosti.
Konfiguracija
Redni manifesti
Spletno mesto Kubernetes ima
- Pod: Pod je najmanjša razporedljiva enota v Kubernetesu. Pod vsebuje vašo delovno obremenitev, sam pod pa ustreza procesu v vaši gruči. Strok vsebuje enega ali več vsebnikov. Vsak strežnik ZooKeeper v skupini in vsak posrednik v gruči Kafka bo deloval v ločenem paketu.
- StatefulSet: StatefulSet je objekt Kubernetes, ki obravnava več delovnih obremenitev s spremljanjem stanja, takšne delovne obremenitve pa zahtevajo koordinacijo. StatefulSets zagotavljajo jamstva glede naročanja podov in njihove edinstvenosti.
- Storitve brez glave: Storitve vam omogočajo, da ločite pode od strank z uporabo logičnega imena. Kubernetes je v tem primeru odgovoren za uravnoteženje obremenitve. Ko upravljate delovne obremenitve s stanjem, kot sta ZooKeeper in Kafka, pa morajo odjemalci komunicirati z določenim primerkom. Tukaj pridejo prav brezglave storitve: v tem primeru bo stranka še vedno imela logično ime, vendar vam ne bo treba neposredno stopiti v stik s podom.
- Prostornina za dolgoročno shranjevanje: Ti nosilci so potrebni za konfiguracijo zgoraj omenjenega nelokalnega blokovnega trajnega pomnilnika.
Na
Karte za krmilo
Helm je upravitelj paketov za Kubernetes, ki ga je mogoče primerjati z upravitelji paketov OS, kot so yum, apt, Homebrew ali Chocolatey. Omogoča preprosto namestitev vnaprej določenih programskih paketov, opisanih v grafikonih Helm. Dobro izbran Helmov grafikon olajša težko nalogo, kako pravilno konfigurirati vse parametre za uporabo Kafke v Kubernetesu. Kafkovih diagramov je več: uradni se nahaja
Operaterji
Ker ima Helm določene pomanjkljivosti, postaja precej priljubljeno drugo orodje: operaterji Kubernetes. Operater ne le pakira programsko opremo za Kubernetes, ampak vam tudi omogoča, da takšno programsko opremo namestite in jo upravljate.
Na seznamu
Produktivnost
Pomembno je, da preizkusite zmogljivost s primerjalno analizo svojega primerka Kafka. Takšni testi vam bodo pomagali najti morebitna ozka grla, preden se pojavijo težave. Na srečo Kafka že ponuja dve orodji za testiranje zmogljivosti: kafka-producer-perf-test.sh
и kafka-consumer-perf-test.sh
. Aktivno jih uporabljajte. Za referenco si lahko ogledate rezultate, opisane v
Operacije
Spremljanje
Transparentnost v sistemu je zelo pomembna – sicer ne boste razumeli, kaj se v njem dogaja. Danes obstaja soliden nabor orodij, ki zagotavlja spremljanje na podlagi meritev v izvirnem slogu v oblaku. Dve priljubljeni orodji za ta namen sta Prometheus in Grafana. Prometheus lahko zbira metrike iz vseh Java procesov (Kafka, Zookeeper, Kafka Connect) z uporabo JMX izvoznika - na najpreprostejši način. Če dodate meritve cAdvisor, lahko bolje razumete, kako se viri uporabljajo v Kubernetesu.
Strimzi ima zelo priročen primer nadzorne plošče Grafana za Kafko. Vizualizira ključne meritve, na primer o premalo podvojenih sektorjih ali tistih, ki so brez povezave. Tam je vse zelo jasno. Te meritve dopolnjujejo informacije o izkoriščenosti virov in zmogljivosti ter kazalniki stabilnosti. Tako dobite osnovno spremljanje grozdov Kafka za nič!
Vir:
Lepo bi bilo vse to dopolniti s spremljanjem odjemalcev (metrike potrošnikov in proizvajalcev), pa tudi spremljanjem latence (za to obstaja
Sečnja
Beleženje je še ena kritična naloga. Prepričajte se, da so vsi vsebniki v vaši namestitvi Kafka prijavljeni stdout
и stderr
, prav tako zagotovite, da vaša gruča Kubernetes združuje vse dnevnike v osrednjo infrastrukturo za beleženje, npr.
Zdravstveni pregled
Kubernetes uporablja sonde živahnosti in pripravljenosti, da preveri, ali vaši podi delujejo normalno. Če preverjanje delovanja ne uspe, bo Kubernetes ustavil ta vsebnik in ga nato samodejno znova zagnal, če je pravilnik o ponovnem zagonu ustrezno nastavljen. Če preverjanje pripravljenosti ne uspe, Kubernetes izolira pod od servisnih zahtev. Tako v takih primerih ročno posredovanje sploh ni več potrebno, kar je velik plus.
Uvajanje posodobitev
StatefulSets podpirajo samodejne posodobitve: če izberete strategijo RollingUpdate, bo vsak pod Kafko posodobljen po vrsti. Na ta način se lahko izpadi zmanjšajo na nič.
Skaliranje
Skaliranje Kafkinega grozda ni lahka naloga. Vendar Kubernetes omogoča zelo preprosto prilagajanje podov na določeno število replik, kar pomeni, da lahko deklarativno definirate poljubno število posrednikov Kafka. Najtežja stvar v tem primeru je ponovna dodelitev sektorjev po povečanju ali pred zmanjšanjem. Tudi pri tej nalogi vam bo pomagal Kubernetes.
Uprava
Naloge, povezane z upravljanjem gruče Kafka, kot je ustvarjanje tem in ponovno dodeljevanje sektorjev, je mogoče opraviti z uporabo obstoječih lupinskih skriptov, tako da odprete vmesnik ukazne vrstice v vaših podih. Vendar ta rešitev ni preveč lepa. Strimzi podpira upravljanje tem z uporabo drugega operaterja. Tukaj je nekaj prostora za izboljšave.
Varnostno kopiranje in obnovitev
Zdaj bo razpoložljivost Kafke odvisna tudi od razpoložljivosti Kubernetesa. Če vaša gruča Kubernetes odpove, bo v najslabšem primeru odpovedala tudi vaša gruča Kafka. Po Murphyjevem zakonu se bo to zagotovo zgodilo in izgubili boste podatke. Če želite zmanjšati to vrsto tveganja, imejte dober koncept varnostnega kopiranja. Lahko uporabite MirrorMaker, druga možnost je uporaba S3 za to, kot je opisano v tem
Zaključek
Pri delu z majhnimi do srednje velikimi gručami Kafka je vsekakor smiselna uporaba Kubernetesa, saj zagotavlja dodatno fleksibilnost in poenostavi izkušnjo operaterja. Če imate zelo velike zahteve po nefunkcionalni zakasnitvi in/ali prepustnosti, je morda bolje razmisliti o kakšni drugi možnosti uvedbe.
Vir: www.habr.com