Folosiți Kubernetes?

Un sondaj util pentru forum despre un tool (încă) popular pentru deployment-ul aplicațiilor de orice tip.

La ce nivel cunoști Kubernetes?

  • Conceptual
  • Utilizator (App developer)
  • Ops (Admin)
  • Nu știu, nu-s de-aici :slight_smile:

0 participanți

Folosești Kubernetes la proiectele în care participi?

  • Da
  • Nu
  • Am de gând

0 participanți

Dacă folosești, de la ce provider?

  • AWS
  • GCP
  • Azure
  • On-premise
  • Alt provider

0 participanți

1 Like

Am folosit k8s la 2 proiecte mari deja, dar grija mare ca putini stiu cu ce se mananca si e scump.

Un puzzle pe care il am acum e cum generez values.yaml cu datele din Terraform pentru Azure/AWS/GCP si on-prem deodata. Fiecare environment are ceva specific la valorile/secretele utilizate.

Helm charts e usor de folosit gresit, adica nu setezi tot flow-ul automat care sa faca upgrade cand apare o versiune noua. (ArgoCD/harness.io)

La java am intalnit probleme cu cold start-uri, trebuie sa limitezi fiecare container ca sa nu iti ia toate resursele la cold start altfel un singur serviciu se poate comporta ca un memory leak si epuizeaza resursele intregului cluster. Chiar unele servicii trebuie prioritizate cu preemption.

In arhitectura de microservicii iti trebuie un service discovery, daca ai folosit Spring atunci Eureka cam trebuie inlocuit cu k8s ingress si e distractie maxima.

O problema cu docker, nu kubernetes in sine e ca poti avea imagini native si imagini emulate pe mac-uri cu ARM64, cele emulate au tot felul de probleme.

La proiecte mici nu cred ca l-as folosi, as incerca Nomad | HashiCorp Developer la ceva mediu-mic, dar categoric as folosi k8s la ceva mare-urias.

Daca ai un front-end o sa te distrezi cu domenii, CORS, certificate…

2 Likes

Legat de proiectele mici.

Nomad nu are o arhitectura tocmai simpla. Este server-client, si are nevoie leader-election. Din experienta (consul, vault, care folosesc acelasi protocol) acest mecanism poate sa mai dea rateuri si sa iti puna totul in cap. Cred ca si cu nomad ai nevoie de un anume “efort” operational, care te poate duce pe culmi ale necunoscutului, exact ceea ce vrei sa eviti la un proiect mic unde vrei sa te misti rapid.

K8S are si solutii mai lightweight. Un motiv pentru care l-as folosi si la proiectele mici este pentru ca poti face rapid set-up la un pipeline de CI/CD. Cred ca folosindu-l deja la proiecte mari, n-ar fi vreun bottleneck sa-l alegi si pentru un proiect mic.

2 Likes

Noi rulăm microserviciile în k8s, însă eu ca developer nu am folosit deloc k8s direct. E un fel de platformă pentru mine. CI/CD e făcut de echipa de ops și n-am idee cum merge decât vag.

Mi se par cool conceptele din spate, și sincer aș vrea să-mi trec chestiile pe care le am pe acasă de pe docker-compose și deployment cu scripturi bash în k8s. Însă aș face asta doar pentru flexibilitate (să le mut de un sistem pe altul mai ușor).

1 Like

Rulăm microserviciile in k8s. Avem 4 stack-uri, localhost, dev, stage și prod.
Local folosim docker-compose. Pe dev toți avem access la k8s (cine strică trebuie să repare).

E relativ simplu, dar ia ceva timp să te obișnuiești cu tot workflow-ul (ah, CI/CD crează imaginile și face update pe dev în urma unui merge to master/main în git).

1 Like

Docker-compose e un pain point in ultima perioada, trebuie trecut si dev stack-ul pe kubernetes, altfel mai tot compose-ul devine inca un proiect de intretinut ca sa iti mearga local dev stack-ul. (unii il intretin, altii nu) Iar daca ai noroc k8s o sa fie total diferit de ce ai in docker-compose si ideea era sa rulezi acelasi lucru si local ca pe servere.

Rancher Desktop e o solutie buna pentru un environment k8s local.

Cand l-am testat nu era o solutie buna,
Insufficient permission to manipulate /usr/local/bin · Issue #1155 · rancher-sandbox/rancher-desktop (github.com)

Acum au mai rezolvat dintre probleme.
Fata de Docker Desktop e mai incet si mai ciudat.

Am utilizat cu succes minikube si kind, rancher era problematic pe mac. Am ramas la Docker Desktop fiindca am cumparat licente si daca esti multi-platform sunt diferente destul de mari precum host.docker.internal de care ai nevoie daca ai servicii care comunica cu keycloak/ory/zitadel de exemplu si trebuie tinut domeniul ca sa ai sesiunea valida intre aplicatii.

1 Like

I don’t know… funcționeză f bine pt noi. Prin docker-compose pornesc baza de date, redis, elastic search și ce mai e nevoie pt a lucra pe local. Am opțiunea să mă leg la baza de date, redis etc din dev dacă e nevoie, dar rareori fac asta.

1 Like

Pentru local k8s environment, tilt.dev si skaffold.dev sunt niste solutii destul de interesante care ajuta developer-ul sa se focuseze pe dezvoltare

2 Likes

Docker Desktop nu cred ca merge pe Linux. :slightly_smiling_face:
In plus, docker e deprecated in k8s (parca de pe la versiunea 1.20, nu mai tin minte exact - suportul va fi scos complet in versiunile viitoare). Rancher Desktop se poate instala cu containerd si nerdctl - l-am testat cu succes pe Mac (M1 si Intel).
Sau, cel mai frumos, niste masini virtuale in KVM sau Virtualbox si-ti faci un master si 3 noduri cu ce CRI vrea sufletul fiecaruia - crio, containerd sau chiar docker.

2 Likes

Bai ce mai bucur ca mai dati niste linkuri si mai invat si eu niste chestii. Fara misto.

Cat despre cum folosim noi k8s, in fine: avem prod, staging si 3x dev environments. In afara de prod, toate sunt spot instances :smiley: Toate in GCP. La cum e folosita aplicatia ne bate gandu sa folosim spot instances si in prod, ce mama naibii. Mai scutim niste $

Pe local e putin haos si chiar eram curios cum lucrati. Am incercat multe variante. Momentan sunt cu docker-compose dezvoltand individual fiecare ms, fac push la imagine si o schimb in dev environment-ul personal din GCP cand am nevoie sa ii fac o acceptanta manuala :smiley: . Mai folosim Taskfile(care e un fel de make evoluat), kubens+kubectx pentru fast context switching si inca niste chestii mai micute care imi scapa acum.

Stiu ca se poate mai bine dar nici timp nici chef parca nu mai am sa fac research :frowning:

La noi e nevoie de aprox 200 de cores si cam tot pe atata ram ca sa ruleze tot. Deci exclus sa ai un mediu cu absolut tot pe local. Si in principiu mi se pare greu cu dezvoltatul in local sub k8s mai ales daca ajungi sa ai 60+ microservicii. E prea mult. Ceea ce inevitabil va duce la un compromis.

Si da, stiu ca sunt prea multe microservicii…cel mai probabil nu e nevoie de ele si asa este. Proiectul e incepul mai demult iar antipattern-ul de nano-services este prezent din plin. Dar nu ne luam din asta acuma…

P.S. Abia astept sa testez zilele astea si Rancher si Tilt si Skaffold.

5 Likes

Pentru cine are timp si chef, tot k8s

3 Likes

Toate solutiile de remote-local dev suna bine, pana iti dai seama ca la toate corporatiile iti trebuie VPN sau ip static pentru whitelist ca sa te poti conecta la clusterul remote.

Mixarea serviciilor functioneaza doar daca ai un discovery service compatibil cu asta, altfel serviciile nu se vor gasi intre ele.

Dupa daca folosesti helm charts si ai un dev care nu stie ce face s-ar putea sa dea Edit cu k8 lens de exemplu si nu ti se mai actualizeaza imaginea la helm upgrade.

Trendul este catre remote development si vor aparea din ce in ce mai multe solutii care sa rezolve barierele de moment.

1 Like

In experienta mea cam 5% din devii pe care ii poti lua pe un proiect vor avea capacitatea sa implementeze si sa intretina asa ceva, e mult mult mult mai complicat decat pare la un proiect real. Iar daca exista deja microservicii legacy e si mai putin probabil.

Ca sa iti dau context:

  1. Pentru microservicii trebuie sa iti setezi pipeline-ul si tot dev flow-ul, build-ul sa creeze imagini cu kaniko/buildx intr-un anumit fel.
  2. Tot remote dev env-ul ar trebui sa fie idempotent, daca 10 devi folosesc acelasi env o sa iti creasca fire albe la un moment dat. Ca sa iti faci un env la un proiect real pentru fiecare dev ar fi ridicol de scump cu GCP/AWS. (asta daca vrei sa lucrezi si cu baza de date/message queue-uri, la front-end mai merge)
  3. Te bazezi pe faptul ca environment-ul remote e de incredere, kubernetes are tot felul de probleme ciudate la care poti sa iei 10 devi seniori si nici unul nu o sa stie care e problema ca nici log-urile nu le puteti intelege. Pot aparea multe probleme cu retelistica, domeniile, certificatele, ceva ramane blocat si trebuie refacut tot clusterul.
  4. Pe front-end intervine reverse-proxy-ul la autentificare, websockets, gRPC, certificate, domenii interne/externe… Daca ai un identity provider trebuie configurat sa functioneze cu reverse-proxy-ul.
2 Likes

Ai dreptate in ceea ce spui, in momentul de fata “remote development” nu este suficient de matur si usor de folosit astfel incat sa fie implementat in proiectele reale(cu exceptii), dar majoritatea toolurilor incearca sa abstractizeze cat mai mult partea de setup si totul se rezuma la un app init, app destroy, app build, rezultatul ar trebuii sa fie ca devs sa se focuseze pe dezvoltat, nu sa utilizeze tooluri fancy

Deploymentul aplicatie noastre se face in principal cu Docker Compose (V2 acum). Avem si un deployment cu Kubernetes. Avem un caz mai special, nu avem un unic deployment, iar clientii instaleaza on-premises. Pentru ca acum avem un script de instalare care instaleaza Docker, ne gandim sa il inlocuim cu script care instaleaza kubeadm. Asta in scenariul in care e Kubernetes “on the cheap”, pe unica masina. Clientii mari, care urmaresc high availability, isi vor instala ei si configura Kubernetes separat. Noi doar incercam sa ne unificam cele doua metode de deployment ca sa avem mai putin efort pe intretinere.

In secondar, aplicatia noastra e folosita de fapt si pentru creare de clustere Kubernetes (folosind proiectul Magnum din OpenStack), si tot noi avem o oferta de clustere Kubernetes pe hardware din Cluj (centru de date GTS, in Liberty Park).

2 Likes
3 Likes

Mutagen | Cloud-based development using your local tools daca vreti doar sync la fisiere