Przyp. tłum.: Autorem oryginalnego materiału jest Henning Jacobs z firmy Zalando. Stworzył on nowy interfejs webowy do pracy z Kubernetes, który jest reklamowany jako „kubectl dla webu”. Dlaczego pojawił się nowy projekt Open Source i jakimi kryteriami nie spełniły istniejące rozwiązania — przeczytaj w jego artykule.
W tej publikacji omawiam różne interfejsy webowe Kubernetes z otwartym kodem źródłowym, przedstawiam swoje wymagania dotyczące uniwersalnego UI i opowiadam, dlaczego go opracowałem — interfejs, który ma na celu ułatwienie wsparcia i rozwiązywania problemów w wielu klastrach jednocześnie.
Scenariusze użycia
W Zalando obsługujemy dużą liczbę użytkowników Kubernetes (ponad 900) oraz klastrów (ponad 100). Istnieje kilka typowych przypadków użycia, w których bardzo przydałby się specjalistyczny narzędzie webowe:
- komunikacja z kolegami w ramach wsparcia;
- reakcja na incydenty i badanie ich przyczyn.
Wsparcie
Z mojego doświadczenia, komunikacja w ramach wsparcia często wygląda następująco:
— Pomóżcie, nasz serwis XYZ jest niedostępny!
— Co widzisz, wykonując kubectl describe ingress ...?
Lub coś podobnego dla CRD:
— Mam jakiś problem z serwisem identyfikacji…
— A co wyświetla polecenie kubectl describe platformcredentialsset ...?
Tego typu komunikacja zazwyczaj sprowadza się do wprowadzania różnych wariacji polecenia kubectl w celu ustalenia problemu. W efekcie obie strony rozmowy muszą nieustannie przełączać się między terminalem a czatem webowym, a także obserwują różne sytuacje.
Dlatego chciałbym, aby front-end webowy do Kubernetes umożliwiał następujące:
- użytkownicy mogliby wymieniać się linkami i obserwować to samo;
- pomagałby unikać błędów ludzkich w wsparciu: na przykład nie wchodząc do niewłaściwego klastra w wierszu poleceń, błędów w poleceniach CLI itp.;
- umożliwiałby tworzenie własnych widoków do wysyłania kolegom, tj. dodawanie kolumn etykiet, wyświetlanie wielu typów zasobów na jednej stronie;
- w idealnym przypadku to narzędzie webowe powinno umożliwiać umieszczanie „głębokich” linków do konkretnych sekcji YAML (na przykład wskazując na niewłaściwy parametr, który powoduje awarie).
Reagowanie na incydenty i analizy
Reagowanie na incydenty w infrastrukturze wymaga sytuacyjnej świadomości, umiejętności oceny wpływu i poszukiwania wzorców w klastrach. Oto kilka przykładów z życia wziętych:
- w przypadku krytycznej awarii usługi produkcyjnej pojawiają się problemy i musisz znaleźć wszystkie zasoby Kubernetes według nazwy we wszystkich klastrach, aby usunąć usterkę;
- węzły zaczynają się wyłączać podczas skalowania, a ty musisz znaleźć wszystkie pod’y o statusie „Pending” we wszystkich klastrach, aby ocenić rozmiar problemu;
- poszczególni użytkownicy zgłaszają problemy z DaemonSet rozlokowanym we wszystkich klastrach i należy ustalić, czy problem ma charakter powszechny.
Moim standardowym rozwiązaniem w takich przypadkach jest coś w stylu for i in $clusters; do kubectl ...; done. Oczywiście można opracować narzędzie, które zapewnia podobne możliwości.
Istniejące interfejsy webowe Kubernetes
Świat Open Source-owych interfejsów webowych do Kubernetes nie jest zbyt obszerny*, więc spróbowałem zebrać dodatkowe informacje za pomocą :
* Moje wyjaśnienie ograniczonej liczby interfejsów webowych dla Kubernetes: usługi chmurowe i dostawcy Kubernetes zazwyczaj oferują własne frontendy, w związku z czym rynek „dobrych” darmowych UI Kubernetes jest stosunkowo mały.
Dzięki tweetowi dowiedziałem się o , i . Przyjrzyjmy się im oraz innym istniejącym rozwiązaniom Open Source i spróbujmy zrozumieć, co one sobą reprezentują.
K8Dash
„K8Dash to najprostszy sposób na zarządzanie klastrem Kubernetes.”
nieźle wygląda i działa szybko, ale ma kilka niedociągnięć dla wymienionych powyżej scenariuszy użycia:
- Działa tylko w ramach jednego klastra.
- Sortowanie i filtrowanie są możliwe, ale nie mają stałych linków.
- Brak wsparcia dla Custom Resource Definitions (CRDs).
Kubernator
„Kubernator to alternatywny UI dla Kubernetes. W przeciwieństwie do wysokopoziomowego panelu Kubernetes Dashboard, zapewnia niskopoziomową kontrolę i doskonały przegląd wszystkich obiektów w klastrze z możliwością tworzenia nowych, edytowania ich i rozwiązywania konfliktów. Będąc całkowicie aplikacją kliencką (jak kubectl), nie wymaga żadnego backendu, z wyjątkiem samego API serwera Kubernetes, a także uwzględnia zasady dostępu do klastra.”
To dość dokładny opis . Niestety, brakuje mu kilku możliwości:
- Obsługuje tylko jeden klaster.
- Brak trybu przeglądania w formie listy (tzn. nie można wyświetlić wszystkich podów o statusie „Oczekujący”).
Kubernetes Dashboard
„Kubernetes Dashboard to uniwersalny interfejs webowy dla klastrów Kubernetes. Umożliwia użytkownikom zarządzanie aplikacjami działającymi w klastrze oraz rozwiązywanie problemów, a także zarządzanie samym klastrem.”
Niestety, nie pomaga szczególnie w moich zadaniach związanych z wsparciem i reagowaniem na incydenty, ponieważ:
- brak stałych linków, na przykład podczas filtrowania zasobów lub zmiany kolejności sortowania;
- nie ma prostego sposobu na filtrowanie według statusu — na przykład, aby zobaczyć wszystkie pody o statusie „Oczekujący”;
- obsługiwany jest tylko jeden klaster;
- nie są obsługiwane CRD (ta funkcja jest w trakcie opracowywania);
- brak kolumn użytkownika (na przykład kolumn z etykietami typu
kubectl -L).
Kubernetes Operational View (kube-ops-view)
„Panel systemowy do monitorowania przestrzeni klastrów K8s.”
U ma zupełnie inne podejście: to narzędzie pokazuje tylko węzły klastra i pody za pomocą WebGL, bez jakichkolwiek tekstowych szczegółów obiektów. Doskonale nadaje się do szybkiego przeglądu stanu klastra („pody padają?”)*, ale nie nadaje się do opisanych wcześniej przypadków użycia w wsparciu i reagowaniu na incydenty.
* Przyp. tłum.: W tym sensie może Cię również zainteresować nasza wtyczka , o której pisaliśmy szczegółowo w .
Kubernetes Resource Report (kube-resource-report)
„Zbieraj informacje o wymaganiach dotyczących zasobów podów i klastra Kubernetes, porównuj je z zużyciem zasobów i generuj statyczny HTML.”
generuje statyczne raporty HTML dotyczące wykorzystania zasobów i podziału kosztów według zespołów/aplikacji w klastrach. Raport w pewnym stopniu jest przydatny w wsparciu i reagowaniu na incydenty, ponieważ pozwala szybciej zlokalizować klaster, w którym wdrożono aplikację.
Przyp. tłum.: W przeglądzie informacji o podziale zasobów i ich kosztach u dostawców chmurowych może również okazać się przydatny serwis i narzędzie , którego przegląd .
Octant
„Rozszerzalna platforma internetowa dla deweloperów, mająca na celu lepsze zrozumienie złożoności klastrów Kubernetes.”
, stworzony w VMware, to nowy produkt, o którym dowiedziałem się stosunkowo niedawno. Umożliwia wygodne badanie klastra na lokalnej maszynie (są nawet wizualizacje), jednak porusza problematykę wsparcia i reakcji na incydenty tylko w ograniczonym zakresie. Wady Octant:
- Brak możliwości wyszukiwania w klastrach.
- Działa tylko na lokalnej maszynie (nie jest wdrażany w klastrze).
- Brak możliwości sortowania/filtracji obiektów (obsługiwany jest tylko selektor etykiet).
- Nie można definiować kolumn użytkownika.
- Nie można wyświetlić listy obiektów według przestrzeni nazw.
Miałem również problemy z stabilnością działania Octant z klastrami Zalando: w niektórych CRD .
Przedstawiam Kubernetes Web View
„kubectl dla internetu”.
Analizując dostępne opcje interfejsów dla Kubernetes, postanowiłem stworzyć nowy: . W końcu potrzebuję tylko całej mocy kubectl w internecie, a mianowicie:
- dostępności wszystkich operacji (tylko do odczytu), w których użytkownicy preferują używać kubectl;
- wszystkie URL-e muszą być stałe i przedstawiać stronę w oryginalnej formie, aby koledzy mogli nimi dzielić się i używać w innych narzędziach;
- wsparcia dla wszystkich obiektów Kubernetes, co pozwoli rozwiązać problem każdego typu;
- listy zasobów powinny być możliwe do pobrania do dalszej pracy (w arkuszach kalkulacyjnych, narzędziach CLI, takich jak
grep) oraz przechowywania (na przykład do postmortemów); - wsparcia dla filtrowania zasobów według etykiet (analogicznie do
kubectl get .. -l); - możliwości tworzenia zgrupowanych list różnych typów zasobów (analogicznie do
kubectl get all) w celu uzyskania ogólnego obrazu operacyjnego wśród kolegów (na przykład w trakcie reakcji na incydent); - możliwości dodawania konfigurowalnych „inteligentnych” głębokich linków do innych narzędzi, takich jak panele monitorowania, logi, rejestry aplikacji itp. w celu ułatwienia wyszukiwania/usuwania błędów i reakcji na incydenty;
- frontend powinien być maksymalnie prosty (czysty HTML), aby uniknąć przypadkowych problemów, takich jak zawieszenie JavaScript;
- wsparcia dla wielu klastrów w celu uproszczenia interakcji podczas zdalnych konsultacji (na przykład, aby zapamiętać tylko jeden URL);
- w miarę możliwości powinien ułatwiać analizę sytuacyjną (na przykład z linkami do pobrania zasobów ze wszystkich klastrów/przestrzeni nazw);
- dodatkowe możliwości tworzenia elastycznych linków oraz wyróżniania informacji tekstowej, na przykład umożliwiające wskazywanie kolegom na konkretną sekcję w opisie zasobu (wiersz w YAML);
- możliwość dostosowania do wymagań konkretnego klienta, na przykład umożliwiająca tworzenie specjalnych szablonów wyświetlania dla CRD, własnych widoków tabelowych, zmienianie stylów CSS;
- narzędzia do dalszego badań w wierszu poleceń (na przykład, pokazując pełne komendy
kubectl, gotowe do skopiowania);
Poza zadaniami do rozwiązania w Kubernetes Web View (non-goals) pozostały:
- abstrahowanie obiektów Kubernetes;
- zarządzanie aplikacjami (na przykład zarządzanie deploymentami, chartami Helm itp.);
- operacje zapisu (muszą być realizowane przez bezpieczne narzędzia CI/CD i/lub GitOps);
- ładny interfejs (JavaScript, motywy itp.);
- wizualizacje (zob. );
- analiza kosztów (zob. ).
Jak Kubernetes Web View pomaga w utrzymaniu i reagowaniu na incydenty?
Wsparcie
- Wszystkie linki są stałe, co ułatwia wymianę informacji z kolegami.
- Można tworzyć własne widoki, na przykład wyświetlić wszystkie Deploymenty i Pody z określonym znacznikiem w dwóch konkretnych klastrach (kilka nazw klastrów i typów zasobów można podać w linku, oddzielając je przecinkami).
- Można odwoływać się do określonych wierszy w pliku YAML obiektu, wskazując na potencjalne problemy ze specyfikacją obiektu.
Wyszukiwanie w klastrach w Kubernetes Web View
Reagowanie na incydenty
- Globalne wyszukiwanie (global search) umożliwia wyszukiwanie obiektów we wszystkich klastrach.
- Widoki w postaci list mogą wyświetlać wszystkie obiekty z określonym stanem/kolumną we wszystkich klastrach (na przykład musimy znaleźć wszystkie pody ze statusem „Pending”).
- Listy obiektów można pobierać w formacie wartości oddzielonych tabulacją (TSV), do dalszej analizy.
- umożliwiają przełączanie się na odpowiednie pulpity nawigacyjne i inne narzędzia.
Kubernetes Web View: lista podów ze statusem „Pending” we wszystkich klastrach
Jeśli chcesz spróbować Kubernetes Web View, rekomenduję zapoznać się z lub zobaczyć .
Oczywiście, interfejs mógłby być lepszy, a na razie Kubernetes Web View jest narzędziem dla „zaawansowanych użytkowników”, którzy nie boją się ręcznie manipulować ścieżkami URL, jeśli zajdzie taka potrzeba. Jeśli masz uwagi/uzupełnienia/propozycje, proszę skontaktuj się !
Ten artykuł jest krótką opowieścią o przesłankach, które doprowadziły do stworzenia Kubernetes Web View. Wkrótce pojawią się inne! (Przyp. tłum.: Można ich oczekiwać w .)
P.S. od tłumacza
Przeczytaj także na naszym blogu:
- «»;
- «»;
- «»;
- «».
Źródło: habr.com
