Лесно и удобно ли е да подготвите Kubernetes клъстер? Обявяване на addon-оператор

След shell-оператор представяме по-големия му брат - addon-оператор. Това е проект с отворен код, който се използва за инсталиране на системни компоненти в клъстер на Kubernetes, които могат да се нарекат добавки.

Защо въобще някакви добавки?

Не е тайна, че Kubernetes не е готов продукт „всичко в едно“ и за изграждането на „възрастен“ клъстер ще ви трябват различни допълнения. Addon-operator ще ви помогне да инсталирате, конфигурирате и поддържате тези добавки актуални.

Необходимостта от допълнителни компоненти в клъстера е разкрита в доклад Колеги дриуша. Накратко, ситуацията с Kubernetes в момента е такава, че за проста инсталация „play around“ можете да се справите с компонентите от кутията, за разработчици и тестване можете да добавите Ingress, но за пълна инсталация, за която можете да кажете „вашата продукция е готова“, трябва да добавите с дузина различни добавки: нещо за наблюдение, нещо за регистриране, не забравяйте ingress и cert-manager, изберете групи от възли, добавете мрежови политики, сезон с настройките на sysctl и pod autoscaler...

Какви са спецификите на работата с тях?

Както показва практиката, въпросът не се ограничава до една инсталация. За да работят удобно с клъстера, добавките ще трябва да бъдат актуализирани, деактивирани (премахнати от клъстера) и ще искате да тествате някои, преди да ги инсталирате в производствения клъстер.

Така че, може би Ansible ще бъде достатъчно тук? Може би. Но Като цяло, пълноценните добавки не живеят без настройки. Тези настройки може да се различават в зависимост от варианта на клъстера (aws, gce, azure, bare-metal, do, ...). Някои настройки не могат да бъдат зададени предварително; те трябва да бъдат получени от клъстера. И клъстерът не е статичен: за някои настройки ще трябва да наблюдавате промените. И тук Ansible вече липсва: имате нужда от програма, която живее в клъстер, т.е. Оператор Kubernetes.

Тези, които го опитаха на работа shell-оператор, те ще кажат, че задачите за инсталиране и актуализиране на добавки и настройки за наблюдение могат да бъдат напълно решени с помощта на кукички за shell-оператор. Можете да напишете скрипт, който ще направи условно условие kubectl apply и наблюдавайте например ConfigMap, където ще се съхраняват настройките. Това е приблизително това, което е внедрено в addon-operator.

Как е организирано това в addon-operator?

При създаването на ново решение изхождаме от следните принципи:

• Инсталаторът на добавката трябва да поддържа шаблони и декларативна конфигурация. Ние не правим магически скриптове, които инсталират добавки. Операторът на добавките използва Helm за инсталиране на добавки. За да инсталирате, трябва да създадете диаграма и да изберете стойностите, които ще се използват за конфигурация.
• Настройките могат да бъдат генерира при инсталация, те могат да бъдат вземете от клъстерИли получавате актуализации, мониторинг на ресурсите на клъстера. Тези операции могат да бъдат изпълнени с помощта на куки.
• Настройките могат да бъдат съхранявайте в клъстер. За да се съхраняват настройките в клъстера, се създава ConfigMap/addon-оператор и Addon-операторът следи промените в тази ConfigMap. Addon-operator дава на куките достъп до настройките, използвайки прости конвенции.
• Добавянето зависи от настройките. Ако настройките са променени, тогава операторът на Addon разгръща Helm диаграмата с нови стойности. Нарекохме комбинацията от диаграмата на Helm, стойностите за нея и куките модул (вижте по-долу за повече подробности).
• Постановка. Няма магически скриптове за освобождаване. Механизмът за актуализиране е подобен на обикновено приложение - събирайте добавки и оператори на добавки в изображение, маркирайте ги и ги разгръщайте.
• Контрол на резултата. Addon-operator може да предостави показатели за Prometheus.

Какво е подпълване в addon-operator?

Като допълнение може да се счита всичко, което добавя нови функции към клъстера. Например, инсталирането на Ingress е чудесен пример за добавка. Това може да бъде всеки оператор или контролер със собствен CRD: prometheus-operator, cert-manager, kube-controller-manager и др. Или нещо малко, но по-лесно за използване - например Secret Copier, който копира тайните на регистъра в нови пространства от имена, или sysctl tuner, който конфигурира sysctl параметри на нови възли.

За внедряване на добавки, Addon-operator предоставя няколко концепции:

• Диаграма на кормилото използва се за инсталиране на различен софтуер в клъстера - например Prometheus, Grafana, nginx-ingress. Ако необходимият компонент има Helm диаграма, тогава инсталирането му с помощта на Addon-operator ще бъде много лесно.
• Съхранение на ценности. Helm диаграмите обикновено имат много различни настройки, които могат да се променят с времето. Операторът на добавките поддържа съхраняването на тези настройки и може да наблюдава промените им, за да преинсталира диаграмата на Helm с нови стойности.
• Кукички са изпълними файлове, които Addon-операторът изпълнява при събития и които имат достъп до хранилището на стойности. Куката може да наблюдава промените в клъстера и да актуализира стойностите в хранилището на стойности. Тези. Използвайки кукички, можете да правите откриване, за да събирате стойности от клъстера при стартиране или по график, или можете да правите непрекъснато откриване, събирайки стойности от клъстера въз основа на промени в клъстера.
• Модул е комбинация от Helm диаграма, хранилище на стойности и куки. Модулите могат да бъдат активирани или деактивирани. Деактивирането на модул означава изтриване на всички версии на диаграмата на Helm. Модулите могат да се активират динамично, например, ако всички модули, от които се нуждае, са активирани или ако откриването е намерило необходимите параметри в куките - това се прави с помощта на спомагателен активиран скрипт.
• Глобални куки. Това са куки „сами по себе си“, те не са включени в модули и имат достъп до глобално хранилище на стойности, чиито стойности са достъпни за всички куки в модулите.

Как тези части работят заедно? Нека да разгледаме снимката от документацията:

Има два сценария на работа:

1. Глобалната кука се задейства от събитие - например, когато се промени ресурс в клъстера. Тази кука обработва промените и записва новите стойности в глобалното хранилище на стойности. Операторът на добавките забелязва, че глобалното хранилище се е променило и стартира всички модули. Всеки модул, използвайки своите кукички, определя дали трябва да бъде активиран и актуализира своето хранилище за стойности. Ако модулът е активиран, операторът Addon започва инсталирането на диаграмата Helm. В този случай диаграмата Helm има достъп до стойности от хранилището на модула и от глобалното хранилище.
2. Вторият сценарий е по-прост: модулна кука се задейства от събитие и променя стойностите в хранилището на стойностите на модула. Операторът на добавките забелязва това и стартира диаграмата Helm с актуализирани стойности.

Добавянето може да се реализира като една единствена кука, или като една Helm карта, или дори като няколко зависими модула - това зависи от сложността на компонента, който се инсталира в клъстера и от желаното ниво на гъвкавост на конфигурацията. Например в хранилището (/примери) има добавка sysctl-tuner, която се изпълнява както като прост модул с кука и Helm диаграма, така и с помощта на хранилището на стойности, което прави възможно добавянето на настройки чрез редактиране на ConfigMap.

Доставка на актуализации

Няколко думи за организирането на актуализации на компоненти, които инсталира Addon-operator.

За да стартирате Addon-operator в клъстер, трябва изградете изображение с допълнения под формата на файлове с диаграми на кука и Helm, добавете двоичен файл addon-operator и всичко необходимо за куките: bash, kubectl, jq, python и т.н. След това това изображение може да бъде пуснато в клъстера като обикновено приложение и най-вероятно ще искате да организирате една или друга схема за маркиране. Ако има малко клъстери, може да е подходящ същият подход като при приложенията: нова версия, нова версия, отидете на всички клъстери и коригирайте изображението на Pods. Въпреки това, в случай на внедряване към значителен брой клъстери, концепцията за самообновяване от канал беше по-подходяща за нас.

Ето как го правим:

• Каналът по същество е идентификатор, който може да бъде зададен на всичко (например dev/stage/ea/stable).
• Името на канала е етикетът на изображението. Когато трябва да пуснете актуализации на канал, се сглобява ново изображение и се маркира с името на канала.
• Когато в системния регистър се появи ново изображение, Addon-operator се рестартира и стартира с новото изображение.

Това не е най-добрата практика, както е написано в Документация на Kubernetes. Не е препоръчително да правите това, но ние говорим за обикновено приложение, което живее в същия клъстер. В случая на Addon-operator едно приложение е много внедрявания, разпръснати в клъстери, а самообновяването помага много и улеснява живота.

Канали помагат и при тестване: ако има спомагателен клъстер, можете да го конфигурирате към канала stage и прехвърляйте актуализации в него, преди да го разпространите в каналите ea и stable. Ако с клъстер на канала ea възникна грешка, можете да го превключите на stable, докато проблемът с този клъстер се проучва. Ако клъстерът бъде изваден от активна поддръжка, той превключва към своя "замразен" канал - напр. freeze-2019-03-20.

В допълнение към актуализирането на куките и Helm диаграмите, може да се нуждаете актуализация и компонент на трета страна. Например, забелязали сте грешка в условния възел-експортер и дори сте измислили как да я закърпите. След това отворихте PR и чакате новата версия да премине през всички клъстери и да увеличи версията на изображението. За да не чакате безкрайно, можете да изградите своя възел-износител и да преминете към него, преди да приемете PR.

По принцип това може да се направи без Addon-operator, но с Addon-operator модулът за инсталиране на node-exporter ще бъде видим в едно хранилище, Dockerfile за изграждане на вашето изображение може да се съхранява точно там, става по-лесно за всички участници в процеса, за да разберете какво се случва... И ако има няколко клъстера, тогава става по-лесно както да тествате своя PR, така и да пуснете нова версия!

Тази организация на обновяване на компоненти работи успешно за нас, но може да се приложи всяка друга подходяща схема - все пак в този случай Addon-operator е прост двоичен файл.

Заключение

Принципите, внедрени в Addon-operator, ви позволяват да изградите прозрачен процес за създаване, тестване, инсталиране и актуализиране на добавки в клъстер, подобно на процесите на разработка на обикновени приложения.

Добавките за Addon-operator във формат на модул (Helm chart + куки) могат да бъдат публично достъпни. Ние, компанията Flant, планираме да публикуваме нашите разработки под формата на такива допълнения през лятото. Присъединете се към разработката в GitHub (shell-оператор, addon-оператор), опитайте се да направите свое собствено допълнение въз основа на примери и документация, очаквайте новини на Habré и ​​на нашия YouTube канал!

PS

Прочетете също в нашия блог:

• «Разширяване и допълване на Kubernetes (преглед и видео отчет)»;
• «Представяме ви shell-operator: създаването на оператори за Kubernetes току-що стана по-лесно".

Източник: www.habr.com