🥇Instrumente pentru dezvoltatorii de aplicații rulate în Kubernetes

Abordarea modernă a operării rezolvă multe probleme urgente ale afacerii. Containerele și orchestratorii permit scalarea ușoară a proiectelor de orice complexitate, simplifică lansările de versiuni noi, le fac mai fiabile, dar în același timp generează probleme suplimentare pentru dezvoltatori. Programatorul, în primul rând, se îngrijorează de codul său: arhitectura, calitatea, performanța, eleganța - și nu de modul în care se va deschide în Kubernetes și cum va fi testat și depanat după efectuarea chiar și a celor mai minime modificări. De aceea, este cât se poate de natural că se dezvoltă activ instrumente pentru Kubernetes care ajută la rezolvarea problemelor chiar și pentru cei mai „arcaici” dezvoltatori, permițându-le să se concentreze pe esențial.

Această recenzie oferă informații scurte despre unele instrumente care simplifică viața programatorului, al cărui cod rulează în pod-urile unui cluster Kubernetes.

Asistenți simpli

Kubectl-debug

Esenta: adaugă-ți containerul în Pod și vezi ce se întâmplă în el.
GitHub.
Statistici scurte GH: 715 stele, 54 commit-uri, 9 contribuabili.
Limbaj: Go.
Licență: Apache License 2.0.

Acest plugin pentru kubectl permite crearea unui container suplimentar în interiorul pod-ului de interes, care va împărtăși spațiul numelui proceselor cu celelalte containere. În acesta, poți depana funcționarea pod-ului: verifica rețeaua, asculta traficul de rețea, face strace pe procesul de interes etc.

De asemenea, poți comuta în containerul procesului executând chroot /proc/PID/root - aceasta este foarte convenabil atunci când trebuie să obții un shell root în containerul pentru care a fost setat în manifest securityContext.runAs.

Instrumentul este simplu și eficient, astfel încât poate fi util pentru fiecare dezvoltator. Mai multe detalii despre el am scris în un articol separat.

Telepresence

Esenta: mută aplicația pe computerul tău. Dezvoltă și depanează local.
Site; GitHub.
Statistici scurte GH: 2131 stea, 2712 commit-uri, 33 contribuabili.
Limbaj: Python.
Licență: Apache License 2.0.

Ideea acestui instrument constă în a rula un container cu aplicația pe computerul local al utilizatorului și a proxy-iza tot traficul din cluster înapoi și înapoi. Această abordare permite dezvoltarea locală, pur și simplu modificând fișierele în IDE-ul tău preferat: rezultatele vor fi disponibile imediat.

Avantajele lansării locale sunt comoditatea modificărilor și rezultatul imediat, precum și posibilitatea de a debuga aplicația într-un mod obișnuit. Dezavantajele includ cerințele de viteză de conexiune, ceea ce devine evident mai ales când trebuie să lucrăm cu o aplicație cu un RPS și trafic destul de ridicat. În plus, Telepresence are probleme cu volume mounts în Windows, ceea ce poate fi o limitare decisivă pentru dezvoltatori obișnuiți cu acest sistem de operare.

Deja am împărtășit experiența noastră cu Telepresence aici.

Ksync

Esenta: sincronizare aproape instantanee a codului cu containerul din cluster.
GitHub.
Statistici scurte GH: 555 stele, 362 comituri, 11 contributori.
Limbaj: Go.
Licență: Apache License 2.0.

Utilitarul permite sincronizarea conținutului unui director local cu un catalog al containerului care rulează în cluster. Un astfel de instrument este excelent pentru dezvoltatorii de limbaje de programare scriptate, ale căror probleme principale sunt livrarea codului în containerul funcțional. Ksync este destinat să elimine această durere de cap.

Prin inițializarea unică cu comanda ksync init în cluster este creat un DaemonSet, care este folosit pentru a urmări starea sistemului de fișiere al containerului selectat. Pe computerul său local, dezvoltatorul rulează comanda ksync watch, care urmărește configurațiile și lansează syncthing, care efectuează sincronizarea directă a fișierelor cu clusterul.

Rămâne să-i instructăm pe ksync ce și cu ce să sincronizeze. De exemplu, o astfel de comandă:

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

… va crea un watcher numit myproject, care va căuta podul cu eticheta app=backend și va încerca să sincronizeze directorul local /home/user/myproject/ cu catalogul /var/www/myproject/ al containerului numit php.

Probleme și observații referitoare la ksync din experiența noastră:

Pe nodurile clusterului Kubernetes trebuie folosit overlay2 ca driver de stocare pentru Docker. Nu va funcționa cu alte utilitare.
Când folosiți Windows ca sistem de operare client, poate apărea o funcționare incorectă a watcher-ului sistemului de fișiere. Acest bug a fost observat la lucrul cu directoare mari — cu un număr mare de fișiere și directoare înnodat. Am creat un issue corespunzător în proiectul syncthing, dar nu există progrese pe acest subiect (de la începutul lui iulie).
Folosiți fișierul .stignore pentru a specifica căile sau șabloanele de fișiere care nu trebuie sincronizate (de exemplu, directoare app/cache și .git).
În mod implicit, ksync va reîncărca containerele la fiecare modificare a fișierelor. Pentru Node.js este convenabil, iar pentru PHP este complet inutil. Cel mai bine este să dezactivați opcache și să folosiți flagul --reload=false.
Configurarea poate fi întotdeauna corectată în $HOME/.ksync/ksync.yaml.

Squash

Esenta: debușează procese direct în cluster.
GitHub.
Statistici sumare GH: 1154 stele, 279 de comitete, 23 de contribuabili.
Limbaj: Go.
Licență: Apache License 2.0.

Acest instrument este destinat debușării proceselor direct în pod-uri. Utilitarul este simplu și în modul interactiv permite alegerea debugger-ului dorit (vezi mai jos) și namespace + pod, în procesul căruia trebuie să interveniți. În prezent, sunt acceptate:

delve — pentru aplicații pe Go;
GDB — prin target remote + redirecționare de port;
redirecționarea portului JDWP pentru debușarea aplicațiilor Java.

Din partea IDE, suportul există doar în VScode (cu ajutorul extensii), totuși în planurile pentru acest an (2019) se află și Eclipse și Intellij.

Pentru debușarea proceselor, Squash pornește un container privilegiat pe nodurile clusterului, așa că este necesar să te familiarizezi mai întâi cu posibilitățile modului de siguranță pentru a evita problemele de securitate.

Soluții complexe

Trecem la artileria grea — la proiecte mai „scalabile”, menite să răspundă direct la multe dintre nevoile dezvoltatorilor.

NB: În această listă, cu siguranță este loc și pentru utilitarul nostru Open Source werf (cunoscut anterior ca dapp). Însă am scris deja de mai multe ori despre el și am decis să nu-l includem în revizuire. Pentru cei care doresc să se familiarizeze mai bine cu capacitățile sale, recomandăm citirea/ascultarea prezentării „werf — instrumentul nostru pentru CI/CD în Kubernetes».

DevSpace

Esenta: pentru cei care doresc să înceapă lucrul cu Kubernetes, dar nu doresc să se adâncească profund în hățișurile sale.
GitHub.
Statistici sumare GH: 630 stele, 1912 de comitete, 13 contribuabili.
Limbaj: Go.
Licență: Apache License 2.0.

Soluția de la compania omonimă, care oferă clustere manage pe Kubernetes pentru dezvoltare în echipă. Utilitarul a fost creat pentru clustere comerciale, dar funcționează excelent și cu orice altele.

Când rulați comanda devspace init în directorul proiectului, vă va solicita (în mod interactiv):

să alegeți clusterul Kubernetes de lucru,
să folosiți unul existent Dockerfile (sau să generați unul nou) pentru a crea un container pe baza acestuia,
să alegeți un depozit pentru stocarea imaginilor containerelor etc.

După toate aceste pregătiri, se poate începe dezvoltarea, executând comanda devspace dev. Aceasta va construi containerul, îl va încărca în repo, va implementa deployment-ul în cluster și va porni redirecționarea porturilor și sincronizarea containerului cu directorul local.

Opțional, vi se va sugera să intrați în container prin terminal. Nu ar trebui să refuzați, deoarece în realitate containerul pornește cu comanda sleep, iar pentru a testa aplicația în mod real, trebuie să o porniți manual.

În cele din urmă, comanda devspace deploy implementează aplicația și infrastructura asociată în cluster, după care totul începe să funcționeze în modul de producție.

Toată configurația proiectului este stocată în fișierul devspace.yaml. Pe lângă setările de mediu pentru dezvoltare, în acesta se poate găsi și descrierea infrastructurii, similară cu manifestele standard Kubernetes, doar că foarte simplificate.

Arhitectura și principalele etape de lucru cu DevSpace

În plus, în proiect este ușor de adăugat un component predefinit (de exemplu, SGBD MySQL) sau un chart Helm. Citiți mai multe în documentation — nu este complicat.

Skaffold

Site; GitHub.
Statistici scurte GH: 7423 stele, 4173 commit-uri, 136 contribuabili.
Limbaj: Go.
Licență: Apache License 2.0.

Această utilitate de la Google pretinde că acoperă toate nevoile dezvoltatorului ale cărui cod va fi rulat într-un cluster Kubernetes. A începe să o folosești nu este la fel de simplu ca cu devspace: nu există interactivitate, determinarea limbajului sau crearea automată Dockerfile nu vi se va propune aici.

Cu toate acestea, dacă acest lucru nu vă sperie — iată ce poate face Skaffold:

Urmăriți modificările codului sursă.
Sincronizați-l cu containerul pod-ului, dacă nu necesită construcție.
Construiți containere cu cod, dacă limbajul de programare este interpretat, sau compilați artefactele și împachetați-le în containere.
Imaginile obținute să fie verificate automat folosind container-structure-test.
Etichetați și încărcați imaginile în Docker Registry.
Implementați aplicația în cluster, folosind kubectl, Helm sau kustomize.
Faceți redirecționarea porturilor.
Depanați aplicațiile scrise în Java, Node.js, Python.

Workflow-ul în diferite variații este descris declarației în fișierul skaffold.yaml. Pentru proiect, puteți de asemenea să definiți mai multe profiluri, în care să modificați parțial sau complet etapele de construcție și implementare. De exemplu, pentru dezvoltare, specificați o imagine de bază convenabilă pentru dezvoltator, iar pentru staging și producție — minimală (+ utilizați securityContext în containere sau să redefinească clusterul în care aplicația va fi desfășurată).

Construirea containerelor Docker poate fi realizată local sau de la distanță: în Google Cloud Build sau în cluster cu ajutorul Kaniko. De asemenea, sunt acceptate Bazel și Jib Maven/Gradle. Pentru etichetarea Skaffold, sunt acceptate multiple strategii: după hash-ul commit-ului git, dată/oră, suma sha256 a surselor etc.

Merită menționată în mod special posibilitatea testării containerelor. Cadrele menționate anterior, container-structure-test, oferă următoarele metode de verificare:

Executarea comenzilor în contextul containerului cu urmărirea stării de ieșire și verificarea 'output-ului' textului comenzii.
Verificarea existenței fișierelor în container și conformitatea atributelor cu cele specificate.
Controlul conținutului fișierelor folosind expresii regulate.
Compararea metadatelor imaginii (ENV, ENTRYPOINT, VOLUMES ș.a.
Verificarea compatibilității licențelor.

Sincronizarea fișierelor cu containerul se face într-un mod nu foarte optim: Skaffold creează pur și simplu un arhiv cu sursele, îl copiază și îl dezarhivează în container (tar trebuie să fie instalat). Prin urmare, dacă scopul dumneavoastră principal este sincronizarea codului, mai bine căutați o soluție specializată (ksync).

Etapele principale ale funcționării Skaffold

În general, instrumentul nu permite abstractizarea de la manifestele Kubernetes și nu are vreo interactivitate, așa că poate părea dificil de învățat. Dar acesta este și avantajul său - o libertate mai mare de acțiune.

Garden

Site; GitHub.
Statistici scurte GH: 1063 stele, 1927 commit-uri, 17 contribuabili.
Limbaj: TypeScript (se preconizează împărțirea proiectului în mai multe componente, unele dintre ele fiind în Go, precum și realizarea unui SDK pentru crearea extensiilor în TypeScript/JavaScript și Go).
Licență: Apache License 2.0.

Ca și Skaffold, Garden este destinat automatizării proceselor de livrare a codului aplicației în clusterul K8s. Pentru aceasta, mai întâi este necesar să descrieți structura proiectului într-un fișier YAML, după care să rulați comanda garden dev. Aceasta va face toată magia:

Va construi containerele cu diferite părți ale proiectului.
Va efectua teste de integrare și unitate, dacă acestea au fost descrise.
Va desfășura toate componentele proiectului în cluster.
În cazul modificării codului sursă - va relua întregul pipeline.

Principalul accent în utilizarea acestui instrument este pe colaborarea echipei de dezvoltare în cadrul unui cluster de la distanță. În acest caz, dacă unele etape de compilare și testare au fost deja realizate, acest lucru va accelera semnificativ întregul proces, deoarece Garden va putea folosi rezultatele cache-uite.

Modulul proiectului poate fi un container, un container Maven, un chart Helm, un manifest pentru kubectl apply sau chiar o funcție OpenFaaS. Oricare dintre module poate fi tras dintr-un repository Git de la distanță. Un modul poate defini (sau nu) servicii, sarcini și teste. Serviciile și sarcinile pot avea dependențe, ceea ce permite definirea ordinii de deploy a fiecărui serviciu, organizarea lansării sarcinilor și testelor.

Garden oferă utilizatorului un dashboard atractiv (deocamdată în stadiu experimental), care afișează graficul proiectului: componentele, ordinea de compilare, execuția sarcinilor și testelor, legăturile și dependențele lor. Direct în browser, se pot vizualiza și jurnalele tuturor componentelor proiectului, verificând ce returnează fiecare componentă prin HTTP (dacă, desigur, pentru aceasta a fost declarat un resursă ingress).

Panoul pentru Garden

Acest instrument oferă și un mod de hot-reload, care sincronizează pur și simplu modificările scripturilor cu containerul din cluster, accelerând semnificativ procesul de depanare a aplicației. Garden dispune de un set bun documentația și nu tocmai rău de exemple, permițându-le utilizatorilor să se familiarizeze rapid și să înceapă să utilizeze. Apropo, recent am publicat traducerea unui articol de la autorii săi.

Concluzie

Desigur, această listă nu epuizează instrumentele pentru dezvoltarea și depanarea aplicațiilor în Kubernetes. Există multe utilitare utile și practice, care merită menționate, dacă nu într-un articol separat, atunci – cel puțin – ca o mențiune. Spuneți-ne, ce instrumente utilizați, cu ce probleme v-ați confruntat și cum le-ați rezolvat!