После ви го претставуваме неговиот постар брат - . Ова е проект со отворен код кој се користи за инсталирање на системските компоненти во кластерот Kubernetes, кој може да се нарече додатоци.
Зошто воопшто некои додатоци?
Не е тајна дека Kubernetes не е готов производ сè-во-едно, а за да се изгради кластер за „возрасни“ ќе ви требаат разни додатоци. Додаток-оператор ќе ви помогне да ги инсталирате, конфигурирате и одржувате ажурирани овие додатоци.
Потребата од дополнителни компоненти во кластерот е откриена во Колеги . Накратко, ситуацијата со Kubernetes во моментот е таква што за едноставна инсталација „play around“ можете да поминете со компонентите надвор од кутијата, за програмери и тестирање можете да додадете Ingress, но за целосна инсталација, за што можете да кажете „вашето производство е подготвено“, треба да додадете со десетина различни додатоци: нешто за следење, нешто за евидентирање, не заборавајте за влез и серти-менаџер, изберете групи на јазли, додадете мрежни политики, сезона со поставки за автоматско мерење на sysctl и pod...
Кои се спецификите за работа со нив?
Како што покажува практиката, работата не е ограничена на една инсталација. За удобно работење со кластерот, додатоците ќе треба да се ажурираат, оневозможат (отстранат од кластерот) и ќе сакате да тестирате некои пред да ги инсталирате во производниот кластер.
Значи, можеби Ansible ќе биде доволно овде? Можеби. Но Во принцип, полноправните додатоци не живеат без поставки. Овие поставки може да се разликуваат во зависност од варијантата на кластерот (aws, gce, azure, bare-metal, do, ...). Некои поставки не можат да се наведат однапред, тие мора да се добијат од кластерот. И кластерот не е статичен: за некои поставки ќе треба да ги следите промените. И тука Ansible веќе недостасува: ви треба програма што живее во кластер, т.е. Оператор Кубернетес.
Оние кои го пробаа на работа , тие ќе кажат дека задачите за инсталирање и ажурирање на додатоците и поставките за следење може целосно да се решат користејќи за школка-оператор. Можете да напишете скрипта што ќе направи условно kubectl apply и следете, на пример, ConfigMap, каде што ќе се складираат поставките. Ова е приближно она што е имплементирано во додаток-оператор.
Како е ова организирано во додаток-оператор?
Кога креиравме ново решение, постапивме од следниве принципи:
- Инсталаторот за додатоци мора да поддржува шаблон и декларативна конфигурација. Ние не правиме магични скрипти кои инсталираат додатоци. Додаток-оператор користи Helm за да инсталира додатоци. За да инсталирате, треба да креирате графикон и да ги изберете вредностите што ќе се користат за конфигурација.
- Поставките може да бидат генерира при инсталација, тие можат да бидат добие од кластеротИли добиваат ажурирања, следење на ресурсите на кластерот. Овие операции може да се спроведат со помош на куки.
- Поставките може да бидат складирајте во кластер. За да се зачуваат поставките во кластерот, се креира ConfigMap/addon-operator и Addon-operator ги следи промените на оваа ConfigMap. Додаток-оператор им дава на куките пристап до поставките користејќи едноставни конвенции.
- Додавањето зависи од поставките. Ако поставките се променети, тогаш Addon-операторот го прикажува дијаграмот Helm со нови вредности. Комбинацијата на дијаграмот на Helm, вредностите за неа и закачувањето ја нарековме модул (видете подолу за повеќе детали).
- Станирање. Нема волшебни скрипти за издавање. Механизмот за ажурирање е сличен на обична апликација - собирајте додатоци и оператори за додатоци во слика, означете ги и распространете ги.
- Контрола на резултат. Додаток-оператор може да обезбеди метрика за Prometheus.
Што е полнење во додаток-оператор?
Додавка може да се смета за сè што додава нови функции во кластерот. На пример, инсталирањето Ingress е одличен пример за додаток. Ова може да биде кој било оператор или контролер со сопствен CRD: прометеј-оператор, серт-менаџер, кубе-контролер-менаџер итн. Или нешто мало, но полесно за користење - на пример, таен копир, кој ги копира тајните на регистарот во нови именски простори или sysctl тјунер, кој ги конфигурира параметрите на sysctl на нови јазли.
За имплементација на додатоци, Addon-оператор обезбедува неколку концепти:
- Табела на кормилото се користи за инсталирање различен софтвер во кластерот - на пример, Prometheus, Grafana, nginx-ingress. Ако потребната компонента има дијаграм на Helm, тогаш ќе биде многу едноставно да се инсталира со помош на Addon-оператор.
- Складирање на вредности. Табелите на кормилото обично имаат многу различни поставки кои можат да се променат со текот на времето. Додаток-оператор поддржува складирање на овие поставки и може да ги следи нивните промени со цел повторно да ја инсталира дијаграмот на Helm со нови вредности.
- Куки се извршни датотеки кои Addon-операторот ги извршува на настани и кои пристапуваат до продавницата за вредности. Куката може да ги следи промените во кластерот и да ги ажурира вредностите во продавницата за вредности. Оние. Користејќи куки, можете да откриете за да соберете вредности од кластерот при стартување или според распоред, или можете да вршите континуирано откривање, собирајќи вредности од кластерот врз основа на промените во кластерот.
- Модул е комбинација од дијаграм на кормилото, складиште за вредности и куки. Модулите може да се овозможат или оневозможат. Оневозможувањето на модул значи бришење на сите изданија на дијаграмите на Helm. Модулите можат да се овозможат динамично, на пример, ако се овозможени сите модули што им се потребни или ако откритието ги пронајде потребните параметри во куките - ова се прави со помош на овозможена помошна скрипта.
- Глобални куки. Овие се куки „сами“, тие не се вклучени во модулите и имаат пристап до продавница за глобални вредности, чии вредности се достапни за сите куки во модулите.
Како овие делови работат заедно? Да ја погледнеме сликата од документацијата:
Постојат две работни сценарија:
- Глобалната кука се активира од настан - на пример, кога се менува ресурс во кластерот. Оваа кука ги обработува промените и ги запишува новите вредности во продавницата за глобални вредности. Додаток-оператор забележува дека глобалното складирање е променето и ги стартува сите модули. Секој модул, користејќи ги своите куки, одредува дали треба да се овозможи и ја ажурира продавницата за вредности. Ако модулот е овозможен, Addon-операторот ја започнува инсталацијата на дијаграмот Helm. Во овој случај, табелата на Helm има пристап до вредностите од складиштето на модулот и од глобалното складирање.
- Второто сценарио е поедноставно: куката на модулот се активира од настан и ги менува вредностите во продавницата за вредности на модулот. Додаток-оператор го забележува ова и го лансира дијаграмот Helm со ажурирани вредности.
Додавањето може да се имплементира како една единечна кука, или како една табела на чело, или дури и како неколку зависни модули - ова зависи од сложеноста на компонентата што се инсталира во кластерот и од посакуваното ниво на флексибилност на конфигурацијата. На пример, во складиштето () постои додаток sysctl-тјунер, кој се имплементира и како едноставен модул со кука и дијаграм на Хем, и со користење на продавницата за вредности, што овозможува додавање поставки со уредување на ConfigMap.
Испорака на ажурирања
Неколку зборови за организирање на ажурирањата на компонентите што ги инсталира Addon-операторот.
За да го извршите Addon-операторот во кластер, ви треба изгради слика со додатоци во форма на датотеки со дијаграми со кука и кормичка, додадете бинарна датотека addon-operator и се што ви треба за куки: bash, kubectl, jq, python итн. Потоа оваа слика може да се префрли во кластерот како редовна апликација и најверојатно ќе сакате да организирате една или друга шема за означување. Ако има малку кластери, може да биде соодветен истиот пристап како кај апликациите: ново издание, нова верзија, одете во сите кластери и поправете ја сликата на Pods. Меѓутоа, во случај на префрлање на значителен број кластери, концептот на само-ажурирање од канал беше посоодветен за нас.
Еве како го правиме тоа:
- Каналот во суштина е идентификатор што може да се постави на било што (на пример, dev/stage/ea/stable).
- Името на каналот е ознака на сликата. Кога треба да објавите ажурирања на канал, се составува нова слика и се означува со името на каналот.
- Кога ќе се појави нова слика во регистарот, Addon-operator се рестартира и се стартува со новата слика.
Ова не е најдобра практика, како што е напишано во . Тоа не е препорачливо да го направите ова, но ние зборуваме за редовна апликација која живее во истиот кластер. Во случајот со Addon-оператор, апликацијата е многу распоредувања расфрлани низ кластери, а само-ажурирањето многу помага и го олеснува животот.
Каналите помагаат и во тестирањето: ако има помошен кластер, можете да го конфигурирате на каналот stage и префрлете ги ажурирањата во него пред да ги пренесете на каналите ea и stable. Ако со кластер на каналот ea се појави грешка, можете да ја префрлите на stable, додека се истражува проблемот со овој кластер. Ако кластерот се извади од активна поддршка, тој се префрла на неговиот „замрзнат“ канал - на пример, freeze-2019-03-20.
Во прилог на ажурирање на куките и графиконите на кормилото, можеби ќе ви треба ажурирање и компонента од трета страна. На пример, забележавте грешка во условниот извозник на јазли и дури сфативте како да го закрпите. Следно, го отворивте ПР и чекате новото издание да помине низ сите кластери и да ја зголеми верзијата на сликата. За да не чекате бесконечно, можете да го изградите вашиот јазол-извозник и да се префрлите на него пред да го прифатите ПР.
Општо земено, ова може да се направи без Addon-operator, но со Addon-operator модулот за инсталирање node-exporter ќе биде видлив во едно складиште, Dockerfile за градење на вашата слика може да се чува токму таму, станува полесно за сите учесници во процесот да се разбере што се случува... И ако има неколку кластери, тогаш станува полесно и да го тестирате вашиот ПР и да објавите нова верзија!
Оваа организација на ажурирање на компонентите работи успешно за нас, но секоја друга соодветна шема може да се имплементира - на крајот на краиштата во овој случај Addon-оператор е едноставна бинарна датотека.
Заклучок
Принципите имплементирани во Addon-оператор ви овозможуваат да изградите транспарентен процес за креирање, тестирање, инсталирање и ажурирање на додатоци во кластер, сличен на развојните процеси на редовните апликации.
Додатоците за Додаток-оператор во формат на модул (Табела на чело + куки) може да бидат јавно достапни. Ние, компанијата Флант, планираме да ги објавиме нашите случувања во форма на вакви дополнувања во текот на летото. Придружете се на развојот на GitHub (, ), обидете се да направите свој додаток врз основа на и , почекајте новости на Habré и на нашите !
PS
Прочитајте и на нашиот блог:
- «";
- «".
Извор: www.habr.com