Hej Habr!
Predstavljamo tim Exness platforme. Prethodno su naše kolege već pisale članak o . Danas želimo podijeliti naše iskustvo migracije usluga na Kubernetes.
Za početak, nudimo vam nekoliko brojeva za bolje razumijevanje o čemu će biti riječi:
- Naš razvojni odjel se sastoji od 100+ ljudi, uključujući više od 10 različitih timova sa samodovoljnim QA, DevOps i Scrum procesima. Razvojni stog - Python, PHP, C++, Java i Golang.
- Veličina testnog i proizvodnog okruženja je oko 2000 kontejnera svaki. Oni koriste Rancher v1.6 na vlastitoj virtuelizaciji i pod VMware-om.
Motivacija
Kako kažu, ništa ne traje vječno, a Rancher je davno najavio prestanak podrške za verziju 1.6. Da, za više od tri godine naučili smo kako to pripremiti i riješiti probleme koji se pojavljuju, ali sve češće se susrećemo sa problemima koji se nikada neće ispraviti. Rancher 1.6 takođe ima okoštali sistem za izdavanje prava, gde možete ili skoro sve ili ništa.
Iako je vlasnička virtuelizacija omogućila veću kontrolu nad skladištenjem podataka i njihovom sigurnošću, nametnula je operativne troškove koje je bilo teško prihvatiti s obzirom na konstantan rast kompanije, broj projekata i zahtjeve za njima.
Željeli smo slijediti IaC standarde i, ako je potrebno, brzo dobiti kapacitet, na bilo kojoj geografskoj lokaciji i bez zaključavanja dobavljača, a isto tako biti u mogućnosti da ga brzo napustimo.
prvi koraci
Prije svega, željeli smo se osloniti na moderne tehnologije i rješenja koja bi omogućila timovima da imaju brži razvojni ciklus i minimiziraju operativne troškove za interakciju s platformom koja daje snagu.
Naravno, prvo što nam je palo na pamet bio je Kubernetes, ali nismo se uzbuđivali i malo smo istražili da vidimo da li je to pravi izbor. Procijenili smo samo rješenja otvorenog koda, a u nepravednoj borbi Kubernetes je bezuvjetno pobijedio.
Zatim je došlo pitanje izbora alata za kreiranje klastera. Usporedili smo najpopularnija rješenja: kops, kubespray, kubeadm.
Za početak, kubeadm nam se činio previše komplikovanim putem, prije kao svojevrsnim izumiteljem „bicikla“, a kops nije imao dovoljno fleksibilnosti.
A pobjednik je bio:
Počeli smo da eksperimentišemo sa sopstvenom virtuelizacijom i AWS-om, pokušavajući da ponovo stvorimo nešto otprilike slično našem prethodnom obrascu upravljanja resursima, gde su svi delili isti „klaster“. I sada imamo naš prvi klaster od 10 malih virtuelnih mašina, od kojih se nekoliko nalazi u AWS-u. Počeli smo da pokušavamo da migriramo timove tamo, sve je izgledalo "dobro", i priča je mogla da se završi, ali...
Prvi problemi
Ansible je ono na čemu je izgrađen kubespray, to nije alat koji vam omogućava da pratite IaC: prilikom puštanja u rad/prekidanja čvorova, stalno je nešto šlo po zlu i bila je potrebna neka vrsta intervencije, a kada se koriste različiti OS, playbook se ponašao drugačije. . Kako je broj timova i čvorova u klasteru rastao, počeli smo primjećivati da je potrebno sve duže i duže da se kompletira, a kao rezultat toga, naš rekord je bio 3,5 sata, a vaš? 🙂
I čini se da je kubespray samo Ansible, i sve je jasno na prvi pogled, ali:
Na početku puta, zadatak je bio da se kapaciteti pokrenu samo u AWS-u i na virtuelizaciji, ali su se onda, kao što se često dešava, promenili zahtevi.
U svetlu ovoga, postalo je jasno da naš stari obrazac kombinovanja resursa u jedan sistem orkestracije nije prikladan - u slučaju kada su klasteri veoma udaljeni i kojima upravljaju različiti provajderi.
Dalje više. Kada svi timovi rade u okviru istog klastera, razni servisi sa pogrešno instaliranim NodeSelectorima mogli bi letjeti na "strani" domaćin drugog tima i tamo koristiti resurse, a ako je postavljena mrlja, postojali su stalni zahtjevi da jedan ili drugi servis ne radi, nije pravilno distribuiran zbog ljudskog faktora. Drugi problem je bio izračunavanje troškova, posebno s obzirom na probleme u distribuciji usluga po čvorovima.
Posebna priča je bila izdavanje prava zaposlenima: svaki tim je želio da bude „na čelu“ klastera i da u potpunosti upravlja njime, što bi moglo izazvati potpuni kolaps, jer su timovi u osnovi nezavisni jedni od drugih.
Kako biti?
Uzimajući u obzir navedeno i želje timova da budu nezavisniji, izveli smo jednostavan zaključak: jedan tim – jedan klaster.
Tako da imamo drugu:
I onda treći klaster:
Onda smo počeli razmišljati: recimo da će za godinu dana naši timovi imati više od jednog klastera? U različitim geografskim područjima, na primjer, ili pod kontrolom različitih provajdera? A neki od njih će htjeti da budu u mogućnosti da brzo implementiraju privremeni klaster za neke testove.
Puni Kubernetes bi došao! Ispostavilo se da je ovo neka vrsta MultiKubernetesa.
Istovremeno, svi ćemo morati na neki način održavati sve ove klastere, moći lako upravljati pristupom njima, kao i kreirati nove i dekomisionirati stare bez ručne intervencije.
Prošlo je neko vrijeme od početka našeg putovanja u svijet Kubernetesa i odlučili smo da preispitamo dostupna rješenja. Ispostavilo se da već postoji na tržištu - Rancher 2.2.
U prvoj fazi našeg istraživanja, Rancher Labs je već napravio prvo izdanje verzije 2, ali iako se moglo pokrenuti vrlo brzo pokretanjem kontejnera bez vanjskih ovisnosti s nekoliko parametara ili korištenjem službenog HELM Chart-a, izgledalo je grubo nama, i nismo znali da li se možemo osloniti na ovu odluku da li će se ona razviti ili brzo napustiti. Paradigma cluster = clicks u samom korisničkom sučelju nam također nije odgovarala, a nismo željeli da se vezujemo za RKE, jer je to prilično usko fokusiran alat.
Verzija Rancher 2.2 je već imala funkcionalniji izgled i, zajedno sa prethodnim, imala je gomilu zanimljivih funkcija iz kutije, kao što su integracija sa mnogim eksternim provajderima, jedna tačka distribucije prava i kubeconfig fajlova, pokretanje kubectl-a slika sa vašim pravima u korisničkom sučelju, ugniježđeni prostori imena ili projekti.
Postojala je i zajednica koja je već formirana oko Ranchera 2, a provajder pod nazivom HashiCorp Terraform je kreiran da njime upravlja, što nam je pomoglo da sve spojimo.
Šta se desilo
Kao rezultat toga, dobili smo jedan mali klaster koji pokreće Rancher, dostupan svim drugim klasterima, kao i mnogim klasterima povezanim s njim, pristup bilo kojem od kojih se može odobriti jednostavno kao dodavanjem korisnika u ldap direktorij, bez obzira na gdje se nalazi i koje resurse provajdera koristi.
Koristeći gitlab-ci i Terraform, kreiran je sistem koji vam omogućava da kreirate klaster bilo koje konfiguracije u cloud provajderima ili našoj sopstvenoj infrastrukturi i povežete ih na Rancher. Sve se to radi u IaC stilu, gdje je svaki klaster opisan repozitorijumom, a njegovo stanje je verzionirano. U isto vrijeme, većina modula je povezana iz vanjskih spremišta, tako da sve što ostaje je proslijediti varijable ili opisati vašu prilagođenu konfiguraciju za primjere, što pomaže u smanjenju postotka ponavljanja koda.
Naravno, naš put je daleko od kraja i pred nama je još mnogo zanimljivih zadataka, kao što je jedna točka rada s logovima i metrikama bilo kojeg klastera, servisna mreža, gitopovi za upravljanje opterećenjima u multiclusteru i još mnogo toga. Nadamo se da će vam naše iskustvo biti zanimljivo!
Članak su napisali A. Antipov, A. Ganush, inženjeri platforme.
izvor: www.habr.com