Puncte:0

Cluster partajat Kubernetes

drapel vn

Planificăm noua noastră infrastructură de cluster Kubernetes și am câteva întrebări. În prezent, avem un cluster mai mare în care lucrează medii (dezvoltare, punere în scenă, producție) și mai multe echipe. La început, a fost doar un „POC”, un demo – dar băieți, știți: nimic nu durează mai mult decât soluțiile temporare. În această configurare, avem câteva probleme generale, iar în arhitectura noastră de destinație, intenționăm să remediem unele dintre aceste subiecte.

Sper că unii dintre voi puteți împărtăși cunoștințele/experiența.

În primul rând: un cluster per aplicație nu este o soluție. Aplicațiile sunt foarte mici și fiecare echipă are în jur de 3-5 aplicații și are nevoie de aproximativ 6-20 GB de memorie RAM pe toate nodurile per mediu. Deci un singur cluster nu este cu adevărat o opțiune.

Planificăm un cluster per mediu: dev, staging (qa), prod și poate pentru operațiuni un cluster demonstrativ. Totul este și va fi automatizat și IaC cu terraform + ansible (kubespray). Fiecare echipă/aplicație va primi un singur spațiu de nume - de cauză.

Întrebările/problemele noastre:

Monitorizarea În mod normal, folosim Prometheus și Grafana pentru a monitoriza utilizarea resurselor pod/cluster.New ar trebui să conțină și înregistrarea centrală (încercăm soluții chiar acum). Acest lucru este bine pentru echipa infra, dar infra nu vrea să monitorizeze la nivel de aplicație.

Există vreo modalitate de lucru de a oferi echipelor de aplicații o monitorizare? Cum ar fi: dvs. (echipa aplicației) puteți configura alerte privind jurnalele, procesorul, utilizarea ramului, orice aveți nevoie. „Trebuie doar să dezvolți această diagramă de cârmă”. Într-o lume grozavă, aș oferi fiecărei echipe (deci fiecare spațiu de nume) propriul stack de monitorizare, astfel încât, de asemenea, putem limita spațiul de stocare și utilizarea ram+cpu și fiecare echipă poate folosi resursele „ordonate” (deci dacă echipa are o mulțime de jurnale / nevoi de monitorizare, trebuie să „ordoneze” mai multe resurse”). De asemenea, pe baza acestei abordări, ei pot alege software-ul care se potrivește cel mai bine.

O altă soluție ar putea fi ca infra team să configureze o soluție centrală de monitorizare / jurnal și să limiteze accesul. App-Team A nu ar trebui să poată accesa jurnalele/utilizarea CPU/utilizarea ram/utilizarea discului de la App-Team B. Dar nu văd nicio modalitate de a face asta chiar bine.

Poate fi o opțiune pe care echipa infra instalează acea stivă - dar tot ce am văzut este: când instalez o stivă de monitorizare pe un anumit spațiu de nume, stiva are nevoie de acces de administrator la cluster. Acest lucru nu este frumos după părerea mea.

gresesc?

Depozitare Avem un depozit pentru gluster și vrem să-l păstrăm. Dacă o echipă are nevoie de un disc, adăugăm un „volum persistent glusterfs” cu o anumită dimensiune și storageClassName, cum ar fi „team1-disk5”. Pe baza acestui lucru, echipa poate crea un PVC și poate folosi depozitul. Funcționează bine în trecut.

Este aceasta o soluție bună? Alte idei?

Cred că asta e tot pentru moment. Doar acele două întrebări. Aveți idee să mă mutați în direcția corectă?

Mulțumiri!

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.