Доклад Kubernetesте операторду өнүктүрүүнүн практикалык маселелерине, анын архитектурасын жана негизги иштөө принциптерине арналган.
Отчеттун биринчи бөлүгүндө биз карап чыгабыз:
- Kubernetes оператору деген эмне жана ал эмне үчүн керек;
- оператор татаал системаларды башкарууну кантип жөнөкөйлөтөт;
- оператор эмне кыла алат жана эмне кыла албайт.
Андан кийин оператордун ички түзүмүн талкуулоого өтөбүз. Оператордун архитектурасын жана иштешин этап-этабы менен карап көрөлү. Аны майда-чүйдөсүнө чейин карап көрөлү:
- оператор менен Kubernetes ортосундагы өз ара аракеттенүү;
- оператор кандай функцияларды аткарат жана ал Kubernetesке кандай функцияларды тапшырат.
Келгиле, Kubernetes'те сыныктарды жана маалымат базасынын репликаларын башкарууну карап көрөлү.
Кийинки, биз маалыматтарды сактоо маселелерин талкуулайбыз:
- оператордун көз карашы боюнча Persistent Storage менен кантип иштөө керек;
- Жергиликтүү сактагычты колдонуудагы кемчиликтер.
Отчеттун акыркы бөлүгүндө биз колдонуунун практикалык мисалдарын карап чыгабыз Amazon же Google Булут кызматы менен. Отчет ClickHouse үчүн оператордун иштеп чыгуу жана иштөө тажрыйбасынын мисалына негизделген.
Videos:
Менин атым Владислав Клименко. Бүгүн мен операторду иштеп чыгуу жана иштетүү боюнча тажрыйбабыз жөнүндө айткым келди, бул маалымат базасы кластерлерин башкаруу боюнча адистештирилген оператор. Мисалы ClickHouse кластерин башкаруу үчүн.
Эмне үчүн бизде оператор жана ClickHouse жөнүндө сүйлөшүү мүмкүнчүлүгү бар?
- Биз ClickHouse программасын колдойбуз жана өнүктүрөбүз.
- Учурда биз акырындык менен ClickHouse программасын өнүктүрүүгө өз салымыбызды кошууга аракет кылып жатабыз. Ал эми ClickHouseга киргизилген өзгөртүүлөрдүн көлөмү боюнча биз Яндекстен кийин экинчибиз.
- Биз ClickHouse экосистемасы үчүн кошумча долбоорлорду ишке ашырууга аракет кылып жатабыз.
Мен ошол долбоорлордун бири жөнүндө айткым келет. Бул Kubernetes үчүн ClickHouse-оператору жөнүндө.
Баяндамамда мен эки темага токтолгум келет:
- Биринчи тема - биздин ClickHouse маалымат базасын башкаруу операторубуз Кубернетесте кантип иштейт.
- Экинчи тема - бул ар кандай оператор кандайча иштейт, б.а. Кубернетес менен кантип иштешет.
Бирок, бул эки суроо менин отчетум бою кесилишет.
Менин айтайын деп жатканымды ким уккусу келет?
- Бул операторлорду иштеткендер үчүн эң кызыктуу болот.
- Же анын ичинде кантип иштээрин, оператор Кубернетес менен кантип иштешерин жана кандай тузактар пайда болушу мүмкүн экенин түшүнүү үчүн өз алдынча жасагысы келгендер үчүн.
Бүгүн эмнени талкуулай турганыбызды жакшыраак түшүнүү үчүн, Kubernetes кантип иштээрин билип, булут боюнча негизги машыгуудан өтүү жакшы идея.
ClickHouse деген эмне? Бул аналитикалык суроо-талаптарды онлайн иштетүү үчүн өзгөчө өзгөчөлүктөрү бар мамычалык маалымат базасы. Жана бул толугу менен ачык булак.
Ал эми биз үчүн эки гана нерсени билүү маанилүү. Бул маалымат базасы экенин билишиңиз керек, андыктан мен сизге айта турган нерсе дээрлик бардык маалыматтар базасына жарактуу болот. Ал эми ClickHouse DBMS абдан жакшы масштабда экендиги дээрлик сызыктуу масштабдуулукту берет. Демек, кластердик абал ClickHouse үчүн табигый абал. Бизди Кубернетестеги ClickHouse кластерин кантип тейлөө керектигин талкуулоого кызыкдарбыз.
Ал жерде эмне үчүн керек? Эмне үчүн аны өзүбүз иштете албайбыз? Ал эми жооптор жарым-жартылай техникалык жана жарым-жартылай уюштуруучулук.
- Иш жүзүндө, биз ири компанияларда дээрлик бардык компоненттер Кубернетеде болгон кырдаалга барган сайын жолугуп жатабыз. Маалыматтар базалары сыртта калат.
- Ал эми суроо барган сайын көп берилип жатат: "Бул ичине жайгаштырууга болобу?" Ошондуктан, ири компаниялар маалымат кампаларын тез башкара алуу үчүн башкаруунун максималдуу унификациясына жетишүүгө аракет кылып жатышат.
- Жана бул, өзгөчө, сизге бир эле нерсени жаңы жерде кайталоо үчүн максималдуу мүмкүнчүлүк керек болсо, жардам берет, башкача айтканда.
Бул канчалык оңой же кыйын? Бул, албетте, кол менен жасалышы мүмкүн. Бирок бул анчалык деле жөнөкөй эмес, анткени бизде Kubernetesтин өзүн башкаруунун кошумча татаалдыгы бар, бирок ошол эле учурда ClickHouse спецификасы үстөмдүк кылат. Жана мындай топтоо натыйжа берет.
Мунун баары биригип технологиялардын кыйла чоң топтомун берет, аларды башкаруу бир топ кыйын болуп калат, анткени Kubernetes өзүнүн күнүмдүк маселелерин ишке киргизет, ал эми ClickHouse өзүнүн маселелерин күнүмдүк ишке киргизет. Айрыкча, бизде бир нече ClickHouse бар болсо жана алар менен дайыма бир нерсе кылышыбыз керек.
Динамикалык конфигурация менен ClickHouse'да DevOps боюнча туруктуу жүктү жараткан көптөгөн маселелер бар:
- Биз ClickHouse бир нерсени өзгөрткүбүз келсе, мисалы, репликаны же сыныкчаны кошсок, анда конфигурацияны башкаруу керек.
- Андан кийин маалымат схемасын өзгөртүү, анткени ClickHouse белгилүү sharding ыкмасы бар. Ал жерде сиз маалымат диаграммасын, конфигурацияларды жайгаштырышыңыз керек.
- Сиз мониторинг орнотуу керек.
- Жаңы сыныктар, жаңы репликалар үчүн журналдарды чогултуу.
- калыбына келтирүү үчүн кам көр.
- Жана кайра баштаңыз.
Бул мен чындап колдонууну жеңилдетким келген күнүмдүк тапшырмалар.
Kubernetes өзү иштөөдө жакшы жардам берет, бирок негизги системалык нерселерде.
Kubernetes төмөнкүдөй нерселерди жеңилдетүүдө жана автоматташтырууда жакшы:
- Калыбына келтирүү.
- Кайра жүргүзүү.
- Сактоо тутумун башкаруу.
Бул жакшы, бул туура багыт, бирок ал маалымат базасы кластерин кантип иштетүүнү билбейт.
Биз дагы көптү каалайбыз, биз бардык маалымат базасы Кубернетесте иштешин каалайбыз.
Мен чоң бир сыйкырдуу кызыл баскыч сыяктуу нерсени алгым келет, ал сиз бассаңыз, күнүмдүк тапшырмалар чечилиши керек болгон кластер бүткүл жашоо цикли бою иштетилип, сакталып турат. Kubernetesтеги ClickHouse кластери.
Ал эми ишти жеңилдетүүгө жардам бере турган чечим чыгарууга аракет кылдык. Бул Altinityден келген Kubernetes үчүн ClickHouse-оператору.
Оператор – бул программа, анын негизги милдети башка программаларды башкаруу, б.а. ал менеджер.
Жана ал жүрүм-турум үлгүлөрүн камтыйт. Сиз бул предметтик аймак жөнүндө кодификацияланган билим деп атасаңыз болот.
Жана анын негизги милдети - DevOpsтин жашоосун жеңилдетүү жана микроменеджментти кыскартуу, ал (DevOps) буга чейин эле жогорку деңгээлде ой жүгүртөт, б.а. бардык майда-чүйдөсүнө чейин кол менен.
Жана жөн гана оператор - бул микротапшырмалар менен алектенген жана DevOps-ка жардам берген робот жардамчы.
Эмне үчүн сизге оператор керек? Ал эки багытта өзгөчө жакшы аткарат:
- ClickHouse менен алектенген адистин тажрыйбасы жетишсиз болсо, бирок ClickHouse иштетиши керек болсо, оператор операцияны жеңилдетет жана анын кандайча иштээри жөнүндө өтө эле майда-чүйдөсүнө чейин айтпастан, кыйла татаал конфигурациядагы ClickHouse кластерин иштетүүгө мүмкүндүк берет. ичинде. Сиз ага жөн гана жогорку деңгээлдеги тапшырмаларды бересиз жана ал иштейт.
- Ал эми эң жакшы аткарган экинчи милдет – бул көп сандагы типтүү тапшырмаларды автоматташтыруу зарыл болгондо. Системалык администраторлордон микротапшырмаларды жок кылат.
Бул жолду жаңыдан баштап жаткандарга же көп автоматташтырууга муктаж болгондорго эң зарыл.
Оператордук ыкма башка системалардан эмнеси менен айырмаланат? Хелм бар. Бул ошондой эле ClickHouse орнотууга жардам берет; сиз бүтүндөй ClickHouse кластерин орното турган руль диаграммаларын тартсаңыз болот. Анда оператор менен бир эле, мисалы, Helm ортосунда кандай айырма бар?
Негизги принципиалдуу айырма - Helm пакетти башкаруу жана Оператор бир кадам алдыга барат. Бул бүткүл жашоо цикли үчүн колдоо болуп саналат. Бул жөн гана орнотуу эмес, бул масштабдоо, майдалоо, б.а. жашоо циклинде жасала турган нерселердин бардыгын (зарыл болсо, андан кийин да жок кылуу) камтыган күнүмдүк тапшырмалар - мунун бардыгын оператор чечет. Ал бүтүндөй программалык камсыздоонун өмүр циклин автоматташтырууга жана колдоого аракет кылат. Бул анын башка чечимдерден негизги айырмасы.
Бул киришүү бөлүгү болчу, келгиле уланталы.
Операторубузду кантип курабыз? Биз ClickHouse кластерин бирдиктүү ресурс катары башкаруу үчүн маселени чечүүгө аракет кылып жатабыз.
Бул жерде биз сүрөттүн сол жагында киргизүү маалыматтары бар. Бул кластердик спецификациясы бар YAML, ал kubectl аркылуу классикалык жол менен Kubernetesке берилет. Ошол жерден биздин оператор аны алып, сыйкырын жасайт. Ал эми чыгарууда биз төмөнкү схеманы алабыз. Бул Kubernetesтеги ClickHouse программасын ишке ашыруу.
Анан акырындык менен оператор кандайча иштей турганын, кандай типтүү тапшырмаларды чечсе болорун карап чыгабыз. Убакытыбыз чектелүү болгондуктан типтүү тапшырмаларды гана карап чыгабыз. Ал эми оператор чече ала турган нерселердин баары талкууланбайт.
Келгиле, практикадан баштайлы. Биздин долбоор толугу менен ачык булак болуп саналат, андыктан анын GitHub'та кантип иштээрин көрө аласыз. Жана сиз жөн гана аны ишке киргизгиңиз келсе, анда Quick Start Guide менен баштасаңыз болот деген ойдон чыга аласыз.
Эгер сиз майда-чүйдөсүнө чейин түшүнгүңүз келсе, анда биз документтерди аздыр-көптүр татыктуу түрдө сактоого аракет кылабыз.
Келгиле, практикалык маселеден баштайлы. Баарыбыз баштагыбыз келген биринчи милдет - бул биринчи мисалды кандайдыр бир жол менен иштетүү. Мен анын кантип иштээрин билбесем дагы, оператордун жардамы менен ClickHouseду кантип ишке киргизсем болот? Биз манифест жазып жатабыз, анткени... k8s менен бардык байланыш манифест аркылуу байланыш болуп саналат.
Бул абдан татаал манифест. Биз кызыл менен баса белгилеген нерсеге көңүл бурушубуз керек. Биз оператордон демо деп аталган кластер түзүүнү суранабыз.
Булар азыр негизги мисалдар. Сактагыч азырынча сүрөттөлгөн жок, бирок биз сактагычка бир аздан кийин кайтып келебиз. Азырынча биз кластердин өнүгүү динамикасын байкайбыз.
Биз бул манифестти түздүк. Биз аны операторубузга беребиз. Ал иштеген, сыйкырчылык кылган.
Биз консолду карайбыз. Үч компонент кызыктырат: Pod, эки Кызмат жана StatefulSet.
Оператор иштеди, биз ал эмнени жаратканын көрө алабыз.
Ал ушундай нерсени жаратат. Бизде ар бир реплика үчүн StatefulSet, Pod, ConfigMap, бүт кластер үчүн ConfigMap бар. Кызматтар кластерге кирүү чекиттери катары талап кылынат.
Кызматтар жүктөөнү тең салмактоочу борбордук кызмат болуп саналат жана аларды ар бир реплика үчүн, ар бир сынык үчүн колдонсо болот.
Биздин негизги кластер ушундай көрүнөт. Бул бир түйүндөн.
Келгиле, андан ары баралы жана ишти татаалдаштыралы. Биз кластерди бөлүшүбүз керек.
Биздин милдеттерибиз өсүүдө, динамика башталат. Биз сынык кошкубуз келет. Биз өнүгүүнү ээрчип жатабыз. Биз спецификациябызды өзгөртүп жатабыз. Биз эки сынык керек экенин көрсөтүп турат.
Бул системанын өсүшү менен динамикалуу өнүгүп жаткан ошол эле файл. Сактоо жок, сактоо мындан ары талкууланат, бул өзүнчө тема.
Биз YAML операторун азыктандырып, эмне болорун көрөбүз.
Оператор ойлонуп, төмөнкү объекттерди жасады. Бизде буга чейин эки Pod, үч Кызмат жана күтүлбөгөн жерден 2 StatefulSets бар. Эмне үчүн 2 StatefulSets?
Диаграммада ал мындай болгон - бул биздин баштапкы абалыбыз, бизде бир капчык болгон кезде.
Ушундай болуп калды. Азырынча баары жөнөкөй, кайталанып келген.
Эмне үчүн эки StatefulSets болуп калды? Бул жерде биз Kubernetesте Pods кантип башкарылат деген суроону четке кагып, талкуулашыбыз керек.
Калыптан Pods топтомун түзүүгө мүмкүндүк берген StatefulSet деп аталган объект бар. Бул жерде негизги фактор шаблон болуп саналат. Жана сиз бир StatefulSet ичинде бир калыпты колдонуу менен көптөгөн Podтарды ишке киргизе аласыз. Жана бул жерде негизги сөз айкашы "бир шаблон үчүн көптөгөн Pods" болуп саналат.
Жана бүт кластерди түзүү, аны бир StatefulSetке топтоо үчүн чоң азгырык болду. Ал иштейт, аны менен эч кандай көйгөй жок. Бирок бир эскертүү бар. Эгерде биз гетерогендүү кластерди, башкача айтканда ClickHouseдун бир нече версияларынан чогултууну кааласак, анда суроолор жарала баштайт. Ооба, StatefulSet жаңыртууну жасай алат жана ал жерден сиз жаңы версияны чыгара аласыз, бир эле учурда мынча көп түйүндөрдү сынап көрүшүңүз керек экенин түшүндүрүңүз.
Бирок, эгерде биз тапшырманы экстраполяциялап, биз толугу менен гетерогендүү кластер түзгүбүз келет десек жана жаңыртуу аркылуу эски версиядан жаңысына өтүүнү каалабайбыз, бирок биз жөн гана эки жагынан тең гетерогендүү кластерди түзгүбүз келет. ClickHouse ар кандай версияларынын жана ар кандай сактоо жагынан. Биз, мисалы, өзүнчө дисктерде, жай дисктерде репликаларды жасоону, жалпысынан гетерогендүү кластерди толугу менен курууну каалайбыз. StatefulSet бир калыптан стандартташтырылган чечим чыгаргандыктан, муну жасоонун эч кандай жолу жок.
Ойлонуп отуруп ушундай кылабыз деген чечимге келдик. Бизде ар бир реплика өзүнүн StatefulSet ичинде бар. Бул чечимдин кээ бир кемчиликтери бар, бирок иш жүзүндө мунун баары оператор тарабынан толугу менен камтылган. Жана көптөгөн артыкчылыктар бар. Биз каалаган кластерди, мисалы, таптакыр гетерогендүү түзө алабыз. Ошондуктан, бир репликасы бар эки сыныкыбыз бар кластерде бизде 2 StatefulSets жана 2 Pod болот, анткени биз гетерогендүү кластерди түзө алуу үчүн жогоруда айтылган себептерден улам ушул ыкманы тандадык.
Келгиле, практикалык маселелерге кайрылып көрөлү. Биздин кластерде биз колдонуучуларды конфигурациялашыбыз керек, б.а. сиз Kubernetesте ClickHouse конфигурациясын жасашыңыз керек. Бул үчүн оператор бардык мүмкүнчүлүктөрдү берет.
Биз каалаган нерсени YAMLде түз жаза алабыз. Бардык конфигурация параметрлери түздөн-түз ушул YAMLден ClickHouse конфигурацияларына түшүрүлөт, алар андан кийин кластер боюнча бөлүштүрүлөт.
Сиз ушундай жазсаңыз болот. Бул, мисалы. Сырсөз шифрленген болот. Бардык ClickHouse конфигурациясынын варианттары колдоого алынат. Бул жерде бир эле мисал.
Кластердин конфигурациясы ConfigMap катары бөлүштүрүлөт. Практикада ConfigMap жаңыртуусу дароо пайда болбойт, андыктан кластер чоң болсо, анда конфигурацияны түртүү процесси бир аз убакытты талап кылат. Бирок мунун баары колдонууга абдан ыңгайлуу.
Келгиле, тапшырманы татаалдаштыралы. Кластер өнүгүп жатат. Биз маалыматтарды кайталагыбыз келет. Башкача айтканда, бизде эки сынык бар, ар бири бирден реплика жана колдонуучулар конфигурацияланган. Биз өсүп жатабыз жана репликация кылгыбыз келет.
Репликация үчүн бизге эмне керек?
Бизге ZooKeeper керек. ClickHouse'да репликация ZooKeeper аркылуу курулат. ZooKeeper ар кандай ClickHouse репликалары кайсы маалымат блоктору кайсы ClickHouseда жайгашканы боюнча консенсуска ээ болушу үчүн керек.
ZooKeeper каалаган адам колдоно алат. Эгерде ишканада тышкы ZooKeeper бар болсо, анда аны колдонсо болот. Болбосо, аны биздин репозиторийден орното аласыз. Мунун баарын жеңилдеткен орнотуучу бар.
Ал эми бүт системанын өз ара аракеттенүү диаграммасы ушундай болуп чыгат. Бизде платформа катары Kubernetes бар. Бул ClickHouse операторун аткарат. Мен бул жерде ZooKeeperди сүрөткө түшүрдүм. Жана оператор ClickHouse жана ZooKeeper менен иштешет. Башкача айтканда, өз ара аракеттенүү натыйжалары.
Мунун баары ClickHouse үчүн k8sдеги маалыматтарды ийгиликтүү кайталоо үчүн зарыл.
Эми тапшырманын өзүн карап көрөлү, репликация манифести кандай болоорун.
Манифестибизге эки бөлүмдү кошуп жатабыз. Биринчиси, ZooKeeperди кайдан алуу керек, ал Kubernetes ичинде же тышкы болушу мүмкүн. Бул жөн гана сүрөттөмө. Жана биз копияларга заказ кылабыз. Ошол. биз эки репликасын каалайбыз. Бардыгы болуп, бизде 4 порода болушу керек. Сактоо жөнүндө эсибизде, ал бир аздан кийин кайтып келет. Сактоо өзүнчө окуя.
Ушундай болду.
Ушундай болуп калат. Репликалар кошулат. Төртүнчүсү туура келбей калды, ал жакта көп болушу мүмкүн деп ойлойбуз. Жана ZooKeeper тарапка кошулат. Схемалар татаал болуп баратат.
Ал эми кийинки тапшырманы кошууга убакыт келди. Туруктуу сактагычты кошобуз.
Туруктуу сактоо үчүн бизде ар кандай варианттар бар.
Биз булут провайдеринде иштеп жаткан болсок, мисалы, Amazon, Google колдонуп, анда булут сактагычты колдонууга чоң азгырык бар. Бул абдан ыңгайлуу, бул жакшы.
Жана экинчи вариант бар. Бул ар бир түйүндө локалдык дисктер болгондо, жергиликтүү сактоо үчүн. Бул вариантты ишке ашыруу алда канча татаал, бирок ошол эле учурда жемиштүү.
Келгиле, булуттагы сактагычта эмне бар экенин карап көрөлү.
Артыкчылыктары бар. Аны конфигурациялоо абдан оңой. Биз жөн гана булут провайдеринен заказ кылабыз, сураныч, бизге мындай жана мындай сыйымдуулукту, тигил же бул классты сактаңыз. Сабактар провайдерлер тарабынан өз алдынча пландаштырылат.
Жана кемчилиги бар. Кээ бирөөлөр үчүн бул олуттуу эмес кемчилик. Албетте, кээ бир аткаруу маселелери болот. Бул колдонуу үчүн абдан ыңгайлуу жана ишенимдүү, бирок кээ бир мүмкүн болгон аткаруу кемчиликтери бар.
Жана Себеби ClickHouse өзгөчө өндүрүмдүүлүккө көңүл бурат, ал тургай, ал мүмкүн болгон нерселердин баарын кысып коёт деп айтууга болот, ошондуктан көптөгөн кардарлар максималдуу өндүрүмдүүлүктү сыкканга аракет кылышат.
Ал эми андан максималдуу пайда алуу үчүн бизге жергиликтүү сактагыч керек.
Kubernetes жергиликтүү сактагычты колдонуу үчүн үч абстракцияны камсыз кылат. Бул:
- EmptyDir
- HostPath.
- жергиликтүү
Келгиле, алар кандайча айырмаланып, кандайча окшош экенин карап көрөлү.
Биринчиден, бардык үч ыкмада бизде сактагыч бар - бул бир эле физикалык k8s түйүнүндө жайгашкан жергиликтүү дисктер. Бирок алардын айрым айырмачылыктары бар.
Эң жөнөкөй, башкача айтканда emptyDir менен баштайлы. Бул иш жүзүндө эмне? Биздин спецификацияда биз контейнерлештирүү тутумунан (көбүнчө Docker) жергиликтүү дисктеги папкага кирүү мүмкүнчүлүгүн берүүнү суранабыз.
Иш жүзүндө, Docker өзүнүн жолдору боюнча бир жерде убактылуу папканы түзөт жана аны узун хэш деп атайт. Жана ага жетүү үчүн интерфейсти камсыз кылат.
Бул кандайча иштешет? Бул жергиликтүү диск ылдамдыгында иштейт, б.а. Бул сиздин бурамага толук мүмкүнчүлүк.
Бирок бул иштин кемчилиги бар. Persistent бул маселеде өтө күмөндүү. Docker биринчи жолу контейнерлер менен кыймылдаганда, Persistent жоголот. Эгерде Kubernetes бул Podду кандайдыр бир себептерден улам башка дискке жылдыргысы келсе, маалыматтар жоголот.
Бул ыкма тесттер үчүн жакшы, анткени ал кадимки ылдамдыкты көрсөтүп турат, бирок олуттуу нерсе үчүн бул параметр ылайыктуу эмес.
Ошондуктан экинчи ыкма бар. Бул hostPath. Мурунку жана бул слайдды карасаңыз, бир гана айырманы көрө аласыз. Биздин папка Докерден түздөн-түз Kubernetes түйүнүнө жылды. Бул жерде бир аз жөнөкөй. Биз жергиликтүү файл тутумунда дайындарыбызды сактагыбыз келген жолду түз көрсөтөбүз.
Бул ыкманын артыкчылыктары бар. Бул мурунтан эле чыныгы Persistent жана классикалык. Бизде кайсы бир дарек боюнча дискке жазылган маалыматтар болот.
Кемчиликтери да бар. Бул башкаруунун татаалдыгы. Биздин Kubernetes Pod башка физикалык түйүнгө жылдырууну каалашы мүмкүн. Бул жерде DevOps ойнойт. Ал бүткүл системага туура түшүндүрүшү керек, бул поддондорду ушул жолдор боюнча бир нерсе орнотулган түйүндөргө гана жылдырса болот жана бир эле учурда бирден ашык түйүн жок. Бул абдан кыйын.
Айрыкча, ушул максаттар үчүн биз операторубузда ушул татаалдыктын баарын жашыруу үчүн шаблондорду жасадык. Жана сиз жөн гана айта аласыз: "Мен ар бир физикалык түйүн үчүн ClickHouse бирден нускасын жана тиги же бул жолдун боюнда болгум келет."
Бирок бул муктаждыкка биз гана муктаж эмеспиз, ошондуктан Кубернетес мырзалар да адамдар физикалык дисктерге жетүүнү каалаарын түшүнүшөт, ошондуктан алар үчүнчү катмарды камсыз кылышат.
Бул жергиликтүү деп аталат. Мурунку слайддан дээрлик эч кандай айырмасы жок. Буга чейин гана биз бул кабыктарды түйүндөн түйүнгө өткөрө албай турганыбызды кол менен ырастоо керек болчу, анткени алар кандайдыр бир жол менен локалдык физикалык дискке тиркелиши керек, бирок азыр бул билимдин баары Кубернетестин өзүндө камтылган. Жана аны конфигурациялоо бир топ жеңил болуп чыкты.
Биздин практикалык проблемабызга кайрылып көрөлү. YAML шаблонуна кайрылып көрөлү. Бул жерде бизде чыныгы сактагыч бар. Биз ага кайтып келдик. Биз классикалык VolumeClaim үлгүсүн k8sдегидей койдук. Жана биз кандай сактоону каалайбыз.
Андан кийин k8s сактагычты сурайт. Аны бизге StatefulSetте бөлүп берет. Акыр-аягы, ал ClickHouse'дун карамагында болот.
Бизде ушундай схема бар болчу. Туруктуу сактагычыбыз кызарып турду, бул муну жасаш керек экенин кыйытты.
Жана ал жашылга айланат. Азыр ClickHouse on k8s кластердик схемасы толугу менен аяктады. Бизде сыныктар, репликалар, ZooKeeper бар, бизде тигил же бул жол менен ишке ашырылган чыныгы Persistent бар. Схема азыртан эле толугу менен иштеп жатат.
Жашоону улантабыз. Биздин кластер өнүгүп жатат. Ал эми Алексей аракет кылып, ClickHouse жаңы версиясын чыгарат.
Практикалык тапшырма пайда болот - биздин кластерибизде ClickHouse жаңы версиясын сыноо. Жана, албетте, сиз мунун баарын чыгаргыңыз келбейт; сиз жаңы версияны алыскы бурчта бир репликага салгыңыз келет, балким, бир жаңы версия эмес, бир эле учурда экөө, анткени алар тез-тез чыгып турат.
Бул тууралуу эмне айта алабыз?
Мына бизде дал ушундай мүмкүнчүлүк бар. Бул подкладка шаблондор. Биздин оператор толугу менен гетерогендүү кластерди курууга мүмкүндүк берет деп жаза аласыз. Ошол. конфигурациялоо, бир тутамдагы бардык репликалардан баштап, ар бир жеке репликага чейин, биз ClickHouse версиясын, кайсы версиясын сактоону каалайбыз. Биз кластерди өзүбүзгө керектүү конфигурация менен толук конфигурациялай алабыз.
Келгиле, ичине бир аз тереңирээк баралы. Буга чейин биз ClickHouse-оператордун ClickHouse өзгөчөлүктөрүнө карата кандайча иштээри жөнүндө сүйлөштүк.
Эми мен кандайдыр бир оператордун жалпысынан кандайча иштеши, ошондой эле анын K8s менен өз ара аракеттенүүсү жөнүндө бир нече сөз айткым келет.
Келгиле, алгач K8s менен өз ара аракеттенүүнү карап көрөлү. Биз kubectl колдонгондо эмне болот? Биздин объекттер API аркылуу etcd ичинде пайда болот.
Мисалы, негизги Kubernetes объекттери: pod, StatefulSet, кызмат жана башкалар.
Ошол эле учурда физикалык эч нерсе болбойт. Бул объекттер кластерде материализацияланышы керек.
Бул үчүн, контроллер пайда болот. Контроллер бул сүрөттөмөлөрдү ишке ашыра турган атайын k8s компоненти. Ал физикалык жактан кантип жана эмне кылуу керектигин билет. Ал контейнерлерди кантип иштетүүнү, сервер иштеши үчүн ал жерде эмнелерди конфигурациялоо керектигин билет.
Жана ал биздин объектилерибизди K8де материалдаштырат.
Бирок биз бир гана pods жана StatefulSets менен иштегибиз келбейт, биз ClickHouseInstallation түзүүнү каалайбыз, б.а. ClickHouse тибиндеги объект, аны менен бүтүндөй иштөө үчүн. Азырынча андай мүмкүнчүлүк жок.
Бирок K8s төмөнкү жакшы нерсеге ээ. Биздин кластерибиз поддондордон жана StatefulSetтен чогула турган ушул татаал объект сыяктуу бир жерде болушубузду каалайбыз.
Жана бул үчүн эмне кылуу керек? Биринчиден, Custom Resource Definition сүрөткө кирет. Бул эмне? Бул K8s үчүн сүрөттөмө, сизде дагы бир маалымат түрүнө ээ болот, биз Pod, StatefulSet үчүн ыңгайлаштырылган ресурсту кошкубуз келет, ал ичи татаал болот. Бул маалымат структурасынын сүрөттөлүшү.
Биз аны kubectl application аркылуу да жөнөтөбүз. Кубернетес кубануу менен кабыл алды.
Эми биздин сактагычта etcd объекти ClickHouseInstallation деп аталган ыңгайлаштырылган ресурсту жаздыруу мүмкүнчүлүгүнө ээ.
Бирок азырынча мындан ары эч нерсе болбойт. Башкача айтканда, эгер биз азыр сыныктарды жана репликаларды сүрөттөгөн YAML файлын түзүп, "kubectl колдонулат" деп айтсак, анда Кубернетес аны кабыл алып, etcd ичинде коет жана мындай дейт: "Сонун, бирок мен эмне кылышты билбейм. аны менен. Мен ClickHouseInstallation кантип сактоону билбейм."
Демек, бизге Kubernetes жаңы маалымат түрүн тейлөөгө жардам бере турган бирөө керек. Сол жакта бизде жергиликтүү маалымат түрлөрү менен иштеген жергиликтүү Kubernetes контроллери бар. Ал эми оң жакта бизде ыңгайлаштырылган маалымат түрлөрү менен иштей ала турган жеке контроллер болушу керек.
Ал эми башка жол менен оператор деп аталат. Мен аны атайын Kubernetes катары киргиздим, анткени ал K8ден тышкары да аткарылышы мүмкүн. Көбүнчө, албетте, бардык операторлор Kubernetesте аткарылат, бирок анын сыртта туруусуна эч нерсе тоскоол болбойт, ошондуктан бул жерде ал атайын сыртка жылдырылат.
Жана өз кезегинде, ыңгайлаштырылган контроллер, ошондой эле оператор катары белгилүү, API аркылуу Kubernetes менен иштешет. Ал мурунтан эле API менен кантип иштешүүнү билет. Ал эми биз заказдык ресурстан жасагыбыз келген татаал схеманы кантип ишке ашырууну билет. Бул оператор так ушундай кылат.
Оператор кандай иштейт? Келгиле, ал муну кантип кылганын көрүү үчүн оң жагын карап көрөлү. Келгиле, оператор мунун баарын кантип ишке ашырарын жана K8s менен мындан аркы өз ара аракеттенүү кантип пайда болорун карап көрөлү.
Оператор бул программа. Ал окуяга багытталган. Оператор Kubernetes API аркылуу окуяларга жазылат. Kubernetes API'де окуяларга жазыла турган кирүү пункттары бар. Эгерде K8де бир нерсе өзгөрсө, анда Kubernetes окуяларды баарына жөнөтөт, б.а. ким бул API пунктуна жазылган болсо, эскертмелерди алат.
Оператор окуяларга жазылат жана кандайдыр бир реакция жасашы керек. Анын милдети пайда болгон окуяларга жооп берүү болуп саналат.
Окуялар белгилүү жаңыртуулар менен түзүлөт. ClickHouseInstallation сүрөттөмөсү менен YAML файлыбыз келет. Ал kubectl колдонмосу аркылуу etcdге барган. Ал жерде окуя козголуп, натыйжада бул окуя ClickHouse-операторуна келди. Оператор бул сүрөттөмө алды. Анан ал бир нерсе кылышы керек. ClickHouseInstallation объекти үчүн жаңыртуу келсе, анда кластерди жаңыртышыңыз керек. Ал эми оператордун милдети кластерди жаңылоо.
Ал эмне кылып жатат? Биринчиден, биз бул жаңыртуу менен эмне кыла турган иш-аракеттердин планын түзүшүбүз керек. Жаңыртуулар өтө аз болушу мүмкүн, б.а. YAML аткарууда кичинекей, бирок кластерде абдан чоң өзгөрүүлөргө алып келиши мүмкүн. Ошондуктан оператор план түзүп, анан ага жабышат.
Бул планга ылайык, ал подъезддерди, кызматтарды, б.а. анын негизги милдети эмне болсо. Kubernetesте ClickHouse кластерин кантип куруу керек.
Эми ушундай кызыктуу нерсеге токтоло кетели. Бул Kubernetes менен оператордун ортосундагы жоопкерчиликти бөлүштүрүү, б.а. Kubernetes эмне кылат, оператор эмне кылат жана алар бири-бири менен кантип иштешет.
Кубернетес системалык нерселер үчүн жооптуу, б.а. система-чөйрөсү катары чечмелене турган объекттердин негизги топтому үчүн. Кубернетес поддондорду кантип ишке киргизүүнү, контейнерлерди кантип кайра баштоону, томдорду кантип орнотууну, ConfigMap менен кантип иштөөнү билет, б.а. система деп атоого болот баары.
Операторлор домендерде иштешет. Ар бир оператор өзүнүн предметтик аймагы үчүн жасалган. Биз муну ClickHouse үчүн жасадык.
Ал эми оператор так предметтик чөйрө боюнча өз ара аракеттенет, мисалы, репликаны кошуу, диаграмма түзүү, мониторингди орнотуу. Бул бөлүнүүгө алып келет.
Кошумча реплика аракетин жасаганда жоопкерчиликти бул бөлүштүрүү кандайча пайда болорун практикалык мисалга карап көрөлү.
Оператор тапшырма алат - репликаны кошуу. Оператор эмне кылат? Оператор жаңы StatefulSet түзүлүшү керек экенин эсептеп чыгат, анда ушуга окшогон шаблондор, көлөм талаптары сүрөттөлүшү керек.
Ал баарын даярдап, K8s өткөрүп берет. Ал ConfigMap, StatefulSet, Volume керек дейт. Kubernetes иштеп жатат. Ал иштеген негизги агрегаттарды материалдаштырат.
Ошондо ClickHouse-оператор кайрадан оюнга кирет. Ал мурунтан эле бир нерсе кыла турган физикалык подкесине ээ. Жана ClickHouse-оператор кайра домен шарттарында иштейт. Ошол. Тактап айтканда ClickHouse, репликаны кластерге кошуу үчүн, биринчиден, бул кластерде бар маалымат схемасын конфигурациялашыңыз керек. Экинчиден, бул репликаны так байкоо үчүн мониторингге киргизүү керек. Оператор муну мурунтан эле конфигурациялаган.
Ошондон кийин гана ClickHouse өзү ишке кирет, б.а. дагы бир жогорку деңгээлдеги объект. Бул мурунтан эле маалымат базасы. Анын өзүнүн инстанциясы, кластерге кошулууга даяр башка конфигурацияланган репликасы бар.
Көрсө, репликаны кошууда аткаруу жана жоопкерчиликти бөлүштүрүү чынжырчасы кыйла узун экен.
Биз практикалык милдеттерибизди улантабыз. Эгер сизде кластер бар болсо, конфигурацияны көчүрө аласыз.
Биз аны ClickHouse түшүнгөн учурдагы xml аркылуу чапташыңар үчүн жасадык.
Сиз ClickHouse'ду жакшырта аласыз. Жөн гана зоналаштырылган жайгаштыруу - бул hostPath, жергиликтүү сактагычты түшүндүрүп жатканда мен айткан нерсе. Райондук жайгаштырууну кантип туура жасоо керек.
Кийинки практикалык милдет - мониторинг.
Эгерде биздин кластер өзгөрсө, анда биз мезгил-мезгили менен мониторингди конфигурациялашыбыз керек.
Келгиле, диаграмманы карап көрөлү. Биз буга чейин бул жерде жашыл жебелерди карап чыктык. Эми кызыл жебелерди карап көрөлү. Мына ушундайча биз кластерибизди көзөмөлдөгүбүз келет. ClickHouse кластериндеги көрсөткүчтөр кантип Прометейге, анан Графанага кирет.
Мониторингдин кандай кыйынчылыгы бар? Эмне үчүн бул кандайдыр бир жетишкендик катары көрсөтүлөт? Кыйынчылык динамикада. Бизде бир кластер болгондо жана ал статикалык болгондо, биз мониторингди бир жолу орнотуп, андан ары убара болбой алабыз.
Бирок бизде кластерлер көп болсо, же бир нерсе тынымсыз өзгөрүп турса, анда процесс динамикалуу. Ал эми мониторингди дайыма реконфигурациялоо – бул ресурстарды жана убакытты текке кетирүү, б.а. ал тургай жалкоолук. Муну автоматташтыруу керек. Кыйынчылык процесстин динамикасында. Ал эми оператор муну абдан жакшы автоматташтырат.
Биздин кластер кантип өнүккөн? Башында ал ошондой болгон.
Анан ал ушундай болгон.
Акыры ушундай болуп калды.
Ал эми мониторинг оператор тарабынан автоматтык түрдө жүргүзүлөт. Бирдиктүү кирүү чекити.
Ал эми жөн эле чыгууда биз кластерибиздин жашоосу кандайча кайнап жатканын көрүү үчүн Grafana панелин карайбыз.
Баса, Grafana панели биздин оператор менен түздөн-түз баштапкы коддо бөлүштүрүлөт. Сиз туташып, колдоно аласыз. Биздин DevOps мага бул скриншотту берди.
Андан ары кайда баргыбыз келет? Бул:
- Сыноолорду автоматташтыруу. Негизги милдет - жаңы версияларды автоматташтырылган тестирлөө.
- Биз ошондой эле ZooKeeper менен интеграцияны автоматташтырууну каалайбыз. Жана ZooKeeper-оператор менен интеграциялоо пландары бар. Ошол. ZooKeeper үчүн оператор жазылган жана эки оператордун ыңгайлуураак чечимди түзүү үчүн интеграциялана баштаганы логикалык.
- Биз дагы татаал турмуштук белгилерди жасагыбыз келет.
- Калыптарды мурастоого жакындап калганыбызды жашыл түс менен баса белгиледим - АТКАРЫЛДЫ, б.а. оператордун кийинки релизинде бизде калыптардын мурасы болот. Бул бөлүктөрдөн татаал конфигурацияларды түзүүгө мүмкүндүк берген күчтүү курал.
- Ал эми биз татаал милдеттерди автоматташтырууну каалайбыз. Негизгиси - кайра бөлүштүрүү.
Келгиле, ортодогу жыйынтыктарды алалы.
Натыйжада биз эмне алабыз? Жана муну жасоого татыктуубу же жокпу? Маалымат базасын Кубернетеске сүйрөп, жалпысынан операторду жана өзгөчө Alitnity операторун колдонууга аракет кылуу керекпи?
Жыйынтыгында биз төмөнкүлөрдү алабыз:
- Конфигурациялоону, жайгаштырууну жана тейлөөнү олуттуу жөнөкөйлөштүрүү жана автоматташтыруу.
- Ошол замат орнотулган мониторинг.
- Жана татаал кырдаалдар үчүн колдонууга даяр кодификацияланган шаблондор. Репликаны кошуу сыяктуу аракетти кол менен жасоонун кереги жок. Оператор муну жасайт.
Акыркы бир гана суроо калды. Бизде Kubernetes, виртуалдаштырууда маалымат базасы бар. Мындай чечимдин иштеши жөнүндө эмне айтууга болот, айрыкча ClickHouse аткаруу үчүн оптималдаштырылгандыктан?
Жооп - баары жакшы! Мен майда-чүйдөсүнө чейин айтпай эле коёюн, бул өзүнчө баяндаманын темасы.
Бирок TSBS сыяктуу долбоор бар. Анын негизги милдети эмнеде? Бул маалымат базасынын аткаруу сыноо. Бул жылуу менен жылуу, жумшак менен жумшак салыштыруу аракети.
Ал кантип иштейт? Бир маалымат топтому түзүлөт. Андан кийин бул маалыматтар топтому бир эле тесттер топтомун колдонуу менен ар кандай маалымат базаларында иштетилет. Жана ар бир маалымат базасы бир көйгөйдү кантип чечет. Ошондо сиз жыйынтыктарды салыштыра аласыз.
Ал буга чейин маалымат базаларынын чоң тобун колдойт. Мен негизги үчөөнү аныктадым. Бул:
- TimescaleDB.
- InfluxDB.
- ClickHouse.
Башка окшош чечим менен салыштыруу да жасалган. RedShift менен салыштыруу. Салыштыруу Amazonда жасалган. ClickHouse да бул маселеде баарынан алдыда.
Менин айтканымдан кандай жыйынтык чыгарса болот?
- Kubernetesтеги DB мүмкүн. Кыязы, баары мүмкүн, бирок жалпысынан бул мүмкүн окшойт. Kubernetesтеги ClickHouse, албетте, биздин оператордун жардамы менен мүмкүн.
- Оператор процесстерди автоматташтырууга жардам берет жана чындыгында жашоону жеңилдетет.
- Аткаруу нормалдуу.
- Жана бизге муну колдонууга болот жана керектей сезилет.
Ачык булак - бизге кошулуңуз!
Мен буга чейин айткандай, оператор толугу менен ачык булак продукт болуп саналат, ошондуктан адамдардын максималдуу саны аны колдонгон болсо, абдан жакшы болмок. Бизге кошул! Баарыңыздарды күтөбүз!
рахмат!
суроолор
Баяндама үчүн рахмат! Менин атым Антон. Мен SEMrush шаарынан болом. Мен логистика эмне болуп жатат деп ойлоп жатам. Мониторинг жөнүндө угабыз, бирок бүткүл кластер жөнүндө айтсак, каротаждоо жөнүндө эч нерсе жок. Мисалы, биз аппараттык камсыздоо боюнча кластерди көтөрдүк. Жана биз борборлоштурулган журналды колдонобуз, аларды стандарттуу каражаттарды колдонуу менен жалпы үймөккө чогултабыз. Анан ошол жерден бизди кызыктырган маалыматтарды алабыз.
Жакшы суроо, б.а. todo тизмесине кирүү. Биздин оператор муну азырынча автоматташтыра элек. Ал дагы эле өнүгүп жатат, долбоор дагы эле жаш. Биз токойду кесүү зарылдыгын түшүнөбүз. Бул да абдан маанилүү тема. Жана бул, балким, мониторингден кем эмес маанилүү. Бирок ишке ашыруу үчүн тизмеде биринчи кезекте мониторинг болгон. Каттоо болот. Албетте, биз кластердин жашоосунун бардык аспектилерин автоматташтырууга аракет кылабыз. Ошондуктан, жооп: азыркы учурда оператор, тилекке каршы, муну кантип жасоону билбейт, бирок бул пландарда бар, биз муну жасайбыз. Эгер сиз кошулууну кааласаңыз, анда суранычты тартыңыз.
Салам! Баяндама үчүн рахмат! Менде Туруктуу томдорго байланыштуу стандарттуу суроом бар. Бул оператор менен конфигурацияны түзгөнүбүздө, оператор кайсы түйүндө бизде кайсы диск же папка тиркелгенин кантип аныктайт? Адегенде ага ClickHouse'ду диски бар түйүндөргө жайгаштырууну түшүндүрүшүбүз керек?
Мен түшүнгөндөй, бул суроо жергиликтүү сактоонун уландысы, айрыкча анын hostPath бөлүгү. Бул бүткүл системага поддонду тигил же бул түйүндө ишке киргизүү керек экенин түшүндүрүү сыяктуу, бизде физикалык жактан туташтырылган диск бар, ал тигил же бул жолдун боюнда орнотулган. Бул мен өтө үстүртөн козгогон бүт бөлүм, анткени ал жерде жооп абдан чоң.
Кыскача мындай көрүнөт. Албетте, биз бул көлөмдөрдү камсыз кылышыбыз керек. Азыркы учурда, жергиликтүү сактагычта динамикалык камсыздоо жок, ошондуктан DevOps дисктерди, бул көлөмдөрдү өздөрү кесип алышы керек. Жана алар Kubernetes жоболорун түшүндүрүп бериши керек, сизде тигил же бул түйүндөрдө жайгашкан мындай класстын туруктуу томдору болот. Андан кийин сиз Кубернетеске мындай жана ушундай локалдык сактоо классын талап кылган поддондорду этикеткаларды колдонуп, тигил же бул түйүндөргө гана багыттоо керек экендигин түшүндүрүшүңүз керек болот. Бул максаттар үчүн оператор кандайдыр бир белгини жана ар бир хост инстанциясын дайындоо мүмкүнчүлүгүнө ээ. Көрсө, подколор Kubernetes тарабынан жөнөкөй тил менен айтканда талаптарга, энбелгилерге жооп берген түйүндөрдө гана иштетилет. Администраторлор энбелгилерди жана дисктерди кол менен дайындайт. Анан масштабдуу.
Ал эми үчүнчү вариант, жергиликтүү, муну бир аз жеңилдетүүгө жардам берет. Мен буга чейин баса белгилегендей, бул тюнинг боюнча талыкпай иш, ал акыры максималдуу аткарууну алууга жардам берет.
Ушуга байланыштуу экинчи суроом бар. Кубернетес түйүндү жоготконубуз же жоготпосубуз бизге маанилүү эмес кылып иштелип чыккан. Эгерде сыныгыбыз илинип турган түйүнүбүздү жоготуп алган болсок, бул учурда эмне кылышыбыз керек?
Ооба, Кубернетес башында биздин кабыктарыбыз менен болгон мамилебиз малга окшош деп ойлогон, бирок бул жерде биз менен ар бир диск үй жаныбары сыяктуу бир нерсеге айланат. Аларды ыргытып жибере албай тургандай бир маселе бар. Ал эми Кубернетестин өнүгүшү ага толугу менен философиялык жактан мамиле кылуу мүмкүн эмес деген багытта баратат, ал толугу менен ташталган ресурс сыяктуу.
Эми практикалык суроо үчүн. Эгер диск турган түйүн жоголсо, эмне кылуу керек? Бул жерде маселе жогорку денгээлде чечилип жатат. ClickHouse учурда бизде жогорку деңгээлде иштеген репликалар бар, б.а. ClickHouse деңгээлинде.
Жыйынтык кандай болот? DevOps дайындар жоголуп кетпеши үчүн жооптуу. Ал репликацияны туура орнотушу керек жана репликация иштеп жатканын камсыз кылышы керек. ClickHouse деңгээлиндеги репликада кайталанган маалыматтар болушу керек. Бул оператор чече турган маселе эмес. Кубернетес өзү чечкен көйгөй эмес. Бул ClickHouse деңгээлинде.
Сиздин темир түйүн түшүп калса, эмне кылуу керек? Ал эми экинчисин орнотуп, андагы дискти туура камсыздап, этикеткаларды колдонушуңуз керек болот экен. Ошондон кийин, ал Kubernetes ага инстанция подкабын ишке киргизе турган талаптарга жооп берет. Kubernetes аны ишке киргизет. Белгиленген санга жооп берүү үчүн сиздин капчыктарыңыздын саны жетишсиз. Ал мен көрсөткөн циклден өтөт. Жана эң жогорку деңгээлде ClickHouse биз репликаны киргизгенибизди түшүнөт, ал дагы эле бош жана биз ага маалыматтарды өткөрүп башташыбыз керек. Ошол. Бул процесс азырынча жакшы автоматташтырылган эмес.
Баяндама үчүн рахмат! Ар кандай жагымсыз нерселер болгондо, оператор бузулуп, кайра иштетилип, ошол учурда окуялар келип калганда, сиз муну кандайдыр бир жол менен чечесизби?
Оператор бузулуп, кайра иштетилсе эмне болот, туурабы?
Ооба. Ошондо окуялар келип жетти.
Бул учурда эмне кылуу милдети жарым-жартылай оператор менен Kubernetes ортосунда бөлүштүрүлөт. Kubernetes болгон окуяны кайра ойнотуу мүмкүнчүлүгүнө ээ. Ал кайталайт. Ал эми оператордун милдети окуя журналы ага кайталанганда, бул окуялар идемпотенттүү экенине ынануу болуп саналат. Жана ошол эле окуянын кайталануусу системабызды бузбашы үчүн. Ал эми биздин оператор бул милдетти аткарат.
Салам! Баяндама үчүн рахмат! Дмитрий Завьялов, компания Смедова. Операторго haproxy менен конфигурациялоо мүмкүнчүлүгүн кошуу пландары барбы? Мен стандарттуудан башка дагы башка балансизаторго кызыгып кетмекмин, ал акылдуу жана ClickHouse чындыгында бар экенин түшүнөт.
Сиз Ingress жөнүндө айтып жатасызбы?
Ооба, Ingress'ти гапрокси менен алмаштырыңыз. Гапроксиде сиз репликалары бар кластердин топологиясын көрсөтө аласыз.
Биз ал жөнүндө ойлоно элекпиз. Эгер ал сизге керек болсо жана эмне үчүн керек экенин түшүндүрө алсаңыз, анда аны ишке ашырууга мүмкүн болот, айрыкча катышууну кааласаңыз. Биз вариантты карап чыгууга кубанычта болобуз. Кыска жооп - жок, бизде учурда андай функция жок. Кеңешиңиз үчүн рахмат, биз бул маселени карап чыгабыз. Эгер сиз ошондой эле колдонуу учурун жана эмне үчүн иш жүзүндө керек экенин түшүндүрүп берсеңиз, мисалы, GitHub'та маселелерди түзсөңүз, анда бул сонун болот.
Бар.
Жакшы. Биз бардык сунуштарга ачыкпыз. Жана haproxy todo тизмесине кошулат. Тодо тизмеси өсүүдө, али азайбайт. Бирок бул жакшы, бул продукт суроо-талапка ээ экенин билдирет.
Source: www.habr.com