🥇Verktyg för utvecklare av applikationer som körs på Kubernetes

Ett modernt arbetssätt löser många pressande affärsproblem. Behållare och orkestratorer gör det enkelt att skala projekt av vilken komplexitet som helst, förenklar utgivningen av nya versioner, gör dem mer tillförlitliga, men samtidigt skapar de ytterligare problem för utvecklare. Programmeraren bryr sig först och främst om sin kod: arkitektur, kvalitet, prestanda, elegans - och inte hur det kommer att fungera i Kubernetes och hur man testar och felsöker det efter att ha gjort till och med minimala ändringar. Därför är det också ganska naturligt att verktyg för Kubernetes aktivt utvecklas, vilket hjälper till att lösa problemen för även de mest "åldriga" utvecklarna och låter dem fokusera på det viktigaste.

Den här recensionen ger kort information om några av verktygen som gör livet lättare för en programmerare vars kod körs i pod'axen i ett Kubernetes-kluster.

Enkla hjälpare

Kubectl-debug

Den nedersta raden: lägg till din behållare i en Pod och se vad som händer i den.
GitHub.
Kort GH-statistik: 715 stjärnor, 54 commits, 9 bidragsgivare.
Språk: Gå.
Licens: Apache License 2.0.

Denna plugin för kubectl låter dig skapa en extra behållare inuti podden av intresse, som kommer att dela processens namnutrymme med andra behållare. I den kan du felsöka poddens funktion: kontrollera nätverket, lyssna på nätverkstrafik, göra en del av processen av intresse, etc.

Du kan också byta till processbehållaren genom att köra chroot /proc/PID/root - det här kan vara väldigt praktiskt när du behöver få ett rotskal i en behållare som det är satt till i manifestet securityContext.runAs.

Verktyget är enkelt och effektivt, så det kan vara användbart för alla utvecklare. Vi skrev mer om det i separat artikel.

Telenärvaro

Den nedersta raden: överföra programmet till din dator. Utveckla och felsöka lokalt.
webbplats; GitHub.
Kort GH-statistik: 2131 stjärnor, 2712 commits, 33 bidragsgivare.
Språk: Python.
Licens: Apache License 2.0.

Tanken med denna snap-in är att starta en behållare med applikationen på den lokala användardatorn och proxy för all trafik från klustret till den och tillbaka. Detta tillvägagångssätt låter dig utveckla lokalt genom att helt enkelt redigera filer i din favorit-IDE: resultaten kommer att vara tillgängliga omedelbart.

Fördelarna med att köra lokalt är bekvämligheten med redigeringar och omedelbara resultat, möjligheten att felsöka applikationen på vanligt sätt. Nackdelen är att det är krävande på uppkopplingshastigheten, vilket märks särskilt när man ska jobba med en applikation med ganska hög RPS och trafik. Dessutom har Telepresence problem med volymfästen på Windows, vilket kan vara en avgörande begränsning för utvecklare som är vana vid detta OS.

Vi har redan delat med oss av vår erfarenhet av att använda Telepresence här.

Ksync

Den nedersta raden: nästan omedelbar synkronisering av kod med behållaren i klustret.
GitHub.
Kort GH-statistik: 555 stjärnor, 362 commits, 11 bidragsgivare.
Språk: Gå.
Licens: Apache License 2.0.

Verktyget låter dig synkronisera innehållet i en lokal katalog med katalogen för en behållare som körs i klustret. Det här verktyget är perfekt för utvecklare som arbetar med skriptprogrammeringsspråk, vars huvudproblem är att leverera kod till en körande behållare. Ksync är utformad för att lindra denna huvudvärk.

När den initieras en gång av kommandot ksync init en DaemonSet skapas i klustret, som används för att övervaka tillståndet för filsystemet för den valda behållaren. På sin lokala dator kör utvecklaren kommandot ksync watch, som övervakar konfigurationer och körningar syncthing, som direkt synkroniserar filer med klustret.

Allt som återstår är att instruera ksync vad som ska synkroniseras med vad. Till exempel detta kommando:

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

...kommer att skapa en bevakare som heter myprojectsom kommer att söka efter en pod med en etikett app=backend och försök att synkronisera den lokala katalogen /home/user/myproject/ med katalog /var/www/myproject/ vid containern som kallas php.

Problem och anteckningar om ksync från vår erfarenhet:

Måste användas på Kubernetes klusternoder overlay2 som lagringsdrivrutin för Docker. Verktyget fungerar inte med andra.
När du använder Windows som ett klientoperativsystem kanske filsystemövervakningen inte fungerar korrekt. Denna bugg uppmärksammades när man arbetade med stora kataloger - med ett stort antal kapslade filer och kataloger. Vi skapade relevant fråga i synkroniseringsprojektet, men det finns inga framsteg på det ännu (sedan början av juli).
Använd fil .stignore för att ange sökvägar eller filmönster som inte behöver synkroniseras (till exempel kataloger app/cache и .git).
Som standard kommer ksync att starta om behållaren när filerna ändras. För Node.js är detta bekvämt, men för PHP är det helt onödigt. Det är bättre att stänga av opcache och använda flaggan --reload=false.
Konfigurationen kan alltid korrigeras i $HOME/.ksync/ksync.yaml.

squash

Den nedersta raden: felsöka processer direkt i klustret.
GitHub.
Kort GH-statistik: 1154 stjärnor, 279 commits, 23 bidragsgivare.
Språk: Gå.
Licens: Apache License 2.0.

Detta verktyg är designat för att felsöka processer direkt i pods. Verktyget är enkelt och interaktivt låter dig välja önskad debugger (se nedan) och namnutrymme + pod, i processen som du måste ingripa. Stöds för närvarande:

dyka - för Go-applikationer;
GDB - via målfjärr + portvidarebefordran;
JDWP-portvidarebefordran för felsökning av Java-applikationer.

På IDE-sidan är stöd endast tillgängligt i VScode (med expansionen), men planer för innevarande (2019) år inkluderar Eclipse och Intellij.

För att felsöka processer kör Squash en privilegierad behållare på klusternoderna, så du måste först bekanta dig med funktionerna säkert läge för att undvika säkerhetsproblem.

Kompletta lösningar

Låt oss gå vidare till det tunga artilleriet - mer "storskaliga" projekt utformade för att omedelbart möta många av utvecklarnas behov.

NB: I den här listan finns det naturligtvis en plats för vårt Open Source-verktyg werf (tidigare känd som dapp). Men vi har redan skrivit och pratat om det mer än en gång och beslutade därför att inte ta med det i recensionen. För dem som vill bli mer bekanta med dess kapacitet rekommenderar vi att läsa/lyssna på rapporten "werf är vårt verktyg för CI/CD i Kubernetes".

DevSpace

Den nedersta raden: för dig som vill börja arbeta i Kubernetes, men inte vill gräva djupt in i dess djungel.
GitHub.
Kort GH-statistik: 630 stjärnor, 1912 engagerade, 13 bidragsgivare.
Språk: Gå.
Licens: Apache License 2.0.

En lösning från företaget med samma namn, som tillhandahåller hanterade kluster med Kubernetes för teamutveckling. Verktyget skapades för kommersiella kluster, men fungerar utmärkt med alla andra.

När du kör kommandot devspace init i projektkatalogen kommer du att erbjudas (interaktivt):

välj ett fungerande Kubernetes-kluster,
Använd existerande Dockerfile (eller generera en ny) för att skapa en behållare baserad på den,
välj ett arkiv för att lagra behållarbilder etc.

Efter alla dessa förberedande steg kan du starta utvecklingen genom att köra kommandot devspace dev. Den kommer att bygga behållaren, ladda upp den till förvaret, rulla ut distributionen till klustret och starta portvidarebefordran och synkronisering av behållaren med den lokala katalogen.

Alternativt kommer du att uppmanas att flytta terminalen till containern. Du bör inte vägra, för i själva verket börjar behållaren med sleep-kommandot, och för riktig testning måste applikationen startas manuellt.

Äntligen laget devspace deploy rullar ut applikationen och tillhörande infrastruktur till klustret, varefter allt börjar fungera i stridsläge.

All projektkonfiguration lagras i en fil devspace.yaml. Utöver inställningarna för utvecklingsmiljön kan du också hitta en beskrivning av infrastrukturen i den, som liknar vanliga Kubernetes-manifester, bara mycket förenklad.

Arkitektur och huvudstadier i arbetet med DevSpace

Dessutom är det enkelt att lägga till en fördefinierad komponent (till exempel en MySQL DBMS) eller ett Helm-diagram till projektet. Läs mer i dokumentation – det är inte komplicerat.

Skaffold

webbplats; GitHub.
Kort GH-statistik: 7423 stjärnor, 4173 commits, 136 bidragsgivare.
Språk: Gå.
Licens: Apache License 2.0.

Det här verktyget från Google påstår sig täcka alla behov hos en utvecklare vars kod på något sätt kommer att köras på ett Kubernetes-kluster. Att börja använda det är inte lika lätt som devspace: ingen interaktivitet, språkdetektering och automatiskt skapande Dockerfile de kommer inte att erbjuda dig det här.

Men om detta inte skrämmer dig, här är vad Skaffold låter dig göra:

Spåra ändringar i källkoden.
Synkronisera den med podbehållaren om den inte kräver montering.
Samla behållare med kod, om språket tolkas, eller kompilera artefakter och packa dem i behållare.
De resulterande bilderna kontrolleras automatiskt med container-struktur-test.
Tagga och ladda upp bilder till Docker Registry.
Distribuera en applikation i ett kluster med kubectl, Helm eller kustomize.
Utför portvidarebefordran.
Felsök applikationer skrivna i Java, Node.js, Python.

Arbetsflöde i olika varianter beskrivs deklarativt i filen skaffold.yaml. För ett projekt kan du också definiera flera profiler där du helt eller delvis kan ändra monterings- och distributionsstegen. Till exempel, för framkallning, ange en basbild som är bekväm för utvecklaren, och för iscensättning och produktion - en minimal (+ användning securityContext behållare eller omdefiniera klustret där applikationen kommer att distribueras).

Dockercontainrar kan byggas lokalt eller på distans: in Google Cloud Build eller i ett kluster med hjälp av Kaniko. Bazel och Jib Maven/Gradle stöds också. För taggning stöder Skaffold många strategier: genom git commit hash, datum/tid, sha256-summan av källor, etc.

Separat är det värt att notera möjligheten att testa behållare. Det redan nämnda ramverket för container-structure-test erbjuder följande verifieringsmetoder:

Utföra kommandon i sammanhanget av en container med spårande utgångsstatusar och kontrollera kommandots textutmatning.
Kontrollera förekomsten av filer i behållaren och matcha de angivna attributen.
Styrning av filinnehåll med hjälp av reguljära uttryck.
Verifiering av bildmetadata (ENV, ENTRYPOINT, VOLUMES etc).
Kontrollerar licenskompatibilitet.

Synkronisering av filer med behållaren utförs inte på det mest optimala sättet: Skaffold skapar helt enkelt ett arkiv med källorna, kopierar det och packar upp det i behållaren (tar måste installeras). Därför, om din huvuduppgift är kodsynkronisering, är det bättre att titta mot en specialiserad lösning (ksync).

Huvudskeden av Skaffold-driften

I allmänhet tillåter verktyget dig inte att abstrahera från Kubernetes-manifester och har ingen interaktivitet, så det kan tyckas svårt att bemästra. Men detta är också dess fördel - större handlingsfrihet.

Trädgård

webbplats; GitHub.
Kort GH-statistik: 1063 stjärnor, 1927 engagerade, 17 bidragsgivare.
Språk: TypeScript (det är planerat att dela upp projektet i flera komponenter, varav några kommer att vara i Go, och även göra en SDK för att skapa tillägg i TypeScript/JavaScript och Go).
Licens: Apache License 2.0.

Liksom Skaffold strävar Garden efter att automatisera processerna för att leverera applikationskod till K8s-klustret. För att göra detta måste du först beskriva projektstrukturen i en YAML-fil och sedan köra kommandot garden dev. Hon kommer att göra all magi:

Samla behållare med olika delar av projektet.
Genomför integrations- och enhetstester, om sådana har beskrivits.
Rulla ut alla projektkomponenter till klustret.
Om källkoden ändras kommer den att starta om hela pipelinen.

Huvudfokus för att använda detta verktyg är att dela ett fjärrkluster med ett utvecklingsteam. I det här fallet, om några av byggnads- och teststegen redan har gjorts, kommer detta att påskynda hela processen avsevärt, eftersom Garden kommer att kunna använda de cachade resultaten.

En projektmodul kan vara en behållare, en Maven-behållare, ett Helm-diagram, ett manifest för kubectl apply eller till och med en OpenFaaS-funktion. Dessutom kan vilken som helst av modulerna hämtas från ett avlägset Git-förråd. En modul kan eller kanske inte definierar tjänster, uppgifter och tester. Tjänster och uppgifter kan ha beroenden, så du kan bestämma distributionssekvensen för en viss tjänst och organisera lanseringen av uppgifter och tester.

Garden ger användaren en vacker instrumentbräda (för närvarande i experimentellt tillstånd), som visar projektdiagrammet: komponenter, monteringssekvens, utförande av uppgifter och tester, deras kopplingar och beroenden. Direkt i webbläsaren kan du se loggarna för alla projektkomponenter och kontrollera vad en viss komponent matar ut via HTTP (om, naturligtvis, en ingångsresurs är deklarerad för den).

Panel för trädgård

Detta verktyg har också ett hot-reload-läge, som helt enkelt synkroniserar skriptändringar med behållaren i klustret, vilket avsevärt påskyndar applikationsfelsökningsprocessen. Trädgården har en bra dokumentationen och inte dåligt uppsättning exempel, så att du snabbt kan vänja dig vid den och börja använda den. Förresten, nyligen publicerade vi artikelöversättning från dess författare.

Slutsats

Naturligtvis är den här listan med verktyg för att utveckla och felsöka applikationer i Kubernetes inte begränsad till. Det finns många fler mycket användbara och praktiska verktyg som är värda, om inte en separat artikel, så åtminstone ett omnämnande. Berätta för oss vad du använder, vilka problem du stött på och hur du löste dem!

PS

Läs även på vår blogg:

Källa: will.com

Verktyg för utvecklare av applikationer som körs på Kubernetes