🥇Tools voor ontwikkelaars van applicaties die in Kubernetes draaien

Een moderne aanpak van exploitatie lost veel dringende zakelijke problemen op. Containers en orkestratoren maken het gemakkelijk om projecten van elke complexiteit op te schalen, vereenvoudigen de release van nieuwe versies en maken deze betrouwbaarder, maar creëren tegelijkertijd ook extra problemen voor ontwikkelaars. Een programmeur maakt zich in de eerste plaats zorgen over zijn code: architectuur, kwaliteit, prestaties, elegantie - en niet hoe het in Kubernetes draait en hoe het getest en gedebugd moet worden na zelfs de kleinste wijzigingen. Daarom is het volkomen logisch dat er steeds meer tools voor Kubernetes worden ontwikkeld die helpen de problemen van zelfs de meest "archaïsche" ontwikkelaars op te lossen, zodat zij zich op het belangrijkste kunnen concentreren.

In deze review vind je beknopte informatie over enkele tools die het leven van programmeurs eenvoudiger maken, wiens code draait in de pods van een Kubernetes-cluster.

Eenvoudige helpers

Kubectl-debug

Essentie: voeg je container toe aan de Pod en kijk wat erin gebeurt.
GitHub.
Korte statistieken GH: 715 sterren, 54 commits, 9 bijdragers.
Programmeertaal: Go.
Licentie: Apache License 2.0.

Deze plugin voor kubectl laat je een extra container binnen de gewenste pod creëren, die de procesnamespace met de andere containers deelt. Hierin kan je de werking van de pod debuggen: netwerktests uitvoeren, netwerkverkeer beluisteren, een strace van een interessant proces maken, enzovoort.

Je kunt ook overschakelen naar de procescontainer met chroot /proc/PID/root — dit is erg handig als je een root shell in de container nodig hebt, waarvoor in het manifest is ingesteld securityContext.runAs.

De tool is eenvoudig en effectief, zodat elk ontwikkelaar het kan gebruiken. Meer hierover hebben we geschreven in een apart artikel.

Telepresence

Essentie: verplaats de applicatie naar je computer. Ontwikkel en debug lokaal.
Website; GitHub.
Korte statistieken GH: 2131 sterren, 2712 commits, 33 bijdragers.
Programmeertaal: Python.
Licentie: Apache License 2.0.

Het idee van deze tool is om een container met de applicatie op de lokale gebruikerscomputer te starten en al het verkeer van de cluster naar deze container en terug te proxyen. Deze aanpak maakt lokaal ontwikkelen mogelijk, simpelweg door bestanden in je favoriete IDE te wijzigen: de resultaten zijn onmiddellijk beschikbaar.

Voordelen van lokale uitvoering zijn het gemak van aanpassingen en directe resultaten, evenals de mogelijkheid om de applicatie op de gebruikelijke manier te debuggen. Nadelen zijn de vereisten aan snelheid van de verbinding, wat vooral merkbaar is wanneer je werkt met een applicatie met aanzienlijke RPS en verkeer. Bovendien heeft Telepresence problemen met volume-mounts in Windows, wat een beperkende factor kan zijn voor ontwikkelaars die aan dit OS gewend zijn.

We hebben al onze ervaringen met Telepresence gedeeld. hier.

Ksync

Essentie: bijna onmiddellijke synchronisatie van code met de container in het cluster..
GitHub.
Korte statistieken van GH: 555 sterren, 362 commits, 11 bijdragers.
Programmeertaal: Go.
Licentie: Apache License 2.0.

De tool maakt het mogelijk om de inhoud van een lokale directory te synchroniseren met de map van een container die in het cluster draait. Dit soort gereedschap is uitstekend geschikt voor ontwikkelaars van scriptingtalen, voor wie het grootste probleem is om code in een werkende container te krijgen. Ksync is ontworpen om deze hoofdpijn te verlichten.

Bij een eenmalige initialisatie met het commando ksync init wordt er in het cluster een DaemonSet aangemaakt, dat gebruikt wordt om de status van het bestandssysteem van de geselecteerde container te volgen. Op zijn lokale computer voert de ontwikkelaar het commando uit ksync watch, dat de configuraties in de gaten houdt en syncthing, dat de directe synchronisatie van bestanden met het cluster uitvoert.

Het blijft over om ksync instructies te geven over wat met wat gesynchroniseerd moet worden. Bijvoorbeeld, zo'n commando:

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

… creëert een watcher met de naam myproject, die zal zoeken naar een pod met het label app=backend en probeert de lokale directory /home/user/myproject/ met de map /var/www/myproject/ van de container met de naam php.

Problemen en opmerkingen over ksync uit onze ervaring:

Op de knooppunten van het Kubernetes-cluster moet overlay2 worden gebruikt als opslagdriver voor Docker. Geen enkele andere tool zal werken.
Bij gebruik van Windows als client-OS kan de watcher van het bestandssysteem onjuist functioneren. Deze bug is opgemerkt bij het werken met grote mappen — met veel geneste bestanden en directories. We hebben een vergelijkbaar issue gemaakt in het syncthing-project, maar er is tot nu toe (sinds begin juli) geen voortgang geboekt.
Gebruik het bestand .stignore om paden of bestandsjablonen aan te geven die niet gesynchroniseerd hoeven te worden (bijvoorbeeld mappen app/cache en .git).
Standaard zal ksync de container opnieuw opstarten bij elke wijziging van bestanden. Dit is handig voor Node.js, maar volkomen overbodig voor PHP. Het is beter om opcache uit te schakelen en de vlag --reload=false.
De configuratie kan altijd worden aangepast in $HOME/.ksync/ksync.yaml.

Squash

Essentie: debug je processen direct in de cluster.
GitHub.
Korte GH-statistieken: 1154 sterren, 279 commits, 23 bijdragers.
Programmeertaal: Go.
Licentie: Apache License 2.0.

Deze tool is bedoeld voor het debuggen van processen rechtstreeks in pods. Het hulpprogramma is eenvoudig en stelt je in staat om de gewenste debugger in interactieve modus te kiezen (zie hieronder) en namespace + pod waarin je wilt ingrijpen. Momenteel worden de volgende ondersteund:

delve - voor Go-applicaties;
GDB - via target remote + poortdoorverwijzing;
poorten doorverwijzen voor JDWP voor het debuggen van Java-applicaties.

Vanuit de IDE is er ondersteuning alleen in VScode (met behulp van de extensie), maar voor het lopende (2019) jaar zijn Eclipse en Intellij in planning.

Voor het debuggen van processen start Squash een geprivilegieerde container op de knooppunten van de cluster, dus het is noodzakelijk om eerst kennis te nemen van de mogelijkheden van de veilige modus om veiligheidsproblemen te voorkomen.

Geavanceerde oplossingen

We gaan over op de zware artillerie - meer 'schalbare' projecten die zijn ontworpen om in één keer veel behoeften van ontwikkelaars te dekken.

NB: In deze lijst is er ongetwijfeld ook plaats voor onze Open Source-tool werf (vroeger bekend als dapp). We hebben al vaak over haar geschreven en verteld, daarom hebben we besloten om deze niet in de review op te nemen. Voor diegenen die haar mogelijkheden beter willen leren kennen, raden we aan de presentatie 'werf - onze tool voor CI/CD in Kubernetes».

DevSpace

Essentie: voor degenen die willen beginnen met werken in Kubernetes, maar niet diep wil graven in de details.
GitHub.
Korte GH-statistieken: 630 sterren, 1912 commits, 13 bijdragers.
Programmeertaal: Go.
Licentie: Apache License 2.0.

Oplossing van het gelijknamige bedrijf dat beheerde clusters met Kubernetes aanbiedt voor teamontwikkeling. Het hulpprogramma is gemaakt voor commerciële clusters, maar werkt ook uitstekend met andere.

Bij het uitvoeren van het commando devspace init in de directory met het project wordt je gevraagd (in interactieve modus):

je werk Kubernetes-cluster te kiezen,
gebruik de bestaande Dockerfile (of genereer een nieuwe) om een container op te bouwen.
selecteer de repository voor het opslaan van container images, enz.

Na alle voorbereidende stappen kan de ontwikkeling beginnen door het uitvoeren van het commando devspace dev. Dit zal de container bouwen, deze naar de repository uploaden, de deployment naar het cluster uitrollen en de poortforwarding en synchronisatie van de container met de lokale map starten.

Optioneel zal het aangeboden worden om via de terminal in de container te gaan. Dit zou je niet moeten vermijden, want in werkelijkheid start de container met het commando sleep, en voor echte tests moet de applicatie handmatig worden gestart.

Ten slotte rolt het commando devspace deploy de applicatie en de daarbij behorende infrastructuur uit naar het cluster, waarna alles in de productie modus begint te functioneren.

De hele projectconfiguratie wordt opgeslagen in het bestand devspace.yaml. Naast de omgevingsinstellingen voor ontwikkeling kan hierin ook een beschrijving van de infrastructuur worden gevonden, die lijkt op de standaard Kubernetes-manifesten, maar veel eenvoudiger is.

De architectuur en de belangrijkste stappen voor het werken met DevSpace

Bovendien is het gemakkelijk om een vooraf gedefinieerd component (bijvoorbeeld een MySQL-database) of een Helm-chart aan het project toe te voegen. Meer hierover lees je in de documentatie — het is niet moeilijk.

Skaffold

Website; GitHub.
Korte statistieken van GH: 7423 sterren, 4173 commits, 136 bijdragers.
Programmeertaal: Go.
Licentie: Apache License 2.0.

Dit hulpprogramma van Google claimt alle behoeften van een ontwikkelaar te dekken wiens code op de een of andere manier in een Kubernetes-cluster zal draaien. Beginnen hierin is niet zo eenvoudig als met devspace: er is geen interactie, taaldefinitie en autogeneratie Dockerfile hier wordt je niet aangeboden.

Maar als dit je niet afschrikt, hier is wat Skaffold kan doen:

Wijs veranderingen in de broncode aan.
Synchroniseer deze met de pod-container, als er geen build nodig is.
Bouw containers met de code, als de programmeertaal interpretatief is, of compileer artefacten en verpakt deze in containers.
De resulterende beelden automatisch controleren met behulp van container-structure-test.
Label en upload beelden naar de Docker Registry.
Rol de applicatie uit naar het cluster met behulp van kubectl, Helm of kustomize.
Voer poortforwarding uit.
Foutopsporing van applicaties geschreven in Java, Node.js, Python.

Workflow in verschillende variaties wordt declaratief beschreven in het bestand skaffold.yaml. Voor het project kunnen ook meerdere profielen worden gedefinieerd, waarin de build- en deploymentstappen gedeeltelijk of volledig kunnen worden veranderd. Bijvoorbeeld, voor ontwikkeling een handige basisafbeelding voor de ontwikkelaar opgeven, en voor staging en productie de minimumversie (+ gebruik securityContext in containers or redefine the cluster in which the application will be deployed).

Docker container builds can take place 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 various strategies: by git commit hash, date/time, sha256 checksum of the sources, etc.

It is also worth mentioning 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 textual output.
Checking for the presence of files in the container and their attributes against specified ones.
Checking the contents of files using regular expressions.
Comparing image metadata (ENV, ENTRYPOINT, VOLUMES etc.).
Checking license compatibility.

Synchronizing files with the container is done in a suboptimal 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's better to look towards specialized solutions (ksync).

Main stages of Skaffold's operation

Overall, the tool does not allow abstraction from Kubernetes manifests and lacks any interactivity, which may make it seem complex to learn. But this is also its advantage — greater freedom of action.

Garden

Website; GitHub.
Brief GH statistics: 1063 stars, 1927 commits, 17 contributors.
Language: TypeScript (there are plans to split the project into several components, some of which will be in Go, and also create an SDK for building plugins in TypeScript/JavaScript and Go).
Licentie: Apache License 2.0.

Like Skaffold, Garden aims to automate the processes 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 you run the command garden dev. It will do all the magic:

Build containers with various parts of the project.
Run integration and unit tests, if they have been described.
Deploy all components of the project to the cluster.
In case of changes in the source code — it will restart the entire pipeline.

De focus bij het gebruik van dit hulpmiddel ligt op de samenwerking binnen een externe cluster door een team van ontwikkelaars. In dit geval, als bepaalde fasen van de bouw en testen al zijn uitgevoerd, versnelt dit het hele proces aanzienlijk, aangezien Garden gebruik kan maken van gecachte resultaten.

Een module van het project kan een container, Maven-container, Helm-chart of manifest zijn voor kubectl apply of zelfs een OpenFaaS-functie. Elke module kan vanuit een externe Git-repository worden opgehaald. Een module kan (maar hoeft niet) services, taken en tests definiëren. Services en taken kunnen afhankelijkheden hebben, waardoor de volgorde van het deployen van een bepaalde service kan worden bepaald, evenals de volgorde van het uitvoeren van taken en tests.

Garden biedt de gebruiker een mooi dashboard (momenteel in experimentale staat), waar het projectdiagram wordt weergegeven: componenten, volgorde van bouwen, uitvoeren van taken en tests, hun verbindingen en afhankelijkheden. In de browser kunnen ook de logs van alle projectcomponenten worden bekeken en kan worden gecontroleerd wat elke component via HTTP uitlevert (tenzij er natuurlijk een ingress-resource voor is gedeclareerd).

Het paneel voor Garden

Dit hulpmiddel heeft ook een hot-reload-modus, die eenvoudig de wijzigingen in scripts synchroniseert met de container in de cluster, waardoor het debuggen van de applicatie aanzienlijk wordt versneld. Garden heeft een goed documentatie en redelijk voorbeeldpakket, dat helpt om snel vertrouwd te raken en aan de slag te gaan. Trouwens, we hebben onlangs een vertaling van een artikel van de auteurs gepubliceerd.

Conclusie

Natuurlijk beperkt deze lijst met tools voor het ontwikkelen en debuggen van applicaties in Kubernetes zich niet. Er zijn nog veel andere zeer nuttige en praktische hulpmiddelen die het vermelden waard zijn, zelfs als ze niet in een apart artikel worden behandeld. Vertel ons met welke tools jij werkt, tegen welke problemen je bent aangelopen en hoe je deze hebt opgelost!

Tools voor ontwikkelaars van applicaties die in Kubernetes draaien