🥇Анонс на уеб интерфейса Kubernetes Web View (и кратък преглед на други web UI за Kubernetes)

Прим. прев.: Автор на оригиналния материал е Henning Jacobs от компания Zalando. Той е създал нов уеб-интерфейс за работа с Kubernetes, който е позициониран като "kubectl за уеба". Защо новият Open Source проект се е появил и кои критерии не удовлетворяваха вече съществуващите решения - четете в неговата статия.

В тази публикация разглеждам различни уеб-интерфейси за Kubernetes с отворен код, представям изискванията си към универсален UI и обяснявам защо създадох Kubernetes Web View — интерфейс, който цели да улесни поддръжката и отстраняването на проблеми едновременно в множество клъстери.

Сценарии за употреба

В 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 не е особено голям*, затова пробвах да събера допълнителна информация с помощта на Twitter:

* Обяснението ми за ограниченото число уеб интерфейси за Kubernetes е, че облачните услуги и доставчиците на Kubernetes обикновено предлагат собствени фронтенд решения, затова пазарът за „добри“ свободни Kubernetes UI е сравнително малък.

С помощта на туит научих за K8Dash, Kubernator и Octant. Нека да ги разгледаме и да видим други съществуващи Open Source решения, опитвайки се да разберем какво представляват.

K8Dash

„K8Dash е най-простият начин за управление на клъстер Kubernetes.“

K8Dash изглежда добре и работи бързо, но има редица недостатъци за посочените по-горе сценарии на употреба:

Работи само в рамките на един клъстер.
Сортиране и филтриране е възможно, но няма постоянни линкове.
Липсва поддръжка на Custom Resource Definitions (CRDs).

Kubernator

„Kubernator е алтернативен UI за Kubernetes. За разлика от високото ниво на Kubernetes Dashboard, той осигурява ниско ниво на контрол и отличен преглед на всички обекти в клъстера с възможност за създаване на нови, редактиране на съществуващите и разрешаване на конфликти. Бийки целия клиентски приложение (като kubectl), той не изисква никакъв бекенд, освен самия API-сървър Kubernetes, и взема предвид правилата за достъп до клъстера.“

Това е доста точно описание на Kubernator’а. За жалост, му липсват някои възможности:

Поддържа само един клъстер.
Няма режим на преглед в режим списък (т.е. не може да се изведат всички под-процеси със статус «Pending»).

Kubernetes Dashboard

«Kubernetes Dashboard — универсален уеб интерфейс за Kubernetes клъстери. Той позволява на потребителите да управляват приложенията, работещи в клъстера, да отстраняват проблеми и да управляват самия клъстер.»

За съжаление, Kubernetes Dashboard не особено помага в моите мероприятия по поддръжка и реагиране на инциденти, защото в него:

няма постоянни линкове, например, когато филтрирам ресурси или променям реда на сортиране;
няма лесен начин за филтриране по статус — например, да видя всички под-процеси със статус «Pending»;
поддържа се само един клъстер;
не се поддържат CRD (тази функция е в процес на разработка);
няма потребителски колони (например, колони с етикети от типа kubectl -L).

Kubernetes Operational View (kube-ops-view)

«Системна панел-наблюдател за пространството на K8s клъстери».

В Kubernetes Operational View совсем различен подход: този инструмент показва само узлите на клъстера и под-процесите с помощта на WebGL, без никакви текстови подробности за обектите. Той е отличен за оперативен преглед на състоянието на клъстера («под-процесите падат?»)*, но не е подходящ за описаните по-горе случаи на използване в поддръжка и реагиране на инциденти.

* Прим. прев.: В този смисъл може да ви заинтересува и нашият плъгин grafana-statusmap, за който по-подробно разказахме в тази статия.

Kubernetes Resource Report (kube-resource-report)

«Събирайте данни за ресурсните заявки на под-процесите и клъстера Kubernetes, сравнявайте ги с консумацията на ресурси и генерирайте статичен HTML».

Kubernetes Resource Report генерира статични HTML отчети за използването на ресурси и разпределението на разходите по екипи/приложения в клъстера. Отчетът е донякъде полезен за поддръжка и реагиране на инциденти, тъй като позволява по-бързо откриване на клъстер, в който е разположено приложението.

Прим. прев.: В прегледа на информацията за разпределението на ресурсите и разходите им при облачните доставчици може да се окажат полезни услугите и инструментите Kubecost, обзорът на които ние недавно публикувахме.

Octant

«Разширяема уеб платформа за разработчици, предназначена да осигури по-добро разбиране на сложността на клъстерите Kubernetes».

Octant, изграден в VMware, — нов продукт, за който научих сравнително наскоро. С негова помощ е удобно да се изследва клъстера на локалната машина (има дори визуализации), но той засяга проблема с поддръжката и реагирането на инциденти само в ограничена степен. Недостатъци на Octant:

Липсва търсене по клъстери.
Работи само на локалната машина (не може да се разгръща в клъстера).
Невъзможно е да се сортират/филтрират обекти (поддържа се само селектор на етикети).
Не може да се задават потребителски колони.
Не може да се извежда списък на обектите по пространства от имена.

Също така имах проблеми с устойчивостта на работата на Octant с клъстери на Zalando: на някои CRD той падна..

Представям Kubernetes Web View

«kubectl за уеба».

След като анализирах наличните интерфейси за Kubernetes, реших да създам нов: Kubernetes Web View. Защото по същество ми е нужна само цялата мощ 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, теми и т.н.);
визуализации (вж. kube-ops-view);
анализ на разходите (вж. kube-resource-report).

Как Kubernetes Web View помага при поддръжката и реакцията на инциденти?

Поддръжка

Всички връзки са постоянни, което улеснява обмена на информация с колеги.
Могат да се създават собствени представяния, например, да се извеждат всички Deployment’и и Pod’и с определен етикет в два конкретни клъстера (няколко имена на клъстери и типове ресурси могат да се задават в връзката, разделяйки ги с запетаи).
Може да се посочва на определени редове в YAML-файла на обекта, указвайки потенциални проблеми в спецификацията на обекта.

Търсене по клъстери в Kubernetes Web View

Реакция на инциденти

Глобално търсене (глобално търсене) позволява търсене на обекти във всички клъстери.
Представяния под формата на списъци могат да показват всички обекти с определено състояние/колона във всички клъстери (например, трябва да намерим всички pod’и със статус „Pending“).
Списъците на обектите могат да се изтеглят в формат на стойности, разделени с табулация (TSV), за последващ анализ.
Персонализируеми външни връзки позволяват превключване на съответните панели за мониторинг и други инструменти.

Kubernetes Web View: списък на pod’ите със статус „Pending“ във всички клъстери

Ако искате да опитате Kubernetes Web View, препоръчвам да се запознаете с документацията или да погледнете на живо демо-версия.

Разбира се, интерфейс можеше да бъде и по-добър, а засега Kubernetes Web View е инструмент за "напреднали потребители", които не се страхуват да манипулират с URL пътища ръчно, ако е необходимо. Ако имате коментари/допълнения/желания, моля, свържете се с мен в Twitter!

Тартата е кратък разказ за предпоставките, които доведоха до създаването на Kubernetes Web View. След него ще последват и други! (Прим. прев.: Следва да се очакват в блога на автора.)