Saluton, Habr!
Iam ni estis la unuaj enkonduki la temon al la rusa merkato
Enkonduko
Kubernetes estas dizajnita por trakti sennaciajn laborŝarĝojn. Tipe, tiaj laborŝarĝoj estas prezentitaj en la formo de mikroserva arkitekturo, ili estas malpezaj, skalas bone horizontale, sekvas la principojn de 12-faktoraj aplikoj, kaj povas labori kun interrompiloj kaj kaosaj simioj.
Kafka, aliflanke, esence funkcias kiel distribuita datumbazo. Tiel, kiam vi laboras, vi devas trakti ŝtaton, kaj ĝi estas multe pli peza ol mikroservo. Kubernetes subtenas ŝtatajn ŝarĝojn, sed kiel Kelsey Hightower rimarkas en du tweets, ili devas esti pritraktataj zorge:
Iuj homoj opinias, ke se vi ruliĝas Kubernetes en ŝtatan laborŝarĝon, ĝi fariĝas plene administrita datumbazo, kiu konkuras kun RDS. Ĉi tio estas malĝusta. Eble, se vi sufiĉe laboras, aldonas pliajn komponantojn kaj altiros teamon de SRE-inĝenieroj, vi povos konstrui RDS sur Kubernetes.
Mi ĉiam rekomendas, ke ĉiuj ekzercu ekstreman singardon dum kurado de ŝtataj laborŝarĝoj sur Kubernetes. Plej multaj homoj, kiuj demandas "ĉu mi povas ruli ŝtatajn laborŝarĝojn sur Kubernetes", ne havas sufiĉe da sperto kun Kubernetes, kaj ofte kun la laborkvanto pri kiu ili demandas.
Do, ĉu vi rulu Kafka sur Kubernetes? Kontraŭdemando: ĉu Kafka funkcios pli bone sen Kubernetes? Tial mi volas reliefigi en ĉi tiu artikolo kiel Kafka kaj Kubernetes kompletigas unu la alian, kaj kiajn malfacilaĵojn povas veni kun kombini ilin.
Tempo de kompletigo
Ni parolu pri la baza afero - la rultempa medio mem
procezo
Kafka makleristoj estas CPU-amika. TLS povas enkonduki iom da superkosto. Tamen, Kafka klientoj povas esti pli CPU-intensaj se ili uzas ĉifradon, sed ĉi tio ne influas makleristojn.
memoro
Kafka makleristoj manĝas memoron. La amaso de JVM estas kutime limigita al 4-5 GB, sed vi ankaŭ bezonos multan sisteman memoron ĉar Kafka tre peze uzas la paĝan kaŝmemoron. En Kubernetes, starigu ujo-rimedon kaj petu limojn laŭe.
Datuma butiko
Datumstokado en ujoj estas efemera - datumoj perdiĝas kiam rekomencita. Por Kafka-datumoj vi povas uzi volumon emptyDir
, kaj la efiko estos simila: viaj makleristaj datumoj perdiĝos post kompletigo. Viaj mesaĝoj ankoraŭ povas esti konservitaj ĉe aliaj makleristoj kiel kopioj. Sekve, post rekomenco, la malsukcesa broker unue devas reprodukti ĉiujn datumojn, kaj ĉi tiu procezo povas preni multan tempon.
Jen kial vi devus uzi longtempan datumstokadon. Estu ne-loka longdaŭra stokado kun la XFS-dosiersistemo aŭ, pli precize, ext4. Ne uzu NFS. Mi avertis vin. NFS-versioj v3 aŭ v4 ne funkcios. Mallonge, la Kafka makleristo kraŝos se ĝi ne povas forigi la datuman dosierujon pro la problemo de "stulta renomo" en NFS. Se mi ankoraŭ ne konvinkis vin, tre zorge
Reto
Kiel ĉe la plej multaj distribuitaj sistemoj, la agado de Kafka tre dependas de konservado de reto latenteco al minimumo kaj bendolarĝo al la maksimumo. Ne provu gastigi ĉiujn makleristojn sur la sama nodo, ĉar ĉi tio reduktos haveblecon. Se Kubernetes-nodo malsukcesos, la tuta Kafka areto malsukcesos. Ankaŭ ne disigu la Kafka-areton tra tutaj datumcentroj. La sama validas por la Kubernetes-areto. Bona kompromiso en ĉi tiu kazo estas elekti malsamajn havebleczonojn.
Agordo
Regulaj manifestoj
La retejo de Kubernetes havas
- Sub: Pod estas la plej malgranda deplojebla unuo en Kubernetes. Pod enhavas vian laborŝarĝon, kaj la pod mem respondas al procezo en via areto. Pod enhavas unu aŭ plurajn ujojn. Ĉiu ZooKeeper-servilo en la ensemblo kaj ĉiu makleristo en la Kafka areto funkcios en aparta podo.
- StatefulSet: StatefulSet estas Kubernetes-objekto, kiu pritraktas multoblajn ŝtatajn laborŝarĝojn, kaj tiaj laborŝarĝoj postulas kunordigon. StatefulSets provizas garantiojn pri la mendado de balgoj kaj ilia unikeco.
- Senkapaj servoj: Servoj permesas al vi malligi podojn de klientoj uzante logikan nomon. Kubernetes en ĉi tiu kazo respondecas pri ŝarĝoekvilibro. Tamen, kiam funkciigas ŝtatajn laborŝarĝojn, kiel ekzemple ZooKeeper kaj Kafka, klientoj devas komuniki kun specifa kazo. Jen kie senkapaj servoj utilas: en ĉi tiu kazo, la kliento ankoraŭ havos logikan nomon, sed vi ne devos rekte kontakti la podon.
- Longtempa stokado-volumo: Ĉi tiuj volumoj estas bezonataj por agordi la ne-lokan blokan konstantan stokadon menciitan supre.
En
Helm-diagramoj
Helm estas pakaĵmanaĝero por Kubernetes, kiu povas esti komparita kun OS-pakadministrantoj kiel ekzemple yum, apt, Homebrew aŭ Chocolatey. Ĝi faciligas instali antaŭdifinitajn programarpakaĵojn priskribitajn en Helm-diagramoj. Bone elektita Helm-diagramo faciligas la malfacilan taskon kiel ĝuste agordi ĉiujn parametrojn por uzi Kafka ĉe Kubernetes. Estas pluraj Kafka diagramoj: la oficiala troviĝas
Telefonistoj
Ĉar Helm havas certajn mankojn, alia ilo akiras konsiderindan popularecon: Kubernetes-funkciigistoj. La funkciigisto ne nur pakas programaron por Kubernetes, sed ankaŭ permesas vin disfaldi tian programaron kaj administri ĝin.
En la listo
Produkteco
Gravas testi agadon per benchmarking de via Kafka-instanco. Tiaj provoj helpos vin trovi eblajn botelojn antaŭ ol problemoj okazas. Feliĉe, Kafka jam provizas du rezultajn testajn ilojn: kafka-producer-perf-test.sh
и kafka-consumer-perf-test.sh
. Aktive uzu ilin. Por referenco, vi povas raporti al la rezultoj priskribitaj en
Operacioj
Monitorado
Travidebleco en la sistemo estas tre grava - alie vi ne komprenos, kio okazas en ĝi. Hodiaŭ ekzistas solida ilaro, kiu disponigas metrik-bazitan monitoradon en la nuba indiĝena stilo. Du popularaj iloj por ĉi tiu celo estas Prometheus kaj Grafana. Prometheus povas kolekti metrikojn de ĉiuj Java-procezoj (Kafka, Zookeeper, Kafka Connect) uzante JMX-eksportilon - en la plej simpla maniero. Se vi aldonas cAdvisor-metrikojn, vi povas pli plene kompreni kiel rimedoj estas uzataj en Kubernetes.
Strimzi havas tre oportunan ekzemplon de Grafana panelo por Kafka. Ĝi bildigas ŝlosilajn metrikojn, ekzemple, pri subreproduktitaj sektoroj aŭ tiuj, kiuj estas eksterrete. Ĉio estas tre klara tie. Ĉi tiuj metrikoj estas kompletigitaj per informoj pri uzado de rimedoj kaj agado, same kiel indikiloj de stabileco. Do vi ricevas bazan Kafka-grupon monitoradon por nenio!
fonto:
Estus bone kompletigi ĉion ĉi per klientmonitorado (metriko pri konsumantoj kaj produktantoj), same kiel latenta monitorado (por tio ekzistas
Enhavo
Registrado estas alia kritika tasko. Certigu, ke ĉiuj ujoj en via Kafka-instalaĵo estas ensalutitaj stdout
и stderr
, kaj ankaŭ certigu, ke via Kubernetes-areto kunigas ĉiujn protokolojn en centran registran infrastrukturon, ekz.
Funkcia Atesto
Kubernetes uzas sondilojn pri viveco kaj preteco por kontroli ĉu viaj podoj funkcias normale. Se la vivkontrolo malsukcesas, Kubernetes haltigos tiun ujon kaj poste aŭtomate rekomencos ĝin se la rekomencpolitiko estas agordita laŭe. Se la preteca kontrolo malsukcesas, Kubernetes izolas la pod de servado de petoj. Tiel, en tiaj kazoj, mana interveno tute ne plu necesas, kio estas granda pluso.
Disvolviĝo de ĝisdatigoj
StatefulSets subtenas aŭtomatajn ĝisdatigojn: se vi elektas la RollingUpdate-strategion, ĉiu sub Kafka estos ĝisdatigita laŭvice. Tiamaniere, malfunkcio povas esti reduktita al nulo.
Skalo
Skali Kafka areton ne estas facila tasko. Tamen, Kubernetes tre facilas grimpi podojn al certa nombro da kopioj, kio signifas, ke vi povas deklara difini tiom da Kafka makleristoj kiel vi volas. La plej malfacila afero en ĉi tiu kazo estas reasigni sektorojn post pligrandigo aŭ antaŭ malpligrandigo. Denove, Kubernetes helpos vin kun ĉi tiu tasko.
Administrado
Taskoj rilataj al administrado de via Kafka-grupo, kiel krei temojn kaj reasigni sektorojn, povas esti faritaj uzante ekzistantajn ŝelajn skriptojn malfermante la komandlinian interfacon en viaj podoj. Tamen ĉi tiu solvo ne estas tre bela. Strimzi subtenas administri temojn uzante malsaman funkciigiston. Estas iom da loko por plibonigo ĉi tie.
Sekurkopio kaj restarigo
Nun la havebleco de Kafka ankaŭ dependos de la havebleco de Kubernetes. Se via Kubernetes-areto malsukcesas, tiam en la plej malbona kazo, via Kafka-areto ankaŭ malsukcesos. Laŭ la leĝo de Murphy, ĉi tio certe okazos, kaj vi perdos datumojn. Por redukti ĉi tiun tipon de risko, havu bonan rezervan koncepton. Vi povas uzi MirrorMaker, alia opcio estas uzi S3 por ĉi tio, kiel priskribite en ĉi tio
konkludo
Kiam vi laboras kun malgrandaj ĝis mezgrandaj Kafka-aretoj, certe indas uzi Kubernetes ĉar ĝi provizas plian flekseblecon kaj simpligas la sperton de operaciisto. Se vi havas tre signifajn nefunkciajn latentecon kaj/aŭ traigajn postulojn, tiam eble estos pli bone konsideri iun alian deplojan opcion.
fonto: www.habr.com