Hei Habr!
Reprezentăm echipa platformei Exness. Anterior, colegii noștri au scris deja un articol despre . Astăzi dorim să împărtășim experiența noastră de migrare a serviciilor către Kubernetes.
Pentru început, vă oferim câteva cifre pentru o mai bună înțelegere a ceea ce va fi discutat:
- Departamentul nostru de dezvoltare este format din peste 100 de oameni, inclusiv peste 10 echipe diferite cu procese auto-suficiente de QA, DevOps și Scrum. Stack de dezvoltare - Python, PHP, C++, Java și Golang.
- Dimensiunea mediului de testare și de producție este de aproximativ 2000 de containere fiecare. Ei rulează Rancher v1.6 pe propria lor virtualizare și sub VMware.
Motivație
După cum se spune, nimic nu durează pentru totdeauna, iar Rancher a anunțat cu mult timp în urmă sfârșitul suportului pentru versiunea 1.6. Da, în mai bine de trei ani am învățat să o pregătim și să rezolvăm problemele care apar, dar tot mai des ne confruntăm cu probleme care nu vor fi corectate niciodată. Rancher 1.6 are, de asemenea, un sistem osificat de eliberare a drepturilor, unde poți fie să faci aproape totul, fie să faci nimic.
Deși virtualizarea proprietară a oferit un control mai mare asupra stocării datelor și a securității acesteia, a impus costuri de operare greu de acceptat având în vedere creșterea constantă a companiei, numărul de proiecte și cerințele pentru acestea.
Ne-am dorit să respectăm standardele IaC și, dacă este necesar, să obținem capacitate rapid, în orice locație geografică și fără blocare a furnizorului și, de asemenea, să o putem abandona rapid.
Primii pași
În primul rând, am vrut să ne bazăm pe tehnologii și soluții moderne care să permită echipelor să aibă un ciclu de dezvoltare mai rapid și să minimizeze costurile operaționale pentru interacțiunea cu platforma care furnizează energie.
Desigur, primul lucru care ne-a venit în minte a fost Kubernetes, dar nu ne-am entuziasmat și am făcut puțină cercetare pentru a vedea dacă a fost alegerea potrivită. Am evaluat doar soluții opensource și, într-o luptă nedreaptă, Kubernetes a câștigat necondiționat.
A urmat problema alegerii unui instrument pentru crearea clusterelor. Am comparat cele mai populare soluții: kops, kubespray, kubeadm.
Pentru început, kubeadm ni s-a părut o cale prea complicată, mai degrabă ca un fel de inventator al unei „biciclete”, iar kops nu avea suficientă flexibilitate.
Și câștigătorul a fost:
Am început să experimentăm propria noastră virtualizare și AWS, încercând să recreăm ceva aproximativ similar cu modelul nostru anterior de gestionare a resurselor, în care toată lumea împărtășea același „cluster”. Și acum avem primul nostru cluster de 10 mașini virtuale mici, dintre care câteva sunt situate în AWS. Am început să încercăm să migrăm echipe acolo, totul părea să fie „bine”, iar povestea se putea termina, dar...
Primele probleme
Ansible este pe care este construit kubespray, nu este un instrument care vă permite să urmăriți IaC: la punerea în funcțiune/dezafectarea nodurilor, ceva a mers prost în mod constant și a fost nevoie de un fel de intervenție, iar la utilizarea diferitelor sisteme de operare, manualul de joc s-a comportat diferit. . Pe măsură ce numărul de echipe și noduri din cluster a crescut, am început să observăm că registrul de joc durează din ce în ce mai mult să se completeze și, ca urmare, recordul nostru a fost de 3,5 ore, cum rămâne cu al tău? 🙂
Și se pare că kubespray este doar Ansible și totul este clar la prima vedere, dar:
La începutul călătoriei, sarcina era să lansăm capacități doar în AWS și pe virtualizare, dar apoi, așa cum se întâmplă adesea, cerințele s-au schimbat.
În lumina acestui fapt, a devenit clar că vechiul nostru model de combinare a resurselor într-un singur sistem de orchestrare nu era potrivit - în cazul în care clusterele sunt foarte îndepărtate și sunt gestionate de diferiți furnizori.
Mai departe mai mult. Atunci când toate echipele lucrează în cadrul aceluiași cluster, diverse servicii cu NodeSelectors instalate incorect ar putea zbura către gazda „străină” a altei echipe și să utilizeze resursele acolo, iar dacă era setat pata, existau solicitări constante că unul sau altul serviciu nu funcționează, nu sunt distribuite corect din cauza factorului uman. O altă problemă a fost calcularea costului, mai ales având în vedere problemele în distribuirea serviciilor între noduri.
O poveste separată a fost eliberarea drepturilor angajaților: fiecare echipă dorea să fie „în fruntea” clusterului și să-l gestioneze complet, ceea ce ar putea provoca un colaps complet, deoarece echipele sunt practic independente unele de altele.
Ce să fac?
Ținând cont de cele de mai sus și de dorințele echipelor de a fi mai independente, am făcut o concluzie simplă: o echipă - un cluster.
Deci avem al doilea:
Și apoi al treilea grup:
Apoi am început să ne gândim: să spunem că într-un an echipele noastre vor avea mai mult de un cluster? În diferite zone geografice, de exemplu, sau sub controlul diferiților furnizori? Și unii dintre ei vor dori să poată implementa rapid un cluster temporar pentru unele teste.
Ar veni Kubernetes complet! Se pare că acesta este un fel de MultiKubernetes.
În același timp, toți va trebui să menținem cumva toate aceste clustere, să putem gestiona cu ușurință accesul la ele, precum și să creăm altele noi și să le dezafectăm pe cele vechi fără intervenție manuală.
A trecut ceva timp de la începutul călătoriei noastre în lumea Kubernetes și am decis să reexaminăm soluțiile disponibile. S-a dovedit că există deja pe piață - Rancher 2.2.
La prima etapă a cercetării noastre, Rancher Labs făcuse deja prima lansare a versiunii 2, dar deși putea fi ridicată foarte rapid prin lansarea unui container fără dependențe externe cu câțiva parametri sau folosind graficul oficial HELM, părea grosier. pentru noi și nu știam dacă ne putem baza pe această decizie dacă va fi dezvoltată sau abandonată rapid. Paradigma cluster = clicuri din interfața de utilizare în sine nu ni se potrivea și nu am vrut să fim legați de RKE, deoarece este un instrument destul de concentrat.
Versiunea Rancher 2.2 avea deja un aspect mai funcțional și, împreună cu cele anterioare, avea o grămadă de caracteristici interesante din cutie, cum ar fi integrarea cu mulți furnizori externi, un singur punct de distribuire a drepturilor și fișierelor kubeconfig, lansarea unui kubectl imagine cu drepturile dumneavoastră în UI, spații de nume imbricate, alias proiecte.
A existat și o comunitate deja formată în jurul Rancher 2 și a fost creat un furnizor numit HashiCorp Terraform pentru a-l gestiona, ceea ce ne-a ajutat să punem totul cap la cap.
Ce s-a întâmplat
Ca urmare, am ajuns să avem un mic cluster care rulează Rancher, accesibil tuturor celorlalte clustere, precum și multor clustere conectate la acesta, accesul la oricare dintre acestea putând fi acordat la fel de simplu ca și adăugarea unui utilizator la directorul ldap, indiferent de unde se află și ce resurse ale furnizorului folosește.
Folosind gitlab-ci și Terraform, a fost creat un sistem care vă permite să creați un cluster cu orice configurație în furnizorii de cloud sau propria infrastructură și să le conectați la Rancher. Toate acestea se fac în stilul IaC, unde fiecare cluster este descris de un depozit, iar starea acestuia este versiunea. În același timp, majoritatea modulelor sunt conectate din depozite externe, astfel încât tot ce rămâne este să treci variabile sau să descrii configurația personalizată pentru instanțe, ceea ce ajută la reducerea procentului de repetare a codului.
Desigur, călătoria noastră este departe de a fi încheiată și mai sunt multe sarcini interesante înainte, cum ar fi un singur punct de lucru cu jurnalele și valorile oricăror clustere, rețeaua de servicii, gitop-uri pentru gestionarea sarcinilor într-un multicluster și multe altele. Sperăm că veți găsi experiența noastră interesantă!
Articolul a fost scris de A. Antipov, A. Ganush, Platform Engineers.
Sursa: www.habr.com