Estne Kafka in Kubernetes bona?

Salve, Habr!

Uno tempore fuimus primum thema ad mercatum Russicum introducendum Kafka et continue track ad suum progressum. Potissimum locum invenimus commercii inter Kafka et . Kubernetes. Observabilis (et satis diligenter) articulus Hic locus in Confluent diarii posterioris mense Octobri proximo anno sub authoritate Gwen Shapira editus est. Hodie ad recentiorem Aprilem articulum a Johanne Gyger admonere vellemus, qui, licet non sine interrogationis nota in titulo, rem substantivo modo examinat, textum cum nexus iucundo comitante. Dimitte nobis liberam translationem "simii chaos" si potes!

introduction

Kubernetes destinatur in laboribus publicis tractandis. Typice, huiusmodi laboribus in forma architecturae microserviae exhibentur, leves sunt, bene scandunt, principia applicationum 12 factoris sequuntur, et cum praevaricatoribus et chaos simiarum ambitu laborare possunt.

Kafka autem essentialiter agit ut datorum distributorum. Sic cum opus est, debes agere rem publicam, et multo gravior est quam microservio. Kubernetes onera publica sustinet, sed ut Kelsey Hightower in duabus tweets designat, diligenter tractari debent;

Nonnulli sentiunt quod, si Kubernetes in oneris statuti volvent, fieri database plene tractatum, quod aemuli RDS. Hoc nefas est. Fortasse, si satis difficile laboras, additamenta adicies et machinarum SRE turmas attrahe, RDS super Kubernetes aedificare poteris.

Semper suadeo ut omnes extremam cautelam exerceant in occupationibus publicis in Kubernetes currentibus. Plerique qui "in Kubernetes statua opera currere possum" non satis experientiam apud Kubernetes habent, et saepe cum inposuit quod quaerunt.

Ergone fugis Kafka in Kubernetes? Contra quaestionem: nunquid Kafka melius sine Kubernetes laborabit? Quam ob rem in hoc articulo illustrare volo quomodo Kafka et Kubernetes se inter se complent, et quae foveae cum illis coniungendis venire possunt.

Tempus complementum

Fama de re fundamentali - ipsum runtime environment

processus

Kafka sectores sunt CPU amica. TLS aliquod caput inducere potest. Nihilominus, Kafka clientes magis CPU intensive esse possunt si encryption utantur, sed hoc sectoribus non afficit.

memoriae

Kafka praesidium sectorum devorant memoria. JVM acervus amplitudo plerumque ad 4-5 GB circumscribi solet, sed multum quoque opus est memoriae ratio cum Kafka paginae cache gravissime utitur. In Kubernetes, fines continens subsidia et postulationem constitue.

Data copia

Data reposita in vasis evanescentibus - notitia deperdita est si restarted. Nam Kafka data volumine uti potes emptyDiret similis effectus erit: peracta peribit notitia sectoris. Epistulae tuae adhuc in aliis sectoribus sicut replicas condi possunt. Ergo, post sileo, sector incassum prius omnia data replicare debet, et hic processus multum temporis capere potest.

Inde est, quod uti debes diu-terminus notitia repono. Sit repositio non-longi temporis cum systemate fasciculi XFS vel pressius ext4. Ne uti NFS. Monui te. NFS versiones v3 vel v4 non operantur. Denique Kafka sectorem fragorem faciet si non potest delere notitias directorium ob "stupidum rename" problema in NFS. Si nondum tibi persuasum est, diligentissime hoc legere articulum. Copia data non-loci debet esse ut Kubernetes mollius novum nodi eligere possit post sileo vel relocationem.

network

Ut cum plurimis systematibus distributis, Kafka effectus est valde pendens ab retis latency custodiendis ad minimum et sed ad maximum. Noli tentare omnes sectores hospitari in eadem node, ut hoc promptuarium reducet. Si node Kubernetes deficiat, tota Kafka botrus deficiet. Item, Kafka botrus per integras centra data non dispergite. Eadem ratio est de botro Kubernetes. Bonum compromissum in hac causa est zonas disponibilitates diversas eligere.

configuratione

Ordinarius manifestos

Kubernetes website has valde bonus dux quomodo manifestat utens configurare ZooKeeper. Cum ZooKeeper pars Kafka est, hoc loco bene incipit fieri familiariter quibus notiones Kubernetes hic applicant. Cum hoc intelligis, eadem notione cum Kafka botro uti potes.

• sub: Vasculum minus explicabile unitas in Kubernetes est. Vasculum tuum quod inposuit continet, et ipsum vasculum processui in botro tuo respondet. Vasculum unum vel plura vasa continet. Quisque ZooKeeper cultor in synagoga et quilibet sector in Kafka botrus in vasculo separato current.
• StatefulSet: StatefulSet obiectum est Kubernetes quod multa negotia statuaria tractat, et huiusmodi laboribus coordinationem requirunt. Praesidia de leguminibus ordinandis eorumque singularitatem praebent StatefulSets.
• Temere officia: Officia sinunt te siliquas ab clientibus seiungi utente nomine logico. Kubernetes in hac causa onus librationis author est. Tamen, cum in laboribus statutis operandis, ut ZooKeeper et Kafka, clientes opus habent cum instantia specifica communicare. Hoc est ubi servitia sine capite veniunt in promptu: in hoc casu, client adhuc nomen logicum habebit, sed vasculum directe contingere non debebis.
• Diu terminus repono volumen: Haec volumina requiruntur ad configurandum impedimentum non-loci constans repositionis de qua supra.

In Yolean Copiam manifestarum praebet ut cum Kafka in Kubernetes incipias.

Galea charts

Gubernaculum sarcina pro Kubernetes est, quod actoribus sarcina OS comparari potest ut yum, aptum, Homebrew vel Chocolatey. Facilis facit ut installare praedefinitos fasciculos programmatum in chartis Helm descriptis. Charta bene electa Helm arduum facit negotium quomodo omnes parametros apte configuret facile Kafka in Kubernetes utendi. Kafka schemata varia sunt: ​​officialis unus locus est in incubator conditione, unus est e desmotis, unus - e Bitnami.

operators

Quia Helm quasdam defectus habet, aliud instrumentum populare magnum obtinet: operariorum Kubernetes. Auctor non solum programmatio sarcinarum Kubernetes, sed etiam permittit ut talem programmatum explicandi et administrandi habeat.

In album mirabile operators Duo operarii pro Kafka nominantur. Unus eorum - Strimzi. Cum Strimzi, facile est tuum Kafka glomerari et in minutis currere. Nihil fere figuratio requiritur, praeterea auctor ipse nonnullas lepidissimas lineas praebet, exempli gratia, punctum TLS encryption in botro. Confluentes etiam praebet suo operator.

productivity

Gravis est probare effectum per benchmarking tuum Kafka exempli gratia. Tales probationes adiuvabunt ut potentiale bottlenecks invenias antequam difficultates fiant. Feliciter Kafka iam duo instrumenta perficiendi probat: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Utantur ea activa. Pro reference, referre potes ad proventus in descriptos hoc post Jay Kreps, vel focus in hanc recensionem Amazon MSK by Stephen Maarek.

res

Cras

Perspicuus in systemate magni momenti est - aliter non intelliges quid in eo agatur. Hodie solidum toolkit est quod in stylo indigena nubem magnae metri substructio praebet. Duo instrumenta popularia ad hanc rem sunt Prometheus et Grafana. Prometheus metrice colligere potest ex omnibus processibus Javae (Kafka, Zookeeper, Kafka Connect) utens JMX exportatorii simplicissimo. Si metricam cAdvisorem addideris, plenius intellegere potes quomodo facultates in Kubernetes adhibeantur.

Strimzi commodissimum exemplum Grafana ashboardday pro Kafka habet. Clavem metricam insensit, exempli gratia, circa partes sub-replicatas vel eas quae in offline sunt. Omnia ibi clarissima sunt. Haec metrica utendo ac perficiendo notitias subsidiis complent, necnon indicibus stabilitatis. Ita ut adipiscing basic Kafka botrum pro nihilo!

Source: streamzi.io/docs/master/#kafka_dashboard

Nice quod haec omnia cum cliente vigilantia (metrica in usuris et effectoribus metricis) supplere, nec non magna latency magna (nam hoc est Burrow Mylne) et finem magna - ad hunc usum Kafka Monitor.

Logging

Logging est aliud opus criticum. Fac omnia vasa in Kafka institutionem tuam initium sint stdout и stderratque etiam ut tui Kubernetes glomerati omnia ligna aggregantur in infrastructuram centralem, v.g. Elasticsearch.

eget reprehendo

Kubernetes vita et alacritate utitur ad reprimendam siliquae tuae normaliter currunt. Si vita perscriptio deficiat, Kubernetes illud continente cessabit et tunc statim illud sileo si consilium sileo constituetur. Si promptitudo perscriptio deficiat, Kubernetes vasculum recedit a petitionibus operandis. Talibus in casibus, interventus manualis omnino non requiritur, quod magnum est plus.

Volubilem ex updates

StatefulSets subsidia latae sententiae: si belli RollingUpdate deligis, singula sub Kafka in vicem renovabuntur. Hoc modo downtime ad nihilum redigi potest.

Scaling

Scandere Kafka botrum non facile est. Nihilominus, Kubernetes facillime facit siliquas ad certum numerum replicationum escendere, quae per tot Kafka sectores declarare potes quot voles. Difficillimum in hoc casu est reponenda sectores post scalas vel ante scalas descendentes. Iterum, Kubernetes hoc munere te adiuvabunt.

administratio

Negotia ad botrum tuum Kafka administrandum pertinentia, ut thema creandi et sectores reponendi, fieri potest utendo scripta testudine existentes aperiendo lineam interfaciei in legumine tuo. Sed haec solutio non est valde pulchra. Strimzi adiuvat argumenta administrandi diversos operatoria utentes. Est hic emendandi locus aliquis.

езервное копирование и восстановление

Nunc promptitudo Kafka etiam a promptitudine Kubernetes dependet. Si botrus tuus Kubernetes deficit, tunc in pessimo casu missionis, etiam botrus tuus Kafka deficiet. Secundum legem Murphy, hoc certum erit, et notitia perdet. Ad hoc genus periculi reducere, bene conceptum tergum habere. MirrorMaker uti potes, alia optione uti S3 pro hoc, de quo in hoc post de Zalando.

conclusio,

Cum parvis ad mediocritatem Kafka racemis laborat, certum est Kubernetes uti, dum flexibilitatem additional praebet et experientiam operantis simpliciorem praebet. Si latentiam significantes non-muneris et/vel throughput requisita habes, melius erit considerare aliam optionem instruere.

Source: www.habr.com