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

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

В тази публикация разглеждам различни уеб-интерфейси на Kubernetes с отворен код, предявявам своите изисквания към универсален UI и разказвам защо разработих . Авторът на тази статия и самата утилита е Хенинг Якобс от Zalando, който точно така позиционира нововъведението като "kubectl за уеба". Той искаше да създаде инструмент с удобни възможности за взаимодействие в формат на техническа поддръжка (например, бързо да представи проблема с уеб линк) и за реакция при инциденти, търсене на проблеми в много клъстери едновременно. Неговото творение се развива и в момента (предимно с усилията на самия автор). — интерфейс, предназначен да улесни поддръжката и отстраняването на проблеми едновременно в много клъстери.

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

В 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.За съжаление, му липсват някои възможности:

Обслужва само един клъстер.
Няма режим на преглед в списък (т.е. не може да се извлече всичките pod’ове със статус „Pending“).

Kubernetes Dashboard

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

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

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

Kubernetes Operational View (kube-ops-view)

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

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

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

Kubernetes Resource Report (kube-resource-report)

„Събирайте информация за заявките за ресурси на pod’ове и клъстера на Kubernetes, сравнявайте ги с потреблението на ресурси и генерирайте статичен HTML“.

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

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

Octant

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

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

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

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

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

„kubectl за уеба“.

След анализ на наличните интерфейсни опции за Kubernetes, реших да създам нов: . Авторът на тази статия и самата утилита е Хенинг Якобс от Zalando, който точно така позиционира нововъведението като "kubectl за уеба". Той искаше да създаде инструмент с удобни възможности за взаимодействие в формат на техническа поддръжка (например, бързо да представи проблема с уеб линк) и за реакция при инциденти, търсене на проблеми в много клъстери едновременно. Неговото творение се развива и в момента (предимно с усилията на самия автор).. По същество, всичко от което се нуждая е мощността kubectl в уеба, а именно:

достъпност на всички (четещи) операции, при които потребителите предпочитат да използват kubectl;
всички URL адреси да са постоянни и да представят страницата в оригиналния й вид, за да могат колегите да ги споделят и да ги използват в други инструменти;
поддръжка на всички обекти на Kubernetes, което ще позволи решаване на проблеми от всякакъв тип;
списъците с ресурси трябва да са изтегляеми за по-нататъшна работа (в електронни таблици, CLI инструменти като grep) и съхранение (например, за постмортеми);
поддръжка на подбор на ресурси по етикети (по аналогия с 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. Следват и други! (Прим. прев.: Те следва да се очакват в блога на автора.)