Прим. прев.: Автор на оригиналния материал е Henning Jacobs от компания Zalando. Той е създал нов уеб-интерфейс за работа с Kubernetes, който е позициониран като "kubectl за уеба". Защо новият Open Source проект се е появил и кои критерии не удовлетворяваха вече съществуващите решения - четете в неговата статия.
В тази публикация разглеждам различни уеб-интерфейси за Kubernetes с отворен код, представям изискванията си към универсален UI и обяснявам защо създадох — интерфейс, който цели да улесни поддръжката и отстраняването на проблеми едновременно в множество клъстери.
Сценарии за употреба
В Zalando обслужваме голямо количество потребители на Kubernetes (900+) и клъстери (100+). Има няколко типични случая на употреба, в които специализираният уеб инструмент би бил много полезен:
- общуване с колеги в рамките на поддръжка;
- реагиране на инциденти и разследване на причините им.
Поддръжка
От моят опит, общуването в рамките на поддръжка често изглежда по следния начин:
— Помогнете, нашият сервис XYZ е недостъпен!
— Какво виждате, когато изпълнявате kubectl describe ingress ...?
Или нещо подобно за CRD:
— Имам някакъв проблем с идентификационния сервис...
— А какво издава командата kubectl describe platformcredentialsset ...?
Такова общуване обикновено се свежда до въвеждане на различни вариации на командата kubectl с цел установяване на проблема. В резултат на това и двете страни в разговора са принудени постоянно да превключват между терминала и уеб чата, плюс те наблюдават различна ситуация.
Затова искам уеб фронтендът на Kubernetes да позволява следното:
- потребителите да обменят връзки и да наблюдават едно и също;
- да помага да се избягват човешки грешки в поддръжката: например, влизане в грешен клъстер в командния ред, правописни грешки в командите CLI и т.н.;
- да позволява да се генерират собствени представяния за изпращане на колеги, т.е. добавяне на колони с етикети, показване на множество типове ресурси на една страница;
- в идеалния случай този уеб инструмент трябва да позволява поставяне на "дълбоки" връзки към конкретни раздели на YAML (например, посочвайки на неправилен параметър, който предизвиква сривове).
Реагиране на инциденти и анализ
Реагирането на инциденти в инфраструктурата изисква наличието на ситуационна осведоменост, способност за оценка на въздействието и търсене на закономерности в клъстери. Някои примери от реалния живот:
- с критично важен production-сервис възникват проблеми и е необходимо да се намерят всички ресурси Kubernetes по име във всички клъстери, за да се отстранят проблемите;
- възлите започват да падат при мащабиране и е необходимо да се намерят всички pod’ове със статус „Pending“ във всички клъстери, за да се оцени мащабът на проблема;
- отделни потребители съобщават за проблем с DaemonSet, разпределен във всички клъстери, и е необходимо да се установи, дали проблемът е тотален..
Моето стандартно решение в такива случаи е нещо като for i in $clusters; do kubectl ...; done. Очевидно е, че може да се разработи инструмент, предоставящ подобни възможности.
Съществуващите уеб интерфейси Kubernetes
Светът на Open Source уеб интерфейсите за Kubernetes не е особено голям*, затова пробвах да събера допълнителна информация с помощта на :
* Обяснението ми за ограниченото число уеб интерфейси за Kubernetes е, че облачните услуги и доставчиците на Kubernetes обикновено предлагат собствени фронтенд решения, затова пазарът за „добри“ свободни Kubernetes UI е сравнително малък.
С помощта на туит научих за , и . Нека да ги разгледаме и да видим други съществуващи Open Source решения, опитвайки се да разберем какво представляват.
K8Dash
„K8Dash е най-простият начин за управление на клъстер Kubernetes.“
изглежда добре и работи бързо, но има редица недостатъци за посочените по-горе сценарии на употреба:
- Работи само в рамките на един клъстер.
- Сортиране и филтриране е възможно, но няма постоянни линкове.
- Липсва поддръжка на Custom Resource Definitions (CRDs).
Kubernator
„Kubernator е алтернативен UI за Kubernetes. За разлика от високото ниво на Kubernetes Dashboard, той осигурява ниско ниво на контрол и отличен преглед на всички обекти в клъстера с възможност за създаване на нови, редактиране на съществуващите и разрешаване на конфликти. Бийки целия клиентски приложение (като kubectl), той не изисква никакъв бекенд, освен самия API-сървър Kubernetes, и взема предвид правилата за достъп до клъстера.“
Това е доста точно описание на . За жалост, му липсват някои възможности:
- Поддържа само един клъстер.
- Няма режим на преглед в режим списък (т.е. не може да се изведат всички под-процеси със статус «Pending»).
Kubernetes Dashboard
«Kubernetes Dashboard — универсален уеб интерфейс за Kubernetes клъстери. Той позволява на потребителите да управляват приложенията, работещи в клъстера, да отстраняват проблеми и да управляват самия клъстер.»
За съжаление, не особено помага в моите мероприятия по поддръжка и реагиране на инциденти, защото в него:
- няма постоянни линкове, например, когато филтрирам ресурси или променям реда на сортиране;
- няма лесен начин за филтриране по статус — например, да видя всички под-процеси със статус «Pending»;
- поддържа се само един клъстер;
- не се поддържат CRD (тази функция е в процес на разработка);
- няма потребителски колони (например, колони с етикети от типа
kubectl -L).
Kubernetes Operational View (kube-ops-view)
«Системна панел-наблюдател за пространството на K8s клъстери».
В совсем различен подход: този инструмент показва само узлите на клъстера и под-процесите с помощта на WebGL, без никакви текстови подробности за обектите. Той е отличен за оперативен преглед на състоянието на клъстера («под-процесите падат?»)*, но не е подходящ за описаните по-горе случаи на използване в поддръжка и реагиране на инциденти.
* Прим. прев.: В този смисъл може да ви заинтересува и нашият плъгин , за който по-подробно разказахме в .
Kubernetes Resource Report (kube-resource-report)
«Събирайте данни за ресурсните заявки на под-процесите и клъстера Kubernetes, сравнявайте ги с консумацията на ресурси и генерирайте статичен HTML».
генерира статични HTML отчети за използването на ресурси и разпределението на разходите по екипи/приложения в клъстера. Отчетът е донякъде полезен за поддръжка и реагиране на инциденти, тъй като позволява по-бързо откриване на клъстер, в който е разположено приложението.
Прим. прев.: В прегледа на информацията за разпределението на ресурсите и разходите им при облачните доставчици може да се окажат полезни услугите и инструментите , обзорът на които ние .
Octant
«Разширяема уеб платформа за разработчици, предназначена да осигури по-добро разбиране на сложността на клъстерите Kubernetes».
, изграден в VMware, — нов продукт, за който научих сравнително наскоро. С негова помощ е удобно да се изследва клъстера на локалната машина (има дори визуализации), но той засяга проблема с поддръжката и реагирането на инциденти само в ограничена степен. Недостатъци на Octant:
- Липсва търсене по клъстери.
- Работи само на локалната машина (не може да се разгръща в клъстера).
- Невъзможно е да се сортират/филтрират обекти (поддържа се само селектор на етикети).
- Не може да се задават потребителски колони.
- Не може да се извежда списък на обектите по пространства от имена.
Също така имах проблеми с устойчивостта на работата на Octant с клъстери на Zalando: на някои CRD .
Представям Kubernetes Web View
«kubectl за уеба».
След като анализирах наличните интерфейси за Kubernetes, реших да създам нов: . Защото по същество ми е нужна само цялата мощ kubectl в уеба, а именно:
- достъпност на всичките (read-only) операции, в които потребителите предпочитат да използват kubectl;
- всички URL адреси трябва да са постоянни и да представят страницата в оригинален вид, за да могат колегите да ги споделят и да ги използват в други инструменти;
- поддръжка на всички обекти от Kubernetes, което ще позволи решаването на проблема от всякакъв тип;
- списъците на ресурсите трябва да могат да се изтеглят за последваща работа (в електронни таблици, CLI инструменти като
grep) и съхранение (например, за postmortem’и); - поддръжка на отбор на ресурсите по етикети (по аналогия с
kubectl get .. -l); - възможност за създаване на комбинирани списъци от различни типове ресурси (по аналогия с
kubectl get all) за получаване на обща операционна картина сред колегите (например, по време на реакция на инцидент); - възможност за добавяне на конфигурируеми «умни» дълбоки връзки към други инструменти, като панели за мониторинг, логери, регистри на приложения и т.н. за облекчаване на търсенето/отстраняването на грешки и реагирането на инциденти;
- фронтендът трябва да бъде максимално прост (чист HTML), за да се избегнат случайни проблеми, например, заключен JavaScript;
- поддръжка на множество клъстери за улесняване на взаимодействието при дистанционно консултиране (например, за да запомняте само един URL);
- при възможност трябва да се опростява ситуационният анализ (например, със връзки за сваляне на ресурси по всички клъстери/пространства от имена);
- допълнителни възможности за създаване на гъвкави връзки и извличане на текстова информация, например, за да може да се посочат на колеги определени раздели в описанието на ресурса (ред в YAML);
- възможност за адаптиране към изискванията на конкретен клиент, например, позволяваща създаването на специални шаблони за показване за CRD, собствени таблици на представяния, промяна на CSS-стилове;
- средства за допълнително проучване в командния ред (например, показвайки пълни команди
kubectl, готови за копиране);
Извън задачите, решавани в Kubernetes Web View (не-цели) останаха:
- абстракция на Kubernetes обекти;
- управление на приложения (например, управление на deployment’и, Helm-чартове и т.н.);
- операции за запис (трябва да се извършват чрез безопасен инструментарий CI/CD и/или GitOps);
- красив интерфейс (JavaScript, теми и т.н.);
- визуализации (вж. );
- анализ на разходите (вж. ).
Как Kubernetes Web View помага при поддръжката и реакцията на инциденти?
Поддръжка
- Всички връзки са постоянни, което улеснява обмена на информация с колеги.
- Могат да се създават собствени представяния, например, да се извеждат всички Deployment’и и Pod’и с определен етикет в два конкретни клъстера (няколко имена на клъстери и типове ресурси могат да се задават в връзката, разделяйки ги с запетаи).
- Може да се посочва на определени редове в YAML-файла на обекта, указвайки потенциални проблеми в спецификацията на обекта.
Търсене по клъстери в Kubernetes Web View
Реакция на инциденти
- Глобално търсене (глобално търсене) позволява търсене на обекти във всички клъстери.
- Представяния под формата на списъци могат да показват всички обекти с определено състояние/колона във всички клъстери (например, трябва да намерим всички pod’и със статус „Pending“).
- Списъците на обектите могат да се изтеглят в формат на стойности, разделени с табулация (TSV), за последващ анализ.
- позволяват превключване на съответните панели за мониторинг и други инструменти.
Kubernetes Web View: списък на pod’ите със статус „Pending“ във всички клъстери
Ако искате да опитате Kubernetes Web View, препоръчвам да се запознаете с или да погледнете .
Разбира се, интерфейс можеше да бъде и по-добър, а засега Kubernetes Web View е инструмент за "напреднали потребители", които не се страхуват да манипулират с URL пътища ръчно, ако е необходимо. Ако имате коментари/допълнения/желания, моля, свържете се !
Тартата е кратък разказ за предпоставките, които доведоха до създаването на Kubernetes Web View. След него ще последват и други! (Прим. прев.: Следва да се очакват в .)
P.S. от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «».
Източник: habr.com
