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