🥇Fejlesztői eszközök alkalmazásokhoz, amelyeket Kubernetes-ben futtatnak

A modern approach to operations addresses many pressing business problems. Containers and orchestrators allow for easy scaling of projects of any complexity, simplify the release of new versions, and make them more reliable, but at the same time create additional problems for developers. A programmer is primarily concerned with their code: architecture, quality, performance, elegance—rather than how it will run in Kubernetes and how to test and debug it after even minor changes. Therefore, it is quite natural that tools for Kubernetes are actively developing, helping to solve the problems of even the most 'archaic' developers and allowing them to focus on what matters.

This review provides a brief overview of some tools that simplify life for programmers whose code runs in the pods of a Kubernetes cluster.

Simple Helpers

Kubectl-debug

Essence: add your container to the Pod and see what is happening in it.
GitHub.
Brief GH statistics: 715 stars, 54 commits, 9 contributors.
Language: Go.
License: Apache License 2.0.

This kubectl plugin allows you to create an additional container inside your interested pod that will share the namespace with the other containers. You can debug the pod's operation in it: check network performance, listen to network traffic, perform an strace on the process of interest, etc.

You can also switch into the process container by executing chroot /proc/PID/root — this is very convenient when you need to get a root shell in a container for which the manifest specifies securityContext.runAs.

The tool is simple and effective, so it may be useful for every developer. We wrote more about it in külön cikkben.

Telepresence

Essence: move the application to your computer. Develop and debug locally.
Weboldal; GitHub.
Brief GH statistics: 2131 stars, 2712 commits, 33 contributors.
Language: Python.
License: Apache License 2.0.

The idea of this tool is to run a container with an application on a local user computer and proxy all traffic from the cluster to it and back. This approach allows for local development, simply by changing files in your favorite IDE: results will be available immediately.

A helyi indítás előnyei – a módosítások kényelme és az azonnali eredmény, valamint a szokásos módon történő hibakeresés lehetősége. Hátrányai közé tartozik a kapcsolat sebességére vonatkozó igényessége, amely különösen észlelhető, amikor egy viszonylag magas RPS-sel és forgalommal rendelkező alkalmazással kell dolgozni. Ezenkívül a Telepresence-nak problémái vannak a volume mounts-szal Windows rendszeren, ami döntő korlátot jelenthet azok számára, akik ehhez az operációs rendszerhez vannak szokva.

Már megosztottuk tapasztalatainkat a Telepresence használatával kapcsolatban itt.

Ksync

Essence: majdnem azonnali kód szinkronizálás a klaszterben lévő konténerrel.
GitHub.
Rövid GH statisztika: 555 csillag, 362 commit, 11 hozzájáruló.
Language: Go.
License: Apache License 2.0.

A segédprogram lehetővé teszi a helyi könyvtár tartalmának szinkronizálását a klaszterben futó konténer könyvtárával. Ez az eszköz kiválóan alkalmas a szkriptnyelvű programozók számára, akiknek fő problémájuk a kód működő konténerbe juttatása. A Ksync célja ennek a fejfájásnak a megszüntetése.

Egy egyszeri inicializálással a ksync init parancs létrehoz egy DaemonSet-et a klaszterben, amely a kiválasztott konténer fájlrendszerének állapotát nyomon követi. A fejlesztő a saját helyi számítógépén elindítja a parancsot ksync watch, amely figyeli a konfigurációkat, és elindítja a syncthing, amely közvetlen fájlszinkronizálást végez a klaszterrel.

Csak utasítani kell a ksync-et, hogy mit és kivel szinkronizáljon. Például, a következő parancs:

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

… létrehoz egy watchert, amelynek neve myproject, és amely a "app=backend" címkét tartalmazó pod-ot keresi, és megpróbálja szinkronizálni a helyi könyvtárat a konténer könyvtárával. /home/user/myproject/ Problémák és megjegyzések a ksync-ről tapasztalataink szerint: /var/www/myproject/ A Kubernetes klaszter csomópontjainak az php.

overlay2

tárolómeghajtót kell használnia a Dockerhez. Más eszközökkel nem fog működni. Windows operációs rendszer használata esetén előfordulhat, hogy a fájlrendszer watchere nem működik megfelelően. Ezt a hibát észleltük nagy könyvtárakban – sok beágyazott fájllal és könyvtárral. Létrehoztunk egy megfelelő hibajegyet
a syncthing projektben, de eddig (július kezdete óta) nincs előrelépés. Használja a fájlt .stignore
Используйте файл .stignore a fájlok szinkronizálására nem szükséges könyvtárak vagy fájlsablonok megadásához app/cache és .git).
Alapértelmezés szerint a ksync minden fájlváltozáskor újraindítja a konténert. Ez hasznos a Node.js esetében, de PHP esetén teljesen felesleges. Jobb letiltani az opcache-t és használni a flaget --reload=false.
A konfiguráció mindig javítható a $HOME/.ksync/ksync.yaml.

Squash

Essence: hibakeresést végezzen közvetlenül a klaszteren.
GitHub.
Rövid statisztika a GitHubon: 1154 csillag, 279 commit, 23 hozzájáruló.
Language: Go.
License: Apache License 2.0.

Ez az eszköz a folyamatok hibakeresésére szolgál közvetlenül a pod-okban. Az eszköz egyszerű, és interaktív módban lehetővé teszi a megfelelő hibakereső kiválasztását (see below) és a névtér + pod, amelybe be kell avatkozni. Jelenleg az alábbiak támogatottak:

delve — Go alkalmazásokhoz;
GDB — távoli célon + port továbbítás;
JDWP porttovábbítás Java-alkalmazások hibakereséséhez.

IDE oldalról a támogatás csak a VScode-ban érhető el (a segítségével kiterjesztés), azonban a jelenlegi (2019) év tervei között szerepel az Eclipse és az Intellij is.

A Squash a klaszter csomópontjain privilegizált konténert indít a folyamatok hibakeresésére, ezért először is meg kell ismerni a biztonsági mód lehetőségeit a biztonsági problémák elkerülése érdekében.

Komplex megoldások

Térjünk át a nehéz tüzérségre — a módszerekre, amelyek azonnal több fejlesztői igényt ki tudnak szolgálni.

NB: Ebben a listában természetesen helyet kap az Open Source eszközünk werf (korábban dapp néven ismert). Azonban már többször írtunk és beszéltünk róla, ezért úgy döntöttünk, hogy nem tesszük bele az áttekintésbe. Azok számára, akik közelebbről meg szeretnék ismerni a lehetőségeit, ajánljuk a "werf — a Kubernetes CI/CD eszközünk».

DevSpace

Essence: számára, akik kezdeni szeretnének a Kubernetes használatával, de nem akarnak mélyen belemerülni a részletekbe.
GitHub.
Rövid statisztika a GitHubon: 630 csillag, 1912 commit, 13 hozzájáruló.
Language: Go.
License: Apache License 2.0.

Megoldás azonos nevű cégtől, amely kezelt klasztereket kínál Kubernetes alatt csapatfejlesztéshez. Az eszközt kereskedelmi klaszterekhez hozták létre, de bármilyen más klaszteren is jól működik.

A parancs futtatásakor devspace init a projekt könyvtárában interaktív módban felajánlják a lehetőségeket:

kiválasztani a működő Kubernetes klasztert,
használni a meglévőt Dockerfile (vagy generálni egy újat) a konténer létrehozásához ezen a bázison,
kiválasztani a tartható konténerképek tárolóját stb.

Miután elvégeztük az összes előkészítő lépést, elkezdhetjük a fejlesztést, végrehajtva a parancsot devspace dev. Ez összegyűjti a konténert, feltölti azt a tárolóba, kiadja a telepítést a klaszterben, és elindítja a portok átirányítását és a konténer szinkronizálását a helyi mappával.

Opcionálisan javasolják, hogy a terminálban lépjünk be a konténerbe. Erről nem érdemes lemondani, mivel a konténer valójában a sleep parancssal indul, és az alkalmazás valós teszteléséhez kézzel kell elindítani.

Végül a parancs devspace deploy kibocsátja az alkalmazást és a hozzá kapcsolódó infrastruktúrát a klaszterben, ezután minden működni kezd éles módban.

A projekt összes konfigurációja a fájlban található devspace.yaml. Az fejlesztési környezet beállításain kívül itt található az infrastruktúra leírása, amely hasonlít a standard Kubernetes-manifesztumokhoz, de jelentősen egyszerűsített.

A DevSpace architektúrája és fő munkafázisai

Ezen kívül a projektbe könnyen hozzáadható egy előre definiált komponens (például MySQL adatbázis) vagy Helm-chart. További részletekért olvassa el a dokumentáció — nem nehéz.

Skaffold

Weboldal; GitHub.
Rövid GH statisztika: 7423 csillag, 4173 elkötelezett, 136 hozzájáruló.
Language: Go.
License: Apache License 2.0.

Ez a Google eszköze azt hivatott megoldani, hogy lefedje az összes fejlesztői szükségletet, akinek a kódja valamilyen módon a Kubernetes klaszterben fut majd. Kezdetben nem olyan egyszerű használni, mint a devspace-t: itt nincs interaktivitás, nyelvmeghatározás és automatikus létrehozás Dockerfile itt nem fognak ajánlani.

Ha azonban ez nem riaszt el — nézzük meg, mit tud csinálni a Skaffold:

Figyeli a forráskód változásait.
Szinkronizálja azt a pod konténerével, ha nem igényel fordítást.
Összegyűjt elkészített konténereket a kóddal, ha a programozási nyelv értelmezett, vagy pedig lefordítja az artefaktumokat, és betölti azokat a konténerekbe.
A létrejövő képeket automatikusan ellenőrzi a container-structure-test.
Címkézi és feltölti a képeket a Docker Registry-be.
Telepíti az alkalmazást a klaszterben, használva a kubectl-t, Helm-et vagy kustomize-t.
Portokat irányít át.
Hibaelhárítást végez a Java, Node.js, Python alkalmazásokkal.

A munkafolyamat különböző változatai deklaratív módon a fájlban vannak leírva skaffold.yamlA projekt esetében több profilt is meghatározhatunk, amelyekben részben vagy teljesen megváltoztathatjuk a build és a deploy szakaszokat. Például a fejlesztéshez kényelmes alapképet adhatunk meg, míg staging és production esetén minimálisat (+ használni a a konténernek van egy paramétere konténerek vagy átdefiniálni a klasztert, ahol az alkalmazás telepítve lesz).

A Docker-konténerek építése helyben vagy távolról végezhető: a Google Cloud Build vagy klaszterben a Kaniko. A Bazel és Jib Maven/Gradle is támogatott. A Skaffold számos stratégiát támogat a címkézéshez: git commit hash, dátum/idő, sha256 források összege stb.

Külön érdemes megemlíteni a konténerek tesztelésének lehetőségét. A már említett container-structure-test keretrendszer a következő ellenőrzési módszereket kínálja:

Parancsok végrehajtása a konténer kontextusában az exit státuszok nyomon követésével és a parancs szöveges 'kimenetének' ellenőrzésével.
Fájlok ellenőrzése a konténerben és az attribútumok megfelelősége a megadottaknak.
Fájlok tartalmának ellenőrzése reguláris kifejezésekkel.
Kép metadatainak összehasonlítása (ENV, ENTRYPOINT, VOLUMES stb.).
Licencmegjelenítések ellenőrzése.

A fájlok szinkronizálása a konténerrel nem a legoptimálisabb módon történik: a Skaffold egyszerűen archívumot készít a forrásokból, átmásolja és kicsomagolja a konténerben (a tar telepítése szükséges). Ezért, ha az elsődleges feladatod a kód szinkronizálása, érdemes egy speciális megoldást (ksync) keresni.

A Skaffold fő munkafázisai

Összességében az eszköz nem engedi meg elvonatkoztatni a Kubernetes-manifesztumoktól, és nincs semmilyen interaktivitása, így elsőre nehéznek tűnhet a tanulása. De ebben rejlik az előnye is — a nagyobb szabadság a cselekvésben.

Garden

Weboldal; GitHub.
Rövid GH statisztika: 1063 csillag, 1927 commit, 17 hozzájáruló.
Nyelv: TypeScript (tervezett, hogy a projektet több komponensre bontják, melyek közül egyesek Go-n lesznek, és SDK-t készítenek kiegészítők létrehozására TypeScript/JavaScript és Go nyelveken).
License: Apache License 2.0.

A Garden, akárcsak a Skaffold, a kódok alkalmazásának K8s klaszterbe történő szállításának automatizálására összpontosít. Ennek érdekében először a projekt struktúráját YAML fájlban kell meghatározni, majd indítani kell a garden dev. Ez elvégzi az összes varázslatot:

Összegyűjti a konténereket a projekt különböző részeivel.
Elvégzi az integrációs és unit teszteket, ha ilyet leírtak.
Kibocsátja a projekt összes komponensét a klaszterbe.
A forráskód módosítása esetén újraindítja az egész pipelinet.

Ez az eszköz a távoli klaszter közös használatára összpontosít a fejlesztőcsapat által. Ebben az esetben, ha bizonyos összeállítási és tesztelési szakaszok már megtörténtek, az jelentősen felgyorsítja az egész folyamatot, mivel a Garden képes használni a gyorsítótárazott eredményeket.

A projekt modulja lehet egy tároló, Maven tároló, Helm chart, manifest a kubectl apply vagy akár OpenFaaS funkció. Ráadásul bármelyik modult lehúzhatjuk egy távoli Git-tárhelyről. A modul lehet, hogy definiál szolgáltatásokat, feladatokat és teszteket (vagy nem). A szolgáltatások és feladatok függőségeket tartalmazhatnak, így meghatározható a bizonyos szolgáltatás telepítési sorrendje, a feladatok és tesztek indításának ütemezése.

A Garden egy szép műszerfalat biztosít a felhasználónak (jelenleg kísérleti állapotban), amelyen a projekt grafikonja látható: a komponensek, az összeállítási sorrend, a feladatok és tesztek végrehajtása, valamint azok kapcsolatai és függőségeik. Közvetlenül a böngészőben megnézhető a projekt összes komponensének naplója, ellenőrizhető, hogy mit ad ki egy bizonyos komponens HTTP-n (ha persze erről be van jelentve egy ingress forrás).

Garden műszerfal

Az eszköz rendelkezik hot-reload móddal is, amely egyszerűen szinkronizálja a szkriptmódosításokat a klaszterben lévő tárolóval, jelentősen felgyorsítva az alkalmazás hibakeresési folyamatát. A Garden jó dokumentáció és nem rossz példák készletét biztosítja,amelyek lehetővé teszik a gyors tanulást és a használat megkezdését. Egyébként nemrégiben közzétettük cikkfordítását a szerzőitől.

Zárás

Természetesen ez a lista nem korlátozza a Kubernetes alkalmazások fejlesztésére és hibakeresésére szolgáló eszközöket. Sok más hasznos és praktikus segédprogram létezik, amelyek megérdemlik, hogy legalább megemlítsük őket. Mesélj el, milyen eszközöket használsz, milyen problémákkal találkoztál, és hogyan oldottad meg őket!