Pozdravljeni, Habr!
Zastopamo ekipo platforme Exness. Pred tem so naši kolegi že napisali članek o . Danes želimo deliti naše izkušnje s selitvijo storitev na Kubernetes.
Za začetek vam ponujamo nekaj številk za boljše razumevanje o čem bomo razpravljali:
- Naš razvojni oddelek sestavlja več kot 100 ljudi, vključno z več kot 10 različnimi ekipami s samozadostnimi procesi QA, DevOps in Scrum. Razvojni sklad - Python, PHP, C++, Java in Golang.
- Velikost testnega in proizvodnega okolja je približno 2000 vsebnikov vsako. Poganjajo Rancher v1.6 na lastni virtualizaciji in pod VMware.
Motivacija
Kot pravijo, nič ne traja večno, Rancher pa je konec podpore za različico 1.6 napovedal že precej dolgo nazaj. Da, v več kot treh letih smo se ga naučili pripraviti in rešiti težave, ki se pojavljajo, a vse pogosteje se soočamo s težavami, ki jih nikoli ne bomo odpravili. Rancher 1.6 ima tudi okostenel sistem izdajanja pravic, kjer lahko narediš skoraj vse ali nič.
Čeprav je lastniška virtualizacija omogočala večji nadzor nad shranjevanjem podatkov in njihovo varnostjo, je zaradi nenehne rasti podjetja, števila projektov in zahtev po njih povzročila težko sprejemljive stroške poslovanja.
Želeli smo slediti standardom IaC in po potrebi hitro pridobiti kapaciteto, na kateri koli geografski lokaciji in brez zaklepanja dobavitelja, ter jo lahko tudi hitro opustiti.
Prvi koraki
Najprej smo se želeli zanesti na sodobne tehnologije in rešitve, ki bi ekipam omogočile hitrejši razvojni cikel in minimizirale operativne stroške za interakcijo s platformo, ki zagotavlja moč.
Seveda nam je najprej na misel prišel Kubernetes, vendar se nismo navduševali in smo malo raziskovali, ali je to prava izbira. Ocenjevali smo le odprtokodne rešitve in v nepoštenem boju je brezpogojno zmagal Kubernetes.
Sledilo je vprašanje izbire orodja za ustvarjanje grozdov. Primerjali smo najbolj priljubljene rešitve: kops, kubespray, kubeadm.
Za začetek se nam je zdel kubeadm preveč zapletena pot, prej kot nekakšen izumitelj »kolesa«, kops pa premalo prilagodljivosti.
In zmagovalec je bil:
Začeli smo eksperimentirati z našo lastno virtualizacijo in AWS ter poskušali poustvariti nekaj približno podobnega našemu prejšnjemu vzorcu upravljanja virov, kjer so vsi delili isto »gručo«. In zdaj imamo prvo gručo 10 majhnih virtualnih strojev, od katerih jih je nekaj v AWS. Tam smo začeli poskušati seliti ekipe, vse je bilo videti »dobro« in zgodba bi se lahko končala, a ...
Prve težave
Ansible je tisto, na čemer je zgrajen kubespray, ni orodje, ki vam omogoča sledenje IaC: pri zagonu/razgradnji vozlišč je šlo nenehno nekaj narobe in je bil potreben nekakšen poseg, pri uporabi različnih operacijskih sistemov pa se je playbook obnašal drugače. . Ko je število ekip in vozlišč v gruči raslo, smo začeli opažati, da je dokončanje priročnika trajalo vse dlje in posledično je bil naš rekord 3,5 ure, kaj pa vaš? 🙂
In zdi se, da je kubespray samo Ansible in je vse jasno na prvi pogled, toda:
Na začetku poti je bila naloga zagon zmogljivosti samo v AWS in na virtualizaciji, potem pa so se, kot se pogosto zgodi, zahteve spremenile.
V luči tega je postalo jasno, da naš stari vzorec združevanja virov v en orkestracijski sistem ni primeren – v primeru, ko so grozdi zelo oddaljeni in jih upravljajo različni ponudniki.
Še več. Ko vse ekipe delajo v istem grozdu, lahko različne storitve z nepravilno nameščenimi NodeSelectors letijo na "tujega" gostitelja druge ekipe in tam uporabljajo vire, in če je bil nastavljen taint, so bile stalne zahteve, da ena ali druga storitev ne deluje, ni pravilno razdeljen zaradi človeškega faktorja. Druga težava je bil izračun stroškov, zlasti glede na težave pri distribuciji storitev po vozliščih.
Posebna zgodba je bila izdaja pravic zaposlenim: vsak tim je želel biti »na čelu« grozda in ga v celoti upravljati, kar bi lahko povzročilo popoln kolaps, saj so timi v bistvu neodvisni drug od drugega.
Kaj storiti?
Glede na navedeno in želje timov po večji samostojnosti smo naredili preprost zaključek: en tim – en grozd.
Pa smo dobili drugega:
In potem tretji grozd:
Potem smo začeli razmišljati: recimo, da bodo naše ekipe čez eno leto imele več kot en grozd? Na primer na različnih geografskih območjih ali pod nadzorom različnih ponudnikov? In nekateri od njih bodo želeli imeti možnost hitre uvedbe začasne gruče za nekaj testov.
Poln Kubernetes bi prišel! Izkazalo se je, da je to neke vrste MultiKubernetes.
Hkrati pa bomo vsi morali nekako vzdrževati vse te grozde, biti sposobni enostavno upravljati dostop do njih, pa tudi ustvarjati nove in razgrajevati stare brez ročnega posega.
Od začetka naše poti v svetu Kubernetesa je minilo že nekaj časa in odločili smo se, da ponovno preučimo razpoložljive rešitve. Izkazalo se je, da že obstaja na trgu - Rancher 2.2.
Na prvi stopnji naše raziskave je Rancher Labs že izdelal prvo izdajo različice 2, a čeprav jo je bilo mogoče dvigniti zelo hitro z zagonom vsebnika brez zunanjih odvisnosti z nekaj parametri ali z uporabo uradnega grafikona HELM, se je zdelo surovo in nismo vedeli, ali se lahko zanesemo na to odločitev, ali jo bomo razvili ali hitro opustili. Tudi paradigma cluster = clicks v samem uporabniškem vmesniku nam ni ustrezala in nismo se želeli vezati na RKE, saj gre za precej ozko usmerjeno orodje.
Različica Rancher 2.2 je že imela bolj uporabno podobo in je imela skupaj s prejšnjimi kopico zanimivih funkcij, kot so integracija s številnimi zunanjimi ponudniki, enotna točka distribucije pravic in datotek kubeconfig, zagon kubectl slika z vašimi pravicami v uporabniškem vmesniku, ugnezdeni imenski prostori ali projekti.
Okoli Rancher 2 je bila tudi že oblikovana skupnost in za njeno upravljanje je bil ustvarjen ponudnik, imenovan HashiCorp Terraform, ki nam je pomagal vse skupaj sestaviti.
Kaj se je zgodilo
Posledično smo imeli eno majhno gručo, ki poganja Rancher, ki je dostopna vsem drugim gručam, pa tudi številnim z njo povezanim gručam, od katerih je dostop do katere koli mogoče odobriti preprosto kot dodajanje uporabnika v imenik ldap, ne glede na kje se nahaja in katerega ponudnikova sredstva uporablja.
Z uporabo gitlab-ci in Terraform je bil ustvarjen sistem, ki vam omogoča, da ustvarite gručo poljubne konfiguracije v ponudnikih oblakov ali lastni infrastrukturi in jih povežete z Rancherjem. Vse to je narejeno v slogu IaC, kjer je vsaka gruča opisana z repozitorijem, njeno stanje pa je verzirano. Hkrati je večina modulov povezanih iz zunanjih repozitorijev, tako da ostane le posredovanje spremenljivk ali opis vaše konfiguracije po meri za primerke, kar pomaga zmanjšati odstotek ponavljanja kode.
Seveda naša pot še zdaleč ni končana in pred nami je še veliko zanimivih nalog, kot so enotna točka dela z dnevniki in metrikami poljubnih grozdov, storitvena mreža, gitops za upravljanje obremenitev v multiclustru in še veliko več. Upamo, da vam je naša izkušnja zanimiva!
Članek sta napisala A. Antipov, A. Ganush, inženirji platforme.
Vir: www.habr.com