🥇 Verktyg för applikationsutvecklare som körs i Kubernetes

En modern strategi för drift löser många aktuella affärsproblem. Containrar och orkestratorer gör det enkelt att skala projekt av alla svårighetsgrader, förenklar lanseringar av nya versioner och gör dem mer pålitliga, men skapar samtidigt ytterligare problem för utvecklare. Utvecklaren är primärt intresserad av sin kod: arkitektur, kvalitet, prestanda, elegans – snarare än hur den körs i Kubernetes och hur den ska testas och felsökas efter även de minsta ändringar. Därför är det mycket rimligt att det aktivt utvecklas verktyg för Kubernetes som hjälper till att lösa problemen även för de mest "arkaiska" utvecklarna och låter dem fokusera på det väsentliga.

Denna översyn ger en kort information om vissa verktyg som förenklar livet för programmerare vars kod körs i poddar inom Kubernetes-klustret.

Enkla hjälpare

Kubectl-debug

Essensen: lägg till din container i Pod och se vad som händer där.
GitHub.
Kort statistik från GH: 715 stjärnor, 54 commits, 9 bidragsgivare.
Språk: Go.
Licens: Apache License 2.0.

Denna plugin för kubectl möjliggör att skapa en extra container inuti den aktuella podden, som kommer att dela processnamnrymd med de andra containrarna. I den kan du debugga poddens funktion: kontrollera nätverksanslutning, övervaka nätverkstrafik, utföra strace på en intressant process, etc.

Du kan också växla till processcontainern genom att utföra chroot /proc/PID/root – detta är mycket praktiskt när du behöver få root-shell i containern, för vilken det i manifestet har ställts in securityContext.runAs.

Verktyget är enkelt och effektivt, så det kan vara till nytta för varje utvecklare. Mer om det har vi skrivit i en separat artikel.

Telepresence

Essensen: flytta applikationen till din dator. Utveckla och debugga lokalt.
Webbplats; GitHub.
Kort statistik från GH: 2131 stjärnor, 2712 commits, 33 bidragsgivare.
Språk: Python.
Licens: Apache License 2.0.

Idén med denna komponent är att köra en container med applikationen på en lokal användardator och proxy hela trafiken från klustret till den och tillbaka. Denna metod gör det möjligt att utveckla lokalt genom att enkelt ändra filer i din favorit-IDE: resultaten blir omedelbart tillgängliga.

Fördelarna med lokal körning är bekvämligheten vid ändringar och omedelbara resultat, samt möjligheten att felsöka applikationen på det sätt man är van vid. Nackdelarna inkluderar krav på hastighet på anslutningen, vilket blir särskilt märkbart när man arbetar med en applikation med tillräckligt hög RPS och trafik. Dessutom har Telepresence problem med volymmonteringar i Windows, vilket kan bli en avgörande begränsning för utvecklare som är vana vid detta operativsystem.

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

Ksync

Essensen: nästan omedelbar synkronisering av kod med containern i klustret..
GitHub.
Kort statistik från GH: 555 stjärnor, 362 commits, 11 bidragsgivare.
Språk: Go.
Licens: Apache License 2.0.

Verktyget gör det möjligt att synkronisera innehållet i en lokal katalog med katalogen för en container som körs i klustret. Detta verktyg passar utmärkt för utvecklare som arbetar med skriptspråk, vars största problem är att få koden in i en fungerande container. Ksync är avsett att lösa denna huvudvärk.

Vid engångsinitialisering med kommandot ksync init skapas en DaemonSet i klustret, som används för att övervaka tillståndet för filsystemet i den valda containern. På sin lokala dator kör utvecklaren kommandot ksync watch, som övervakar konfigurationerna och startar syncthing, som utför den faktiska synkroniseringen av filer med klustret.

Det återstår att instruera ksync om vad som ska synkroniseras med vad. Till exempel, ett sådant kommando:

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

… kommer att skapa en watcher med namnet myproject, som kommer att leta efter en pod med etiketten app=backend och försöka synkronisera den lokala katalogen /home/user/myproject/ med katalogen /var/www/myproject/ i containern med namnet php.

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

På noder i Kubernetes-klustret måste overlay2 användas som lagringsdrivrutin för Docker. Ingen annan kommer att fungera med verktyget.
Vid användning av Windows som klient-OS kan det förekomma felaktigt beteende hos filsystemets watcher. Denna bugg har observerats vid arbete med stora kataloger — med många inbäddade filer och kataloger. Vi har skapat en motsvarande issue i syncthing-projektet, men det har hittills (sedan början av juli) inte skett någon framsteg.
Använd filen .stignore för att ange sökvägar eller filmall som inte ska synkroniseras (till exempel kataloger app/cache och .git).
Som standard kommer ksync att starta om containern vid varje ändring av filer. För Node.js är detta användbart, 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 justeras i $HOME/.ksync/ksync.yaml.

Squash

Essensen: debuge processer direkt i klustret.
GitHub.
Kort statistik GH: 1154 stjärnor, 279 commits, 23 bidra.
Språk: Go.
Licens: Apache License 2.0.

Detta verktyg är avsett för att debuga processer direkt i poddar. Verktyget är enkelt och tillåter i interaktivt läge att välja den önskade debuggern (se nedan) och namespace + pod, i den process som behöver ingripas i. För närvarande stöds:

delve — för Go-appar;
GDB — via target remote + port forwarding;
port forwarding JDWP för att debugga Java-appar.

Från IDE-sidan finns det stöd endast i VScode (med hjälp av tillägget), men det finns planer för det aktuella (2019) året för Eclipse och Intellij.

För att debugga processer startar Squash en privilegierad container på klusternoderna, så det är nödvändigt att först bekanta sig med möjligheterna säkert läge för att undvika säkerhetsproblem.

Komplexa lösningar

Vi går vidare till den tunga artilleriet – mer ”skala”-projekt som syftar till att omedelbart täcka många utvecklares behov.

NB: I denna lista finns det utan tvekan plats för vår Open Source-nytta werf (tidigare känd som dapp). Vi har dock redan skrivit och berättat om den flera gånger, så vi har beslutat att inte inkludera den i översikten. För dem som vill bekanta sig närmare med dess möjligheter rekommenderar vi att läsa/lyssna på föredraget “werf — vårt verktyg för CI/CD i Kubernetes».

DevSpace

Essensen: för dem som vill börja arbeta i Kubernetes men inte vill gå djupt in i dess fällor.
GitHub.
Kort statistik GH: 630 stjärnor, 1912 commits, 13 bidra.
Språk: Go.
Licens: Apache License 2.0.

Lösning av det namngivna företaget som tillhandahåller managed-kluster med Kubernetes för teamutveckling. Verktyget skapades för kommersiella kluster, men fungerar också utmärkt med andra.

När kommandot devspace init i katalogen med projektet körs kommer du att erbjudas (i interaktivt läge):

välja en arbets Kubernetes-kluster,
använda en befintlig Dockerfile (eller generera en ny) för att skapa en container baserat på den,
välja ett repository för att lagra containerbilder och så vidare.

Efter alla dessa förberedande åtgärder kan man börja utvecklingen genom att köra kommandot devspace dev. Det kommer att samla containern, ladda upp den till förvaret, lansera deployment i klustret och starta portvidarebefordran och synkronisera containern med den lokala katalogen.

Det kommer att erbjudas att gå in i containern via terminalen, vilket rekommenderas, eftersom containern faktiskt startar med kommandot sleep, och för verklig testning krävs att applikationen startas manuellt.

Till slut kommer kommandot devspace deploy att lansera applikationen och dess relaterade infrastruktur i klustret, efter vilket allt börjar fungera i produktionsläge.

All projektkonfiguration lagras i filen devspace.yaml. Förutom utvecklingsmiljöinställningar kan man också hitta en beskrivning av infrastrukturen här, liknande standardmanifesten från Kubernetes, men kraftigt förenklade.

Arkitektur och huvudsteg med DevSpace

Dessutom är det enkelt att lägga till en fördefinierad komponent i projektet (till exempel databashanteraren MySQL) eller Helm-chart. Läs mer i dokumentationen — den är inte komplicerad.

Skaffold

Webbplats; GitHub.
Kort statistik från GH: 7423 stjärnor, 4173 commits, 136 bidragsgivare.
Språk: Go.
Licens: Apache License 2.0.

Detta verktyg från Google syftar till att täcka alla behov för en utvecklare vars kod på något sätt kommer att köras i ett Kubernetes-kluster. Att börja använda det är inte så enkelt som med devspace: ingen interaktivitet, språkinställningar och automatisk skapande Dockerfile kommer du inte att bli erbjuden här.

Men om detta inte skrämmer dig — här är vad Skaffold möjliggör:

Att övervaka ändringar i källkoden.
Synchronisera det med podens container, om det inte kräver byggande.
Bygga containrar med koden, om programmeringsspråket är tolkat, eller kompilera artefakter och paketera dem i containrar.
De resulterande bilderna kontrolleras automatiskt med hjälp av container-structure-test.
Tagga och ladda upp bilder till Docker Registry.
Distribuera applikationen i klustret med hjälp av kubectl, Helm eller kustomize.
Göra portvidarebefordran.
Felsöka applikationer skrivna i Java, Node.js, Python.

Arbetsflödet i olika variationer beskrivs deklarativt i filen skaffold.yaml. För projektet kan man även definiera flera profiler där man delvis eller helt ändrar bygg- och deploy-stegen. Till exempel kan man för utveckling ange en grundbild som är bekväm för utvecklaren, och för staging och produktion – en minimal (+ använda securityContext eller åsidosätta klustret där applikationen kommer att driftsättas).

Byggning av Docker-containrar kan utföras lokalt eller på distans: i Google Cloud Build eller i klustret med hjälp av Kaniko. Dessutom stöds Bazel och Jib Maven/Gradle. För taggning stöder Skaffold många strategier: utifrån git commit hash, datum/tid, sha256-summa av källkoden osv.

Det är också värt att nämna möjligheten att testa containrar. Det redan nämnda ramverket container-structure-test erbjuder följande metoder för kontroll:

Utföra kommandon i containerns kontext med spårning av exit-statusar och kontroll av den textuella 'utgången' av kommandot.
Kontroll av filernas existens i containern och överensstämmelse av attribut mot angivna.
Kontroll av filinnehåll enligt reguljära uttryck.
Jämförelse av imagenas metadata (ENV, ENTRYPOINT, VOLUMES och liknande).
Kontroll av licenskompatibilitet.

Fil synkronisering med containern genomförs på ett mindre optimalt sätt: Skaffold skapar helt enkelt ett arkiv med källkoden, kopierar det och packar upp det i containern (tar måste vara installerat). Därför, om din huvudsakliga uppgift är kodsynkronisering, är det bättre att titta åt ett specialiserat verktyg (ksync).

Huvudstegen i Skaffold

I allmänhet tillåter verktyget inte att man abstraherar från Kubernetes-manifest och har ingen interaktivitet, så det kan verka svårt att lära sig. Men just detta är också dess fördel – stor frihet i handlandet.

Garden

Webbplats; GitHub.
Kort statistik på GH: 1063 stjärnor, 1927 commits, 17 bidragsgivare.
Språk: TypeScript (det planeras att dela projektet i flera komponenter, varav vissa kommer vara på Go, samt att skapa SDK för tillägg på TypeScript/JavaScript och Go).
Licens: Apache License 2.0.

Precis som Skaffold syftar Garden till att automatisera processerna för kodleverans av applikationen till K8s-klustret. För detta måste man först beskriva projektstrukturen i en YAML-fil och sedan köra kommandot garden dev. Det kommer att utföra all magi:

Samla containrar med olika delar av projektet.
Genomföra integrations- och enhetstester, om sådana har beskrivits.
Det kommer att rulla ut alla projektkomponenter till klustret.
Vid ändring av källkoden kommer hela pipelinen att startas om.

Fokus vid användning av detta verktyg ligger på gemensamt bruk av det fjärrstyrda klustret av utvecklarteamet. Om vissa bygg- och teststeg redan har genomförts kommer detta avsevärt att snabba upp hela processen, eftersom Garden kan använda cachelagrade resultat.

Projektmodulen kan vara en container, en Maven-container, ett Helm-diagram, ett manifest för kubectl apply eller till och med en OpenFaaS-funktion. Dessutom kan vilken modul som helst hämtas från ett fjärr-Git-repo. Modulen kan definiera (eller inte) tjänster, uppgifter och tester. Tjänster och uppgifter kan ha beroenden, vilket gör att man kan definiera i vilken ordning olika tjänster ska distribueras och ordna startordningen för uppgifter och tester.

Garden erbjuder användaren en vacker dashboard (fortfarande i experimentellt tillstånd), där projektgrafen visas: komponenter, byggsekvens, utförande av uppgifter och tester, deras relationer och beroenden. Direkt i webbläsaren kan man se loggar för alla projektkomponenter, kontrollera vad varje komponent returnerar via HTTP (om en ingress-resurs är deklarerad för den, förstås).

Panel för Garden

Detta verktyg har också ett hot-reload-läge, som helt enkelt synkroniserar ändringar i skripten med containern i klustret, vilket avsevärt påskyndar felavkänning av applikationen. Garden har en bra dokumentation och inte dålig uppsättning exempel, som gör att man snabbt kan sätta sig in i det och börja använda det. Förresten, nyligen publicerade vi översättningen av artikeln från dess författare.

Slutsats

Självklart begränsar denna lista inte verktygen för utveckling och felsökning av applikationer i Kubernetes. Det finns fortfarande många mycket användbara och praktiska verktyg som förtjänar, om inte en separat artikel, så åtminstone ett omnämnande. Berätta vad du använder, vilka problem du har stött på och hur du har löst dem!