🥇Narzędzia dla programistów aplikacji działających na Kubernetesie

Nowoczesne podejście do operacji rozwiązuje wiele palących problemów biznesowych. Kontenery i orkiestratory ułatwiają skalowanie projektów o dowolnej złożoności, upraszczają wydawanie nowych wersji, czynią je bardziej niezawodnymi, ale jednocześnie stwarzają dodatkowe problemy dla programistów. Programista dba przede wszystkim o swój kod: architekturę, jakość, wydajność, elegancję – a nie o to, jak będzie on działał w Kubernetesie i jak go testować i debugować po wprowadzeniu nawet minimalnych zmian. Dlatego też całkiem naturalne jest, że aktywnie rozwijane są narzędzia dla Kubernetesa, pomagające rozwiązywać problemy nawet najbardziej „archaicznych” programistów i pozwalające im skupić się na tym, co najważniejsze.

Ta recenzja zawiera krótkie informacje na temat niektórych narzędzi, które ułatwiają życie programiście, którego kod działa w pod'axie klastra Kubernetes.

Prości pomocnicy

Debugowanie Kubectl

Dolna linia: dodaj swój kontener do Poda i zobacz, co się w nim stanie.
GitHub.
Krótka statystyka GH: 715 gwiazdek, 54 zatwierdzeń, 9 współpracowników.
Język: Idź.
Licencja: Licencja Apache 2.0.

Ta wtyczka do kubectl umożliwia utworzenie dodatkowego kontenera wewnątrz interesującego go poda, który będzie dzielić przestrzeń nazw procesu z innymi kontenerami. Można w nim debugować działanie kapsuły: sprawdzać sieć, słuchać ruchu sieciowego, śledzić interesujący nas proces itp.

Możesz także przełączyć się do kontenera procesów, uruchamiając chroot /proc/PID/root - może to być bardzo wygodne, gdy trzeba uzyskać powłokę root w kontenerze, dla którego jest ona ustawiona w manifeście securityContext.runAs.

Narzędzie jest proste i skuteczne, dlatego może przydać się każdemu programiście. Więcej o tym pisaliśmy w osobny artykuł.

Teleobecność

Dolna linia: przenieś aplikację na swój komputer. Twórz i debuguj lokalnie.
Strona; GitHub.
Krótka statystyka GH: 2131 gwiazdek, 2712 zatwierdzeń, 33 autorów.
Język: Python.
Licencja: Licencja Apache 2.0.

Ideą tej przystawki jest uruchomienie kontenera z aplikacją na lokalnym komputerze użytkownika i proxy całego ruchu z klastra do niego i z powrotem. Takie podejście pozwala na rozwój lokalny poprzez prostą edycję plików w ulubionym IDE: wyniki będą dostępne natychmiast.

Zaletami działania lokalnego są wygoda edycji i natychmiastowe rezultaty, możliwość debugowania aplikacji w zwykły sposób. Wadą jest to, że wymaga szybkości połączenia, co jest szczególnie zauważalne, gdy musisz pracować z aplikacją o dość wysokim RPS i ruchu. Ponadto Telepresence ma problemy z montowaniem woluminów w systemie Windows, co może być zdecydowanym ograniczeniem dla programistów przyzwyczajonych do tego systemu operacyjnego.

Podzieliliśmy się już naszymi doświadczeniami z korzystania z Teleobecności tutaj.

Ksync

Dolna linia: niemal natychmiastowa synchronizacja kodu z kontenerem w klastrze.
GitHub.
Krótka statystyka GH: 555 gwiazdek, 362 zatwierdzeń, 11 współpracowników.
Język: Idź.
Licencja: Licencja Apache 2.0.

Narzędzie umożliwia synchronizację zawartości katalogu lokalnego z katalogiem kontenera działającego w klastrze. Takie narzędzie jest idealne dla programistów zajmujących się skryptowymi językami programowania, których głównym problemem jest dostarczenie kodu do działającego kontenera. Ksync został zaprojektowany, aby złagodzić ten ból głowy.

Po jednokrotnym zainicjowaniu poleceniem ksync init w klastrze tworzony jest DaemonSet, który służy do monitorowania stanu systemu plików wybranego kontenera. Na swoim komputerze lokalnym programista uruchamia polecenie ksync watch, który monitoruje konfiguracje i działa syncthing, który bezpośrednio synchronizuje pliki z klastrem.

Pozostaje tylko poinstruować ksync, co z czym ma synchronizować. Na przykład to polecenie:

ksync create --name=myproject --namespace=test --selector=app=backend --container=php --reload=false /home/user/myproject/ /var/www/myproject/

...utworzy obserwatora o imieniu myprojectktóry wyszuka kapsułę z etykietą app=backend i spróbuj zsynchronizować katalog lokalny /home/user/myproject/ z katalogiem /var/www/myproject/ przy kontenerze tzw php.

Problemy i uwagi dotyczące ksync z naszego doświadczenia:

Należy go używać w węzłach klastra Kubernetes overlay2 jako sterownik pamięci masowej dla Dockera. Narzędzie nie będzie działać z żadnymi innymi.
W przypadku używania systemu Windows jako systemu klienckiego moduł monitorujący system plików może nie działać poprawnie. Ten błąd został zauważony podczas pracy z dużymi katalogami - z dużą liczbą zagnieżdżonych plików i katalogów. Stworzyliśmy istotna kwestia w projekcie synchronizacji, ale na razie nie ma w nim postępu (od początku lipca).
Użyj pliku .stignore aby określić ścieżki lub wzorce plików, które nie wymagają synchronizacji (na przykład katalogi app/cache и .git).
Domyślnie ksync zrestartuje kontener po każdej zmianie plików. W przypadku Node.js jest to wygodne, ale w przypadku PHP jest to całkowicie niepotrzebne. Lepiej wyłączyć opcache i użyć flagi --reload=false.
Konfigurację zawsze można poprawić $HOME/.ksync/ksync.yaml.

kabaczek

Dolna linia: debuguj procesy bezpośrednio w klastrze.
GitHub.
Krótka statystyka GH: 1154 gwiazdki, 279 zatwierdzeń, 23 autorów.
Język: Idź.
Licencja: Licencja Apache 2.0.

To narzędzie jest przeznaczone do debugowania procesów bezpośrednio w podach. Narzędzie jest proste i interaktywnie pozwala wybrać żądany debuger (patrz poniżej) i przestrzeń nazw + pod, w procesie której musisz interweniować. Obecnie obsługiwane:

zagłębić się - dla aplikacji Go;
GDB - poprzez docelowy zdalny + przekierowanie portów;
Przekierowanie portów JDWP do debugowania aplikacji Java.

Po stronie IDE obsługa jest dostępna tylko w VScode (przy użyciu ekspansja), natomiast w planach na bieżący (2019) rok są Eclipse i Intellij.

Aby debugować procesy, Squash uruchamia uprzywilejowany kontener na węzłach klastra, dlatego musisz najpierw zapoznać się z możliwościami tryb bezpieczeństwa aby uniknąć problemów związanych z bezpieczeństwem.

Kompletne rozwiązania

Przejdźmy do ciężkiej artylerii - więcej projektów „na dużą skalę”, zaprojektowanych tak, aby od razu zaspokoić wiele potrzeb deweloperów.

NB: Na tej liście oczywiście jest miejsce na nasze narzędzie Open Source werf (dawniej znany jako dapp). Jednak pisaliśmy i rozmawialiśmy o tym już nie raz, dlatego postanowiliśmy nie uwzględniać go w recenzji. Osobom chcącym bliżej zapoznać się z jego możliwościami polecamy lekturę/przesłuchanie raportu „werf to nasze narzędzie do CI/CD w Kubernetes".

DevSpace

Dolna linia: dla tych, którzy chcą rozpocząć pracę w Kubernetesie, ale nie chcą zagłębiać się w jego dżunglę.
GitHub.
Krótka statystyka GH: 630 gwiazdek, 1912 zatwierdzeń, 13 autorów.
Język: Idź.
Licencja: Licencja Apache 2.0.

Rozwiązanie firmy o tej samej nazwie, która dostarcza zarządzane klastry z Kubernetesem do rozwoju zespołów. Narzędzie zostało stworzone z myślą o klastrach komercyjnych, ale świetnie współpracuje z każdym innym.

Podczas uruchamiania polecenia devspace init w katalogu projektu zaoferowane zostaną (interaktywnie):

wybierz działający klaster Kubernetes,
Użyj istniejącego Dockerfile (lub wygeneruj nowy), aby na jego podstawie utworzyć kontener,
wybierz repozytorium do przechowywania obrazów kontenerów itp.

Po wszystkich tych krokach przygotowawczych możesz rozpocząć programowanie, uruchamiając polecenie devspace dev. Zbuduje kontener, prześle go do repozytorium, wdroży wdrożenie w klastrze i rozpocznie przekierowywanie portów oraz synchronizację kontenera z katalogiem lokalnym.

Opcjonalnie zostaniesz poproszony o przeniesienie terminala do kontenera. Nie warto odmawiać, bo tak naprawdę kontener uruchamia się komendą uśpienia, a do prawdziwych testów trzeba uruchomić aplikację ręcznie.

Wreszcie zespół devspace deploy wdraża aplikację i związaną z nią infrastrukturę do klastra, po czym wszystko zaczyna funkcjonować w trybie bojowym.

Cała konfiguracja projektu jest przechowywana w pliku devspace.yaml. Oprócz ustawień środowiska deweloperskiego można znaleźć w nim także opis infrastruktury, podobny do standardowych manifestów Kubernetesa, tylko mocno uproszczony.

Architektura i główne etapy pracy z DevSpace

Ponadto łatwo jest dodać do projektu predefiniowany komponent (na przykład MySQL DBMS) lub wykres Helm. Przeczytaj więcej w dokumentacja - to nie jest skomplikowane.

Rusztowanie

Strona; GitHub.
Krótka statystyka GH: 7423 gwiazdki, 4173 zatwierdzeń, 136 współpracowników.
Język: Idź.
Licencja: Licencja Apache 2.0.

To narzędzie Google twierdzi, że zaspokaja wszystkie potrzeby programisty, którego kod będzie w jakiś sposób działał w klastrze Kubernetes. Rozpoczęcie korzystania z niego nie jest tak proste jak devspace: brak interaktywności, wykrywania języka i automatycznego tworzenia Dockerfile nie zaoferują ci tego tutaj.

Jeśli jednak Cię to nie przeraża, oto, co umożliwia Skffold:

Śledź zmiany w kodzie źródłowym.
Zsynchronizuj go z pojemnikiem na kapsułki, jeśli nie wymaga montażu.
Zbieraj pojemniki z kodem, jeśli język jest interpretowany, lub kompiluj artefakty i pakuj je do pojemników.
Powstałe obrazy są automatycznie sprawdzane za pomocą test struktury kontenera.
Oznaczanie i przesyłanie obrazów do rejestru Docker.
Wdróż aplikację w klastrze za pomocą kubectl, Helm lub kustomize.
Wykonaj przekierowanie portów.
Debuguj aplikacje napisane w Java, Node.js, Python.

Przebieg pracy w różnych wariantach jest deklaratywnie opisany w pliku skaffold.yaml. Dla projektu można także zdefiniować kilka profili, w których można częściowo lub całkowicie zmienić etapy montażu i wdrożenia. Na przykład do celów programistycznych określ obraz bazowy wygodny dla programisty, a do postoju i produkcji - minimalny (+ użyj securityContext kontenery lub przedefiniować klaster, w którym aplikacja zostanie wdrożona).

Kontenery Docker można budować lokalnie lub zdalnie: w Kompilacja w chmurze Google lub w klastrze przy użyciu Kaniko. Obsługiwane są także Bazel i Jib Maven/Gradle. W przypadku tagowania Skaffold obsługuje wiele strategii: za pomocą skrótu zatwierdzenia git, daty/godziny, sumy źródeł sha256 itp.

Osobno warto zwrócić uwagę na możliwość testowania kontenerów. Wspomniany już framework do testowania struktury kontenera oferuje następujące metody weryfikacji:

Wykonywanie poleceń w kontekście kontenera ze śledzeniem statusów wyjścia i sprawdzaniem wyniku tekstowego polecenia.
Sprawdzenie obecności plików w kontenerze i dopasowanie określonych atrybutów.
Kontrola zawartości plików za pomocą wyrażeń regularnych.
Weryfikacja metadanych obrazu (ENV, ENTRYPOINT, VOLUMES itp.).
Sprawdzanie zgodności licencji.

Synchronizacja plików z kontenerem nie przebiega w najbardziej optymalny sposób: Skaffold po prostu tworzy archiwum ze źródłami, kopiuje je i rozpakowuje do kontenera (musi być zainstalowany tar). Dlatego jeśli Twoim głównym zadaniem jest synchronizacja kodu, lepiej zwrócić się w stronę specjalistycznego rozwiązania (ksync).

Główne etapy działania Skaffold

Generalnie narzędzie nie pozwala na abstrahowanie od manifestów Kubernetesa i nie cechuje się interaktywnością, przez co może wydawać się trudne do opanowania. Ale to też jest jego zaleta – większa swoboda działania.

Ogród

Strona; GitHub.
Krótka statystyka GH: 1063 gwiazdki, 1927 zatwierdzeń, 17 autorów.
Język: TypeScript (planowane jest podzielenie projektu na kilka komponentów, część z nich będzie w Go, a także wykonanie SDK do tworzenia dodatków w TypeScript/JavaScript i Go).
Licencja: Licencja Apache 2.0.

Podobnie jak Skaffold, Garden ma na celu automatyzację procesów dostarczania kodu aplikacji do klastra K8s. W tym celu należy najpierw opisać strukturę projektu w pliku YAML, a następnie uruchomić komendę garden dev. Ona zrobi całą magię:

Zbieraj pojemniki z różnymi częściami projektu.
Przeprowadza testy integracyjne i jednostkowe, jeśli takie zostały opisane.
Wdraża wszystkie komponenty projektu do klastra.
Jeśli kod źródłowy ulegnie zmianie, cały potok zostanie ponownie uruchomiony.

Głównym celem korzystania z tego narzędzia jest udostępnianie zdalnego klastra zespołowi programistów. W takim przypadku, jeśli niektóre etapy budowania i testowania zostały już wykonane, znacznie przyspieszy to cały proces, ponieważ Garden będzie mógł korzystać z wyników zapisanych w pamięci podręcznej.

Moduł projektu może być kontenerem, kontenerem Mavena, wykresem Helm, manifestem kubectl apply lub nawet funkcję OpenFaaS. Co więcej, dowolny moduł można pobrać ze zdalnego repozytorium Git. Moduł może, ale nie musi, definiować usługi, zadania i testy. Usługi i zadania mogą mieć zależności, dzięki czemu można określić kolejność wdrażania konkretnej usługi i zorganizować uruchamianie zadań i testów.

Garden udostępnia użytkownikowi piękny dashboard (obecnie w wersji stan eksperymentalny), który wyświetla graf projektu: komponenty, kolejność montażu, wykonanie zadań i testów, ich powiązania i zależności. Bezpośrednio w przeglądarce możesz przeglądać logi wszystkich komponentów projektu i sprawdzić, co dany komponent wysyła poprzez HTTP (jeśli oczywiście zadeklarowano dla niego zasób ingresowy).

Panel do ogrodu

Narzędzie to posiada również tryb hot-reload, który po prostu synchronizuje zmiany skryptu z kontenerem w klastrze, znacznie przyspieszając proces debugowania aplikacji. Ogród ma dobry dokumentacja i nieźle zestaw przykładów, co pozwala szybko się do niego przyzwyczaić i zacząć z niego korzystać. Nawiasem mówiąc, niedawno opublikowaliśmy tłumaczenie artykułu od jego autorów.

wniosek

Oczywiście ta lista narzędzi do tworzenia i debugowania aplikacji w Kubernetesie nie ogranicza się do. Istnieje wiele innych bardzo przydatnych i praktycznych narzędzi, które są godne, jeśli nie osobnego artykułu, to przynajmniej wzmianki. Powiedz nam, czego używasz, jakie napotkałeś problemy i jak je rozwiązałeś!

PS

Przeczytaj także na naszym blogu:

Źródło: www.habr.com

Narzędzia dla programistów aplikacji działających na Kubernetesie