Прим. перев.: Автор оригінального матеріалу - 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, а також враховує правила доступу до кластера».
Це досить точний опис . На жаль, йому бракує деяких можливостей:
- Обслуговує лише один кластер.
- Немає режиму перегляду у вигляді списку (тобто не можна вивести всі pod'и зі статусом «Pending»).
Панель інструментів Kubernetes
«Kubernetes Dashboard – це універсальний веб-інтерфейс для кластерів Kubernetes. Він дозволяє користувачам керувати програмами, що працюють у кластері, та усувати їх неполадки, а також керувати самим кластером».
На жаль, не особливо допомагає у моїх заходах щодо підтримки та реагування на інциденти, тому що в ньому:
- немає постійних посилань, наприклад, коли я фільтрую ресурси або змінюю порядок сортування;
- немає простого способу фільтрувати за статусом – наприклад, побачити всі pod'и зі статусом «Pending»;
- підтримується лише один кластер;
- не підтримуються CRD (ця функція у процесі розробки);
- немає власних стовпців (наприклад, стовпців з мітками за типом
kubectl -L).
Kubernetes Operational View (kube-ops-view)
"Системна панель-спостерігач за простором кластерів K8s".
У зовсім інший підхід: цей інструмент лише показує вузли кластера та pod'и за допомогою WebGL, без будь-яких текстових подробиць об'єктів. Він відмінно підходить для оперативного огляду стану кластера («pod'и падають?»)*, але не підходить для описаних вище випадків використання у підтримці та реагуванні на інциденти.
* Прим. перев.: У цьому сенсі вас також може зацікавити наш плагін , про який ми розповідали докладніше в .
Kubernetes Resource Report (kube-resource-report)
«Збирайте відомості про запити на ресурси pod'ів та кластера Kubernetes, порівнюйте їх із споживанням ресурсів та генеруйте статичний HTML».
генерує статичні HTML-звіти про використання ресурсів та розподіл витрат за командами/додатками у кластерах. Звіт певною мірою корисний для підтримки та реагування на інциденти, оскільки дозволяє швидше знайти кластер, у якому розгорнуто додаток.
Прим. перев.: У перегляді відомостей про розподіл ресурсів та їх вартість у хмарних провайдерів може також виявитися корисним сервіс та інструмент , огляд якого ми .
Октант
«Розширювана веб-платформа для розробників, покликана забезпечити краще розуміння складності кластерів 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 задач (non-goals) залишилися:
- абстрагування об'єктів Kubernetes;
- керування додатками (наприклад, керування deployment'ами, Helm-чартами тощо);
- операції запису (мають здійснюватися через безпечний інструментарій CI/CD та/або GitOps);
- гарний інтерфейс (JavaScript, теми тощо);
- візуалізації (див. );
- аналіз витрат (див. ).
Як Kubernetes Web View допомагає підтримувати та реагувати на інциденти?
Підтримка
- Усі посилання - постійніщо полегшує обмін інформацією з колегами.
- Можна створювати свої уявлення, наприклад, вивести всі Deployment'и і Pod'и з певною міткою у двох конкретних кластерах (кілька імен кластерів та типів ресурсів можна задавати в засланні, розділяючи їх комами).
- Можна посилатися на певні рядки в YAML-файлі об'єкта, вказуючи на потенційні проблеми специфікації об'єкта.
Пошук за кластерами у Kubernetes Web View
Реагування на інциденти
- Глобальний пошук (global search) дозволяє шукати об'єкти у всіх кластерах.
- Подання у вигляді списків можуть відображати всі об'єкти з певним станом/стовпцем у всіх кластерах (наприклад, нам потрібно знайти всі pod'и зі статусом «Pending»).
- Списки об'єктів можна завантажувати у форматі значень, поділених табуляцією (TSV), для подальшого аналізу.
- дозволяють перемикатися на відповідні панелі моніторингу та інші інструменти.
Kubernetes Web View: список pod'ів зі статусом «Pending» у всіх кластерах
Якщо хочете скуштувати Kubernetes Web View, рекомендую ознайомитися з або подивитися на .
Звичайно, інтерфейс міг би бути і кращим, а поки що Kubernetes Web View є інструментом для «просунутих користувачів», які не цураються маніпулювання з URL-шляхами вручну, якщо це необхідно. Якщо у вас є зауваження/доповнення/побажання, будь ласка, зв'яжіться !
Ця стаття є короткою розповіддю про передумови, що призвели до створення Kubernetes Web View. За нею підуть інші! (Прим. перев.: Їх слід очікувати в .)
PSвід перекладача
Читайте також у нашому блозі:
- «»;
- «»;
- «»;
- «».
Джерело: habr.com