Hej Habr!
Predstavljamo tim Exness platforme. Prethodno su naši kolege već napisali članak o . Danas želimo podijeliti naše iskustvo migracije usluga na Kubernetes.
Za početak, nudimo vam neke brojeve za bolje razumijevanje o čemu će se raspravljati:
- Naš odjel za razvoj sastoji se od 100+ ljudi, uključujući više od 10 različitih timova sa samodostatnim QA, DevOps i Scrum procesima. Razvojni skup - Python, PHP, C++, Java i Golang.
- Veličina testnog i proizvodnog okruženja je oko 2000 spremnika svaki. Pokreću Rancher v1.6 na vlastitoj virtualizaciji i pod VMwareom.
Motivacija
Kako kažu, ništa ne traje vječno, a Rancher je davno najavio prestanak podrške za verziju 1.6. Da, u više od tri godine naučili smo ga pripremiti i riješiti probleme koji se pojave, ali sve češće se susrećemo s problemima koji se nikada neće moći ispraviti. Rancher 1.6 također ima okoštali sustav za izdavanje prava, gdje možete raditi ili gotovo sve ili ništa.
Iako je vlasnička virtualizacija omogućila veću kontrolu nad pohranom podataka i njihovu sigurnost, nametnula je operativne troškove koji su bili teško prihvatljivi s obzirom na stalni rast tvrtke, broj projekata i zahtjeva 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 također ga moći brzo napustiti.
Prvi koraci
Prije svega, htjeli smo se osloniti na suvremene tehnologije i rješenja koja će timovima omogućiti brži razvojni ciklus i minimizirati 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 je li to pravi izbor. Evaluirali smo samo opensource rješenja, au nepoštenoj borbi Kubernetes je bezuvjetno pobijedio.
Zatim je došlo pitanje odabira alata za stvaranje klastera. Usporedili smo najpopularnija rješenja: kops, kubespray, kubeadm.
Za početak, kubeadm nam se činio previše kompliciranom stazom, poput svojevrsnog izumitelja “bicikla”, a kops nije imao dovoljno fleksibilnosti.
A pobjednik je bio:
Počeli smo eksperimentirati s vlastitom virtualizacijom i AWS-om, pokušavajući ponovno stvoriti nešto otprilike slično našem prethodnom obrascu upravljanja resursima, gdje su svi dijelili isti "klaster". A sada imamo naš prvi klaster od 10 malih virtualnih strojeva, od kojih se nekoliko nalazi u AWS-u. Tamo smo počeli pokušavati preseliti timove, sve je izgledalo "dobro", i priča je mogla biti gotova, ali...
Prvi problemi
Ansible je ono na čemu je izgrađen kubespray, to nije alat koji vam omogućuje praćenje IaC-a: prilikom puštanja u pogon/dekomisioniranja čvorova stalno je nešto išlo krivo i bila je potrebna neka vrsta intervencije, a pri korištenju različitih operativnih sustava, playbook se ponašao drugačije. drugačije . Kako je broj timova i čvorova u klasteru rastao, počeli smo primjećivati da je za dovršetak priručnika potrebno sve više i više vremena, i kao rezultat toga, naš je rekord bio 3,5 sata, što je s vašim? 🙂
I čini se da je kubespray samo Ansible, i sve je jasno na prvi pogled, ali:
Na početku puta zadatak je bio pokrenuti kapacitete samo u AWS-u i na virtualizaciji, no onda su se, kao što se često događa, zahtjevi promijenili.
U svjetlu ovoga, postalo je jasno da naš stari obrazac kombiniranja resursa u jedan sustav orkestracije nije prikladan - u slučaju kada su klasteri vrlo udaljeni i njima upravljaju različiti pružatelji usluga.
Dalje više. Kada svi timovi rade unutar istog klastera, razni servisi s neispravno instaliranim NodeSelectorima mogli su letjeti na “strani” host drugog tima i tamo koristiti resurse, a ako je postavljen taint, postojali su stalni zahtjevi da jedan ili drugi servis ne radi, nisu ispravno raspoređeni zbog ljudskog faktora. Drugi problem bio je izračun troškova, posebno s obzirom na probleme u distribuciji usluga po čvorovima.
Posebna je priča bila izdavanje prava zaposlenicima: svaki je tim želio biti “na čelu” klastera i njime u potpunosti upravljati, što bi moglo izazvati potpuni kolaps, jer su timovi u principu neovisni jedni o drugima.
Što učiniti?
Uzimajući u obzir navedeno i želje timova za većom neovisnošću, donijeli smo jednostavan zaključak: jedan tim – jedan klaster.
Pa smo dobili 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 pružatelja usluga? A neki od njih će htjeti moći brzo implementirati privremeni klaster za neke testove.
Došao bi puni Kubernetes! Ovo je neka vrsta MultiKubernetesa, ispada.
U isto vrijeme, svi ćemo morati nekako održavati sve te klastere, moći lako upravljati pristupom njima, kao i stvarati nove i dekomisionirati stare bez ručne intervencije.
Prošlo je neko vrijeme od početka našeg putovanja u svijetu Kubernetesa i odlučili smo preispitati 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 spremnika bez vanjskih ovisnosti s nekoliko parametara ili korištenjem službene HELM karte, činilo se sirovo nama, a nismo znali možemo li se osloniti na ovu odluku hoće li se razvijati ili brzo odustati. Paradigma cluster = clicks u samom korisničkom sučelju također nam nije odgovarala i nismo se htjeli vezati za RKE, jer je to prilično usko usmjeren alat.
Verzija Rancher 2.2 već je imala praktičniji izgled i, zajedno s prethodnima, imala je hrpu zanimljivih značajki izvan kutije, poput integracije s mnogim vanjskim pružateljima usluga, jedinstvene točke distribucije prava i kubeconfig datoteka, pokretanja kubectl slika s vašim pravima u korisničkom sučelju, ugniježđeni prostori imena poznati kao projekti.
Postojala je i zajednica koja je već bila formirana oko Ranchera 2, a pružatelj pod nazivom HashiCorp Terraform stvoren je da njime upravlja, što nam je pomoglo da sve spojimo.
Što se dogodilo
Kao rezultat toga, završili smo s jednim malim klasterom koji pokreće Rancher, dostupan svim drugim klasterima, kao i mnogim klasterima povezanim s njim, pristup bilo kojem od kojih se može dodijeliti jednostavno kao dodavanje korisnika u ldap direktorij, bez obzira na gdje se nalazi i resurse kojeg pružatelja koristi.
Koristeći gitlab-ci i Terraform, kreiran je sustav koji vam omogućuje stvaranje klastera bilo koje konfiguracije u cloud providerima ili vlastitoj infrastrukturi i njihovo povezivanje s Rancherom. Sve se to radi u IaC stilu, gdje je svaki klaster opisan repozitorijem, a njegovo stanje je verzirano. U isto vrijeme, većina modula povezana je iz vanjskih repozitorija tako da sve što preostaje je proslijediti varijable ili opisati svoju prilagođenu konfiguraciju za instance, što pomaže smanjiti postotak ponavljanja koda.
Naravno, naše putovanje je daleko od završetka i predstoji još mnogo zanimljivih zadataka, kao što je jedna točka rada s zapisima i metrikom bilo kojeg klastera, servisna mreža, gitopovi za upravljanje opterećenjima u multiklasteru i još mnogo toga. Nadamo se da će vam naše iskustvo biti zanimljivo!
Članak su napisali A. Antipov, A. Ganush, Platform Engineers.
Izvor: www.habr.com