Përshëndetje, Habr!
Në një kohë, ne ishim të parët që prezantuam temën në tregun rus
Paraqitje
Kubernetes është krijuar për të trajtuar ngarkesat e punës pa shtetësi. Në mënyrë tipike, ngarkesa të tilla paraqiten në formën e një arkitekture mikroservice, ato janë të lehta, shkallëzohen mirë horizontalisht, ndjekin parimet e aplikacioneve me 12 faktorë dhe mund të punojnë me ndërprerësit dhe majmunët e kaosit.
Kafka, nga ana tjetër, në thelb vepron si një bazë të dhënash e shpërndarë. Kështu, kur punoni, duhet të keni të bëni me shtetin, dhe është shumë më i rëndë se një mikroshërbim. Kubernetes mbështet ngarkesat me status, por siç thekson Kelsey Hightower në dy postime në Twitter, ato duhet të trajtohen me kujdes:
Disa njerëz mendojnë se nëse futni Kubernetes në një ngarkesë pune të plotë, ai bëhet një bazë të dhënash plotësisht e menaxhuar që rivalizon RDS. Kjo eshte e gabuar. Ndoshta, nëse punoni mjaftueshëm, shtoni komponentë shtesë dhe tërheqni një ekip inxhinierësh SRE, do të jeni në gjendje të ndërtoni RDS në krye të Kubernetes.
Unë gjithmonë rekomandoj që të gjithë të kenë kujdes ekstrem kur kryejnë ngarkesa të rregullta pune në Kubernetes. Shumica e njerëzve që pyesin "a mund të ekzekutoj ngarkesa shtetërore të punës në Kubernetes" nuk kanë përvojë të mjaftueshme me Kubernetes, dhe shpesh me ngarkesën e punës për të cilën po pyesin.
Pra, a duhet ta drejtoni Kafkën në Kubernetes? Kundërpyetje: A do të funksionojë Kafka më mirë pa Kubernetes? Kjo është arsyeja pse unë dua të nënvizoj në këtë artikull se si Kafka dhe Kubernetes plotësojnë njëri-tjetrin dhe çfarë grackash mund të vijnë nga kombinimi i tyre.
Koha e përfundimit
Le të flasim për gjënë themelore - vetë mjedisin e ekzekutimit
proces
Agjentët Kafka janë miqësorë me CPU-në. TLS mund të prezantojë disa shpenzime. Sidoqoftë, klientët e Kafka mund të jenë më intensivë të CPU-së nëse përdorin enkriptim, por kjo nuk ndikon tek ndërmjetësit.
kujtim
Agjentët e Kafkës hanë kujtesën. Madhësia e grumbullit të JVM zakonisht kufizohet në 4-5 GB, por do t'ju duhet gjithashtu shumë memorie të sistemit pasi Kafka përdor shumë memorien e faqeve. Në Kubernetes, vendosni burimet e kontejnerit dhe kërkoni kufijtë në përputhje me rrethanat.
Ruajtja e të dhënave
Ruajtja e të dhënave në kontejnerë është kalimtare - të dhënat humbasin kur riniset. Për të dhënat e Kafkës mund të përdorni një vëllim emptyDir
, dhe efekti do të jetë i ngjashëm: të dhënat tuaja të ndërmjetësit do të humbasin pas përfundimit. Mesazhet tuaja ende mund të ruhen në agjentë të tjerë si kopje. Prandaj, pas një rifillimi, ndërmjetësi i dështuar duhet së pari të përsërisë të gjitha të dhënat dhe ky proces mund të marrë shumë kohë.
Kjo është arsyeja pse ju duhet të përdorni ruajtjen afatgjatë të të dhënave. Le të jetë ruajtja afatgjatë jo-lokale me sistemin e skedarëve XFS ose, më saktë, ext4. Mos përdorni NFS. Te paralajmerova. Versionet NFS v3 ose v4 nuk do të funksionojnë. Me pak fjalë, ndërmjetësi Kafka do të rrëzohet nëse nuk mund të fshijë drejtorinë e të dhënave për shkak të problemit të "riemërtimit budalla" në NFS. Nëse nuk ju kam bindur akoma, me shumë kujdes
Сеть
Ashtu si me shumicën e sistemeve të shpërndara, performanca e Kafkës varet shumë nga mbajtja e vonesës së rrjetit në minimum dhe gjerësia e brezit në maksimum. Mos u përpiqni të strehoni të gjithë ndërmjetësit në të njëjtën nyje, pasi kjo do të zvogëlojë disponueshmërinë. Nëse një nyje Kubernetes dështon, i gjithë grupi Kafka do të dështojë. Gjithashtu, mos e shpërndani grupin Kafka në të gjitha qendrat e të dhënave. E njëjta gjë vlen edhe për grupin Kubernetes. Një kompromis i mirë në këtë rast është zgjedhja e zonave të ndryshme të disponueshmërisë.
konfiguracion
Manifestet e rregullta
Faqja e internetit Kubernetes ka
- Nën: Një pod është njësia më e vogël e vendosshme në Kubernetes. Një pod përmban ngarkesën tuaj të punës dhe vetë podi korrespondon me një proces në grupin tuaj. Një pod përmban një ose më shumë kontejnerë. Çdo server ZooKeeper në ansambël dhe çdo ndërmjetës në grupin Kafka do të funksionojë në një pod të veçantë.
- StatfulSet: Një StatefulSet është një objekt Kubernetes që trajton ngarkesa të shumta pune me status dhe ngarkesa të tilla kërkojnë koordinim. StatefulSets ofrojnë garanci në lidhje me renditjen e pods dhe uniken e tyre.
- Shërbime pa kokë: Shërbimet ju lejojnë të shkëputni pods nga klientët duke përdorur një emër logjik. Kubernetes në këtë rast është përgjegjës për balancimin e ngarkesës. Megjithatë, kur operojnë ngarkesa pune të qëndrueshme, si ZooKeeper dhe Kafka, klientët duhet të komunikojnë me një shembull specifik. Këtu janë të dobishme shërbimet pa kokë: në këtë rast, klienti do të ketë ende një emër logjik, por nuk do të duhet të kontaktoni drejtpërdrejt me podin.
- Vëllimi i ruajtjes afatgjatë: Këto vëllime nevojiten për të konfiguruar ruajtjen e vazhdueshme të bllokut jo-lokal të përmendur më sipër.
Mbi
Tabelat e timonit
Helm është një menaxher paketash për një Kubernetes që mund të krahasohet me menaxherët e paketave OS si yum, apt, Homebrew ose Chocolatey. E bën të lehtë instalimin e paketave softuerike të paracaktuara të përshkruara në diagramet Helm. Një grafik Helm i zgjedhur mirë e bën të lehtë detyrën e vështirë se si të konfiguroni siç duhet të gjithë parametrat për të përdorur Kafka në Kubernetes. Ka disa diagrame të Kafkës: ndodhet ajo zyrtare
Операторы
Për shkak se Helm ka disa mangësi, një mjet tjetër po fiton popullaritet të konsiderueshëm: operatorët Kubernetes. Operatori jo vetëm që paketon softuer për Kubernetes, por gjithashtu ju lejon të vendosni një softuer të tillë dhe ta menaxhoni atë.
Në listë
prodhimtari
Është e rëndësishme të testoni performancën duke krahasuar shembullin tuaj Kafka. Teste të tilla do t'ju ndihmojnë të gjeni pengesat e mundshme përpara se të shfaqen problemet. Për fat të mirë, Kafka tashmë ofron dy mjete të testimit të performancës: kafka-producer-perf-test.sh
и kafka-consumer-perf-test.sh
. Përdorni ato në mënyrë aktive. Për referencë, mund t'i referoheni rezultateve të përshkruara në
operacionet
Monitorimi
Transparenca në sistem është shumë e rëndësishme - përndryshe nuk do të kuptoni se çfarë po ndodh në të. Sot ekziston një paketë mjetesh solide që ofron monitorim të bazuar në metrikë në stilin origjinal të cloud. Dy mjete të njohura për këtë qëllim janë Prometheus dhe Grafana. Prometheus mund të mbledhë metrikë nga të gjitha proceset Java (Kafka, Zookeeper, Kafka Connect) duke përdorur një eksportues JMX - në mënyrën më të thjeshtë. Nëse shtoni matjet e cAdvisor, mund të kuptoni më plotësisht se si përdoren burimet në Kubernetes.
Strimzi ka një shembull shumë të përshtatshëm të një pulti Grafana për Kafka. Ai vizualizon matjet kryesore, për shembull, në lidhje me sektorët e nën-përsëritur ose ata që janë jashtë linje. Gjithçka është shumë e qartë atje. Këto metrika plotësohen nga informacioni i përdorimit të burimeve dhe performancës, si dhe treguesit e stabilitetit. Kështu që ju merrni monitorimin bazë të grupimeve të Kafkës për asgjë!
Burimi:
Do të ishte mirë të plotësohej e gjithë kjo me monitorimin e klientit (metrikat për konsumatorët dhe prodhuesit), si dhe monitorimin e vonesës (për këtë ekziston
Prerjet
Regjistrimi është një detyrë tjetër kritike. Sigurohuni që të gjithë kontejnerët në instalimin tuaj Kafka të jenë të regjistruar stdout
и stderr
, dhe gjithashtu sigurohuni që grupi juaj Kubernetes grumbullon të gjitha regjistrat në një infrastrukturë qendrore të regjistrimit, p.sh.
Kontrolli shëndetësor
Kubernetes përdor sondat e gjallërisë dhe gatishmërisë për të kontrolluar nëse podet tuaja funksionojnë normalisht. Nëse kontrolli i gjallërisë dështon, Kubernetes do ta ndalojë atë kontejner dhe më pas do ta rifillojë automatikisht nëse politika e rinisjes caktohet në përputhje me rrethanat. Nëse kontrolli i gatishmërisë dështon, Kubernetes izolon podin nga kërkesat për servisim. Kështu, në raste të tilla, ndërhyrja manuale nuk kërkohet më, gjë që është një plus i madh.
Përditësimet në qarkullim
StatefulSets mbështesin përditësimet automatike: nëse zgjidhni strategjinë RollingUpdate, secili nën Kafka do të përditësohet me radhë. Në këtë mënyrë, koha e ndërprerjes mund të reduktohet në zero.
Shkallëzimi
Shkallëzimi i një grupi Kafka nuk është një detyrë e lehtë. Sidoqoftë, Kubernetes e bën shumë të lehtë shkallëzimin e pod-ve në një numër të caktuar kopjesh, që do të thotë se mund të përcaktoni në mënyrë deklarative sa më shumë ndërmjetës Kafka që dëshironi. Gjëja më e vështirë në këtë rast është ricaktimi i sektorëve pas shkallëzimit ose para zvogëlimit. Përsëri, Kubernetes do t'ju ndihmojë me këtë detyrë.
administratë
Detyrat që lidhen me administrimin e grupit tuaj Kafka, të tilla si krijimi i temave dhe ricaktimi i sektorëve, mund të bëhen duke përdorur skriptet ekzistuese të guaskës duke hapur ndërfaqen e linjës së komandës në podet tuaja. Megjithatë, kjo zgjidhje nuk është shumë e bukur. Strimzi mbështet menaxhimin e temave duke përdorur një operator tjetër. Këtu ka hapësirë për përmirësim.
Rezervoni dhe rivendosni
Tani disponueshmëria e Kafkës do të varet edhe nga disponueshmëria e Kubernetes. Nëse grupi juaj Kubernetes dështon, atëherë në skenarin më të keq, grupi juaj Kafka gjithashtu do të dështojë. Sipas ligjit të Murphy, kjo do të ndodhë patjetër, dhe ju do të humbni të dhënat. Për të reduktuar këtë lloj rreziku, keni një koncept të mirë rezervë. Ju mund të përdorni MirrorMaker, një tjetër mundësi është të përdorni S3 për këtë, siç përshkruhet në këtë
Përfundim
Kur punoni me grupe Kafka të vogla dhe të mesme, patjetër që ia vlen të përdorni Kubernetes pasi ofron fleksibilitet shtesë dhe thjeshton përvojën e operatorit. Nëse keni kërkesa shumë të rëndësishme jofunksionale për vonesë dhe/ose xhiro, atëherë mund të jetë më mirë të konsideroni një opsion tjetër vendosjeje.
Burimi: www.habr.com