🥇Værktøjer til udviklere af applikationer, der kører i Kubernetes

Moderne tilgange til drift løser mange af virksomhedens presserende problemer. Containere og orkestratorer gør det nemt at skalere projekter af enhver kompleksitet, forenkler udgivelser af nye versioner, gør dem mere pålidelige, men skaber samtidig også yderligere problemer for udviklere. Programmører fokuserer først og fremmest på deres kode: arkitektur, kvalitet, ydeevne, elegance — og ikke på, hvordan den skal køres i Kubernetes, samt hvordan den skal testes og fejlrettes efter selv de mindste ændringer. Det er derfor helt naturligt, at værktøjer til Kubernetes, der hjælper med at løse problemer, selv for de mest 'arkaiske' udviklere, aktivt udvikles og giver dem mulighed for at fokusere på det væsentlige.

Denne oversigt indeholder kort information om nogle værktøjer, der gør livet nemmere for programmører, hvis kode kører i pod’ere i Kubernetes-klyngen.

Enkle hjælpere

Kubectl-debug

Essens: tilføj din container til pod’en og se, hvad der sker i den.
GitHub.
Kort statistik fra GH: 715 stjerner, 54 commits, 9 bidragsydere.
Sprog: Go.
Licens: Apache License 2.0.

Denne plugin til kubectl gør det muligt at oprette en ekstra container inde i den ønskede pod, som deler navnerummet for processer med de andre containere. I denne container kan man debugge pod’ens funktion: kontrollere netværksdrift, lytte til netværkstrafik, foretage strace af en interessant proces osv.

Man kan også skifte til procescontaineren ved at udføre chroot /proc/PID/root — dette er særligt nyttigt, når man har brug for at få root shell i en container, hvor "securityContext.runAs" er angivet i manifestet. Værktøjet er enkelt og effektivt, så det kan være nyttigt for enhver udvikler. Læs mere om det i.

en separat artikel Telepresence.

flyt applikationen til din computer. Udvikl og debug lokalt

Essens: Kort statistik fra GH: 2131 stjerne, 2712 commits, 33 bidragsydere..
Webstedet; GitHub.
Sprog: Python.
Ideen med dette værktøj er at køre en container med applikationen på den lokale brugercomputer og proxy al trafik fra klyngen til den og tilbage. Denne tilgang gør det muligt at udvikle lokalt ved blot at ændre filer i din yndlings-IDE: resultaterne vil være tilgængelige med det samme.
Licens: Apache License 2.0.

Ideen med dette værktøj er at køre en container med applikationen på den lokale brugercomputer og proxy al trafik fra klyngen til den og tilbage. Denne tilgang gør det muligt at udvikle lokalt ved blot at ændre filer i din yndlings-IDE: resultaterne vil være tilgængelige med det samme.

Fordele ved lokal kørsel — bekvemmeligheden ved redigeringer og øjeblikkelig feedback, muligheden for at debugge applikationen på den sædvanlige måde. Ulemperne inkluderer et krav til hastigheden af forbindelsen, som især er mærkbart, når man arbejder med applikationer med en relativt høj RPS og trafik. Desuden har Telepresence problemer med volume mounts i Windows, hvilket kan være en afgørende begrænsning for udviklere, der er vant til dette OS.

Vi har allerede delt vores erfaring med at bruge Telepresence her.

Ksync

Essens: næsten øjeblikkelig synkronisering af kode med containeren i klyngen.
GitHub.
Kort statistik fra GH: 555 stjerner, 362 commits, 11 bidragsydere.
Sprog: Go.
Licens: Apache License 2.0.

Værktøjet gør det muligt at synkronisere indholdet af en lokal mappe med biblioteket i en container, der kører i klyngen. Et sådant værktøj er perfekt til udviklere, der arbejder med scriptsprog, hvor hovedproblemet er at få koden ind i den kørende container. Ksync er designet til at fjerne denne hovedpine.

Ved én enkelt initialisering med kommandoen ksync init oprettes der en DaemonSet i klyngen, som bruges til at overvåge tilstanden af filsystemet i den valgte container. På sin lokale computer kører udvikleren kommandoen ksync watch, som holder øje med konfigurationerne og starter syncthing, som udfører den direkte synkronisering af filer med klyngen.

Det er nu nødvendigt at instruere ksync om, hvad der skal synkroniseres med hvad. For eksempel kan en sådan kommando bruges:

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

… vil oprette en watcher med navnet myproject, som vil søge efter en pod med etiketten app=backend og forsøge at synkronisere den lokale mappe /home/user/myproject/ med biblioteket /var/www/myproject/ i containeren med navnet php.

Problemer og bemærkninger om ksync baseret på vores erfaring:

På Kubernetes-klynge noderne skal der anvendes overlay2 som storage driver for Docker. Ingen andre værktøjer vil fungere med det.
Når man bruger Windows som klient-OS, kan der opstå problemer med filsystemets watcher. Denne fejl er bemærket ved brug af store mapper — med mange indlejrede filer og mapper. Vi har oprettet en tilsvarende issue i syncthing-projektet, men der er stadig ikke sket nogen fremskridt siden starten af juli.
Brug filen .stignore for at angive stier eller filskabeloner, der ikke skal synkroniseres (for eksempel kataloger app/cache og .git).
Som standard genstarter ksync containeren ved hver ændring af filer. For Node.js er det praktisk, men for PHP er det helt unødvendigt. Det er bedre at deaktivere opcache og bruge flaget --reload=false.
Konfigurationen kan altid rettes i $HOME/.ksync/ksync.yaml.

Squash

Essens: debugge processer direkte i klyngen.
GitHub.
Kort statistik GH: 1154 stjerner, 279 commits, 23 bidragsydere.
Sprog: Go.
Licens: Apache License 2.0.

Dette værktøj er designet til at debugge processer direkte i pod'ene. Værktøjet er enkelt og i interaktiv tilstand muliggør valg af den nødvendige debugger (se nedenfor) og namespace + pod, hvor der skal intervenere. I øjeblikket understøttes:

delve — til applikationer på Go;
GDB — via target remote + port forwarding;
port forwarding JDWP til debugging af Java-applikationer.

Fra IDE-siden er der kun support i VScode (ved hjælp af udvidelsen), men der er planer for det nuværende (2019) år for Eclipse og Intellij.

Til debugging kører Squash en privilegeret container på cluster nodene, så det er nødvendigt først at gøre sig bekendt med mulighederne for sikkerhedsmodus for at undgå sikkerhedsproblemer.

Komplekse løsninger

Lad os gå videre til den tunge artilleri — mere 'skala' projekter, der skal dække mange behov for udviklere.

NB: I denne liste er der uden tvivl også plads til vores Open Source-værktøj werf (tidligere kendt som dapp). Men vi har allerede skrevet og talt om det mange gange, så vi har besluttet ikke at inkludere det i oversigten. For dem, der ønsker at lære mere om dets muligheder, anbefaler vi at læse/lytte til rapporten 'werf — vores værktøj til CI/CD i Kubernetes».

DevSpace

Essens: for dem, der ønsker at begynde at arbejde med Kubernetes, men ikke vil dykke dybt ned i dets kompleksiteter.
GitHub.
Kort statistik GH: 630 stjerner, 1912 commits, 13 bidragsydere.
Sprog: Go.
Licens: Apache License 2.0.

Løsningen fra det samme selskab, der tilbyder managed-klynger med Kubernetes til teamwork. Værktøjet blev skabt til kommercielle klynger, men fungerer også fantastisk med andre.

Når du kører kommandoen devspace init i mappen med projektet vil du blive bedt om (i interaktiv tilstand):

at vælge en arbejds Kubernetes-klynge,
at bruge en eksisterende Dockerfile (eller generere en ny) til at oprette en container på dens basis,
at vælge et repository til opbevaring af containerbilleder osv.

Efter alle disse forberedende handlinger kan udviklingen begynde med at køre kommandoen devspace dev. Den vil samle containeren, uploade den til depotet, implementere deployment i klyngen og starte port forwarding og synkronisering af containeren med det lokale bibliotek.

Valgfrit vil du blive bedt om at gå ind i containeren via terminalen. Det bør ikke afvises, for i virkeligheden starter containeren med kommandoen sleep, og til reel testning skal applikationen startes manuelt.

Endelig kører kommandoen devspace deploy applikationen og den tilknyttede infrastruktur i klyngen, hvorefter alt begynder at fungere i produktionsmiljøet.

Al konfiguration af projektet opbevares i filen devspace.yaml. Udover indstillinger for udviklingsmiljøet kan man også finde en beskrivelse af infrastrukturen, der ligner standard Kubernetes-manifester, kun stærkt forenklet.

Arkitektur og hovedtrin i arbejdet med DevSpace

Desuden er det let at tilføje en foruddefineret komponent (f.eks. DBMS MySQL) eller Helm-chart til projektet. Læs mere i dokumentationen — den er ikke kompliceret.

Skaffold

Webstedet; GitHub.
Kort statistik fra GH: 7423 stjerner, 4173 commits, 136 bidragsydere.
Sprog: Go.
Licens: Apache License 2.0.

Dette værktøj fra Google sigter mod at dække alle behovene hos udvikleren, hvis kode på en måde vil blive kørt i en Kubernetes-klynge. Det er ikke så nemt at begynde at bruge som devspace: der er ingen interaktivitet, sprogdetektering og automatisk oprettelse Dockerfile her vil du ikke blive tilbudt.

Når det er sagt, hvis det ikke skræmmer dig — her er, hvad Skaffold gør:

Overvåge ændringer i kildekoden.
Synkronisere den med podens container, hvis den ikke kræver bygning.
Bygge containere med koden, hvis programmeringssproget er fortolket, eller kompilere artefakter og pakke dem i containere.
De resulterende billeder testes automatisk med hjælp fra container-structure-test.
Tagge og uploade billeder til Docker Registry.
Implementere applikationen i klyngen ved hjælp af kubectl, Helm eller kustomize.
Foretage port-forwarding.
Fejlsøge applikationer skrevet i Java, Node.js, Python.

Workflow i forskellige variationer beskrives deklarativt i filen skaffold.yaml. For the project, you can also define several profiles, which can partially or completely alter the build and deployment stages. For example, for development, specify a base image that is convenient for the developer, while for staging and production — a minimal one (+ use securityContext for containers or override the cluster in which the application will be deployed).

Building Docker containers can be done locally or remotely: in Google Cloud Build or in the cluster using Kaniko. Bazel and Jib Maven/Gradle are also supported. For tagging, Skaffold supports multiple strategies: by git commit hash, date/time, sha256 checksum of the sources, etc.

It is also worth noting the ability to test containers. The previously mentioned framework container-structure-test offers the following verification methods:

Executing commands in the context of the container while tracking exit statuses and checking the command's output.
Checking the presence of files in the container and whether their attributes match specified ones.
Controlling file content by regular expressions.
Verifying image metadata (ENV, ENTRYPOINT, VOLUMES og lignende).
Checking license compatibility.

File synchronization with the container is not performed in the most optimal way: Skaffold simply creates an archive with the sources, copies it, and unpacks it in the container (tar must be installed). Therefore, if your main task is code synchronization, it is better to look for a specialized solution (ksync).

Main stages of Skaffold work

In general, the tool does not allow abstraction from Kubernetes manifests and lacks any interactivity, so it may seem complex to master. But this is also its advantage — greater freedom of action.

Garden

Webstedet; GitHub.
Brief GH statistics: 1063 stars, 1927 commits, 17 contributors.
Language: TypeScript (it is planned to split the project into several components, some of which will be in Go, and also create an SDK for building extensions in TypeScript/JavaScript and Go).
Licens: Apache License 2.0.

Like Skaffold, Garden aims to automate the process of delivering application code to the K8s cluster. To do this, you first need to describe the project structure in a YAML file, after which launch the command garden dev. It will do all the magic:

Build containers with various parts of the project.
Run integration and unit tests, if such have been described.
Deploy all project components to the cluster.
Hvis den oprindelige kode ændres, startes hele pipeline'en forfra.

Fokusset ved brug af dette værktøj ligger på samarbejdet omkring en fjernklynge af udviklerteamet. I dette tilfælde, hvis nogle faser af bygning og test allerede er udført, vil det betydeligt fremskynde hele processen, da Garden kan bruge cachelagrede resultater.

Projektmodulet kan være en beholder, et Maven-beholder, et Helm-chart, en manifest for kubectl apply eller endda en OpenFaaS-funktion. Og enhver af modulerne kan hentes fra et eksternt Git-repositorium. Et modul kan definere (eller ikke definere) tjenester, opgaver og tests. Tjenester og opgaver kan have afhængigheder, hvilket gør det muligt at definere rækkefølgen af deployment af en given tjeneste samt organisere udførelsen af opgaver og tests.

Garden giver brugeren et flot dashboard (stadig i eksperimentel tilstand), hvor projektets grafik vises: komponenter, rækkefølge af bygning, udførelse af opgaver og tests, deres relationer og afhængigheder. Direkte i browseren kan man også se loggene fra alle projektets komponenter og kontrollere, hvad en given komponent returnerer over HTTP (hvis der selvfølgelig er erklæret en ingress-ressource til den).

Panelet for Garden

Dette værktøj tilbyder også en hot-reload-funktion, der blot synkroniserer ændringer i scripts med beholderen i klyngen, hvilket markant fremskynder debuggingprocessen for applikationen. Garden har et godt dokumentation og et anstændigt udvalg af eksempler, som gør det muligt hurtigt at komme i gang og begynde at bruge det. Ved øvrigt har vi for nylig offentliggjort oversættelsen af artiklen fra dens forfattere.

Konklusion

Selvfølgelig er denne liste over værktøjer ikke udtømmende for udvikling og debugging af applikationer i Kubernetes. Der findes mange andre nyttige og praktiske værktøjer, der fortjener, hvis ikke en separat artikel, så i det mindste en omtale. Fortæl om hvad du bruger, hvilke problemer du har stødt på, og hvordan du har løst dem!