Салам, Хабр!
Бир убакта биз биринчилерден болуп орус рыногуна теманы киргизгенбиз жана улантыңыз анын өнүгүшү үчүн. Атап айтканда, биз Кафка менен өз ара аракеттенүү темасын таптык . Байкалуучу (жана өтө кылдат) бул тема Confluent блогунда өткөн жылдын октябрь айында Гвен Шапиранын автору астында жарыяланган. Бүгүн биз сиздин көңүлүңүздү Иоганн Гигердин апрель айындагы акыркы макаласына бургубуз келет, ал темада суроо белгиси жок болсо да, теманы мазмундуураак карап, текстти кызыктуу шилтемелер менен коштогон. Мүмкүн болсо, “хаос маймылынын” бекер котормосун кечириңиз!
тааныштыруу
Kubernetes жарандыгы жок жумуш жүгүн көтөрүү үчүн иштелип чыккан. Эреже катары, мындай жумуш жүктөрү микросервис архитектурасы түрүндө берилет, алар жеңил, туурасынан жакшы масштабда, 12 фактордук колдонмолордун принциптерин сакташат жана автоматтык өчүргүчтөр жана хаос маймылдары менен иштей алат.
Кафка, тескерисинче, бөлүштүрүлгөн маалымат базасы катары иштейт. Ошентип, иштеп жатканда, сиз мамлекет менен күрөшүүгө туура келет жана ал микросервиске караганда алда канча оор. Кубернетес штаттык жүктөрдү колдойт, бирок Келси Хайтауэр эки твиттерде белгилегендей, аларды этияттык менен иштетүү керек:
Кээ бир адамдар, эгерде сиз Кубернетти штаттык жүктөмгө айлантсаңыз, ал RDS менен атаандашкан толук башкарылган маалымат базасы болуп калат деп ойлошот. Бул андай эмес. Мүмкүн, эгер сиз жетишерлик иштесеңиз, кошумча компоненттерди кошуп, SRE инженерлеринин тобун тартсаңыз, сиз RDSти Kubernetesтин үстүнө кура аласыз.
Мен ар бир адамга Kubernetes'те штаттык жүктөмдү иштетип жатканда өтө этият болууну сунуштайм. "Мен Kubernetes боюнча штаттык жүктөрдү иштете аламбы" деп сураган адамдардын көбү Kubernetes менен жетиштүү тажрыйбага ээ эмес жана көбүнчө алар сураган иш жүгү менен.
Демек, сиз Кафканы Кубернетесте иштетишиңиз керекпи? Каршы суроо: Кафка Кубернетессиз жакшы иштейби? Ошондуктан мен бул макалада Кафка менен Кубернетес бири-бирин кантип толуктап турганын жана аларды айкалыштырууда кандай тузактар болушу мүмкүн экенин баса белгилегим келет.
Аяктоо убактысы
Келгиле, негизги нерсе - иштөө чөйрөсү жөнүндө сүйлөшөлү
тартиби
Кафка брокерлери CPU үчүн ыңгайлуу. TLS кошумча чыгымдарды киргизиши мүмкүн. Бирок, Кафка кардарлары шифрлөөнү колдонсо, CPU интенсивдүү болушу мүмкүн, бирок бул брокерлерге таасирин тийгизбейт.
эс-тутум
Кафка брокерлер эс тутумун жеп жатышат. JVM үймөгүнүн өлчөмү адатта 4-5 ГБ менен чектелет, бирок Кафка баракчанын кэшин абдан катуу колдонгондуктан, сизге көп тутумдук эс керек болот. Kubernetes'те контейнер ресурсун коюп, ошого жараша чектөөлөрдү сураңыз.
Маалымат дүкөнү
Контейнерлердеги маалыматтарды сактоо убактылуу болуп саналат - кайра иштетилгенде маалыматтар жоголот. Кафка маалыматтары үчүн көлөмдү колдонсоңуз болот emptyDir, жана эффект окшош болот: сиздин брокер маалыматтарыңыз аяктагандан кийин жоголот. Сиздин билдирүүлөр дагы эле башка брокерлерде көчүрмө катары сакталышы мүмкүн. Ошондуктан, кайра иштетүү кийин, ийгиликсиз брокер биринчи бардык маалыматтарды кайталап керек, жана бул жараян көп убакыт талап кылынышы мүмкүн.
Мына ушул себептен сиз узак мөөнөттүү маалымат сактагычты колдонушуңуз керек. Бул XFS файл системасы же, тагыраак айтканда, ext4 менен локалдык эмес узак мөөнөттүү сактоо болсун. NFS колдонбоңуз. Мен сага эскерткем. NFS v3 же v4 версиялары иштебейт. Кыскача айтканда, Кафка брокери NFSдеги "акылсыз атын өзгөртүү" көйгөйүнөн улам маалыматтар каталогун жок кыла албаса, бузулат. Эгер мен сени ынандыра элек болсом, өтө кылдаттык менен . Кубернетес өчүрүп күйгүзгөндөн же көчүрүлгөндөн кийин жаңы түйүндү ийкемдүү тандай алышы үчүн маалымат сактагыч локалдык эмес болушу керек.
тармак
Көпчүлүк бөлүштүрүлгөн системалардай эле, Кафканын иштеши тармактын кечигүү убактысын минималдуу жана өткөрүү жөндөмдүүлүгүн максималдуу сактоого абдан көз каранды. Бардык брокерлерди бир түйүнгө жайгаштырууга аракет кылбаңыз, анткени бул жеткиликтүүлүктү азайтат. Эгерде Kubernetes түйүнү иштебей калса, бүт Кафка кластери иштебей калат. Ошондой эле, Кафка кластерин бүт маалымат борборлоруна таратпаңыз. Ошол эле Kubernetes кластерине да тиешелүү. Бул учурда жакшы компромисс ар кандай жеткиликтүү зоналарды тандоо болуп саналат.
тарам
Кадимки манифесттер
Kubernetes веб-сайтында бар манифесттерди колдонуу менен ZooKeeperди кантип конфигурациялоо керектиги жөнүндө. ZooKeeper Кафканын бир бөлүгү болгондуктан, бул жерде Kubernetes концепциялары колдонулушу менен таанышуу үчүн жакшы жер. Муну түшүнгөндөн кийин, ошол эле түшүнүктөрдү Кафка кластери менен колдоно аласыз.
- төмөндө: Под - Кубернетестеги эң кичинекей жайгаштырылуучу бирдик. Подтук сиздин иш жүгүңүздү камтыйт, ал эми подкасттын өзү кластериңиздеги процесске туура келет. Поджик бир же бир нече контейнерди камтыйт. Ансамблдеги ар бир ZooKeeper сервери жана Кафка кластериндеги ар бир брокер өзүнчө бөлүмдө иштейт.
- StatefulSet: StatefulSet - бул Kubernetes объектиси, ал бир нече штаттык жүктөмдү иштетет жана мындай жүктөр координацияны талап кылат. StatefulSets поддондорду иретке келтирүүгө жана алардын уникалдуулугуна кепилдик берет.
- Башсыз кызматтар: Кызматтар сизге логикалык аталышты колдонуп, кардарлардан поддондорду ажыратууга мүмкүндүк берет. Бул учурда Kubernetes жүк балансы үчүн жооптуу болуп саналат. Бирок, ZooKeeper жана Kafka сыяктуу штаттык жүктөмдөрдү иштеткенде, кардарлар белгилүү бир инстанция менен байланышуусу керек. Бул жерде башсыз кызматтар жардамга келет: бул учурда кардар дагы эле логикалык ысымга ээ болот, бирок сиз подколь менен түздөн-түз байланышуунун кереги жок.
- Узак мөөнөттүү сактоо көлөмү: Бул көлөмдөр жогоруда айтылган локалдык эмес блоктун туруктуу сактагычын конфигурациялоо үчүн керек.
боюнча Kubernetesтеги Кафка менен баштоого жардам берүү үчүн манифесттердин толук топтомун камсыз кылат.
Руль диаграммалары
Helm - yum, apt, Homebrew же Chocolatey сыяктуу OS пакет менеджерлери менен салыштырууга боло турган Kubernetes үчүн пакет менеджери. Бул Helm диаграммаларында сүрөттөлгөн алдын ала аныкталган программалык пакеттерди орнотууну жеңилдетет. Жакшы тандалган Helm диаграммасы Kubernetesте Кафканы колдонуу үчүн бардык параметрлерди кантип туура конфигурациялоо боюнча татаал тапшырманы жеңилдетет. Бир нече Кафка диаграммасы бар: расмийси жайгашкан , бирөөсү бар , дагы бир - тартып .
операторлор
Helm кээ бир кемчиликтерге ээ болгондуктан, дагы бир курал бир топ популярдуулукка ээ болууда: Kubernetes операторлору. Оператор Kubernetes үчүн программалык камсыздоону пакеттөө менен гана чектелбестен, ошондой программалык камсыздоону жайгаштырууга жана аны башкарууга мүмкүнчүлүк берет.
тизме Кафка үчүн эки оператор айтылган. Алардын бирөөсү - . Strimzi менен Кафка кластериңизди бир нече мүнөттүн ичинде иштетүү оңой. Иш жүзүндө эч кандай конфигурация талап кылынбайт, андан тышкары, оператор өзү кээ бир жакшы мүмкүнчүлүктөрдү берет, мисалы, кластердин ичинде чекиттен чекитке TLS шифрлөө. Confluent да камсыз кылат .
кирешелүүлүк
Кафка инстанцияңызды салыштыруу аркылуу майнаптуулукту текшерүү маанилүү. Мындай тесттер көйгөйлөр пайда боло электе мүмкүн болгон тоскоолдуктарды табууга жардам берет. Бактыга жараша, Кафка буга чейин эки өндүрүмдүүлүктү текшерүү куралдарын камсыз кылат: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Аларды активдуу пайдалануу. Маалымат үчүн, сиз сүрөттөлгөн натыйжаларга кайрыла аласыз Джей Крепс, же көңүл буруңуз Стефан Маарек тарабынан Amazon MSK.
иш
Мониторинг
Системада ачыктык абдан маанилүү - антпесе анда эмне болуп жатканын түшүнбөй каласыз. Бүгүнкү күндө булуттун жергиликтүү стилинде метрикага негизделген мониторингди камсыз кылган катуу инструмент бар. Бул максат үчүн эки популярдуу куралдар Prometheus жана Grafana болуп саналат. Prometheus бардык Java процесстеринен (Kafka, Zookeeper, Kafka Connect) метрикаларды JMX экспорттоочуну колдонуп, эң жөнөкөй жол менен чогулта алат. Эгерде сиз cAdvisor көрсөткүчтөрүн кошсоңуз, Kubernetesте ресурстар кандайча колдонуларын толук түшүнө аласыз.
Strimzi Кафка үчүн Grafana башкаруу панелинин абдан ыңгайлуу мисалы бар. Ал негизги көрсөткүчтөрдү, мисалы, аз репликацияланган же оффлайн болгон секторлор жөнүндө визуализациялайт. Ал жерде баары абдан түшүнүктүү. Бул көрсөткүчтөр ресурстарды пайдалануу жана аткаруу маалыматы, ошондой эле туруктуулук көрсөткүчтөрү менен толукталат. Ошентип, сиз Кафка кластеринин негизги мониторингин бекер аласыз!
Source:
Мунун баарын кардарлардын мониторинги (керектөөчүлөр жана өндүрүүчүлөр боюнча көрсөткүчтөр), ошондой эле күтүү мониторинги (бул үчүн бар) менен толуктоо жакшы болмок. ) жана аягына чейин мониторинг - бул колдонуу үчүн .
Каттоо
Каттоо дагы бир маанилүү милдет болуп саналат. Кафка орнотууңуздагы бардык контейнерлер киргенин текшериңиз stdout и stderr, жана ошондой эле Kubernetes кластериңиз бардык журналдарды борбордук журнал инфраструктурасына топтошуна кепилдик бериңиз, мис. .
иштөө жөндөмдүүлүктөрүн текшерүү
Кубернетес подколоруңуз нормалдуу иштеп жатканын текшерүү үчүн жандуулукту жана даярдуулук зондарын колдонот. Эгер жандуулукту текшерүүдөн өтпөй калса, Kubernetes ал контейнерди токтотуп, кайра иштетүү саясаты ошого жараша коюлса, аны автоматтык түрдө өчүрүп күйгүзөт. Даярдыкты текшерүүдөн өтпөй калса, Kubernetes поддонду тейлөө сурамдарынан бөлүп коёт. Ошентип, мындай учурларда кол менен кийлигишүү таптакыр талап кылынбайт, бул чоң плюс.
Жаңыртууларды жайылтуу
StatefulSets автоматтык жаңыртууларды колдойт: эгер сиз RollingUpdate стратегиясын тандасаңыз, Кафка астындагы ар бири өз кезегинде жаңыртылат. Ушундай жол менен токтоп калууларды нөлгө чейин кыскартууга болот.
Масштабдоо
Кафка кластерин масштабдоо оңой иш эмес. Бирок, Kubernetes подкасттарды репликалардын белгилүү бир санына чейин масштабдоону абдан жеңилдетет, демек сиз Кафка брокерлерин декларативдик түрдө каалагандай аныктай аласыз. Бул учурда эң кыйын нерсе - масштабды чоңойткондон кийин же кичирейтүү алдында секторлорду кайра дайындоо. Дагы бир жолу, Kubernetes сизге бул тапшырманы аткарууга жардам берет.
башкаруу
Темаларды түзүү жана секторлорду кайра дайындоо сыяктуу Кафка кластериңизди башкарууга байланыштуу тапшырмаларды подколоруңуздагы буйрук сабынын интерфейсин ачуу аркылуу учурдагы кабык скрипттеринин жардамы менен аткарса болот. Бирок, бул чечим абдан кооз эмес. Strimzi башка оператор аркылуу темаларды башкарууну колдойт. Бул жерде жакшыртуу үчүн бир аз орун бар.
Камдык көчүрмөнү сактоо жана калыбына келтирүү
Эми Кафканын болушу Kubernetesтин жеткиликтүүлүгүнөн да көз каранды болот. Эгерде сиздин Kubernetes кластериңиз иштебей калса, анда эң начар сценарийде Кафка кластериңиз да иштебей калат. Мерфинин мыйзамына ылайык, бул сөзсүз болот жана сиз маалыматтарды жоготосуз. тобокелдиктин бул түрүн азайтуу үчүн, жакшы камдык түшүнүк бар. Сиз MirrorMaker колдоно аласыз, дагы бир параметр бул үчүн, бул сүрөттөлгөн S3 колдонуу болуп саналат Заландодон.
жыйынтыктоо
Чакан жана орто өлчөмдөгү Кафка кластерлери менен иштөөдө, албетте, Kubernetesти колдонуу керек, анткени ал кошумча ийкемдүүлүктү камсыз кылат жана оператордун тажрыйбасын жөнөкөйлөтөт. Эгер сизде өтө маанилүү функционалдык эмес кечигүү жана/же өткөрүү талаптары бар болсо, анда башка жайылтуу вариантын карап чыкканыңыз жакшы.
Source: www.habr.com