Čau Habr!
Zastupujeme tím platformy Exness. V minulosti už naši kolegovia napísali článok o . Dnes sa chceme podeliť o naše skúsenosti s migráciou služieb na Kubernetes.
Na začiatok vám ponúkame niekoľko čísel pre lepšie pochopenie toho, o čom sa bude diskutovať:
- Naše vývojové oddelenie pozostáva z viac ako 100 ľudí vrátane viac ako 10 rôznych tímov so sebestačnými procesmi QA, DevOps a Scrum. Vývojový zásobník - Python, PHP, C++, Java a Golang.
- Veľkosť testovacieho a produkčného prostredia je približne 2000 kontajnerov. Používajú Rancher v1.6 na vlastnej virtualizácii a pod VMware.
Motivácia
Ako sa hovorí, nič netrvá večne a Rancher oznámil koniec podpory verzie 1.6 už pomerne dávno. Áno, za viac ako tri roky sme sa ho naučili pripravovať a riešiť vzniknuté problémy, no čoraz častejšie sa stretávame s problémami, ktoré sa už nikdy nenapravia. Rancher 1.6 má aj skostnatený systém vydávania práv, kde buď môžete robiť takmer všetko, alebo nič.
Proprietárna virtualizácia síce poskytovala väčšiu kontrolu nad ukladaním dát a ich bezpečnosťou, no zaťažovala prevádzkové náklady, ktoré bolo ťažké akceptovať vzhľadom na neustály rast spoločnosti, množstvo projektov a požiadaviek na ne.
Chceli sme dodržiavať štandardy IaC a v prípade potreby získať kapacitu rýchlo, v akejkoľvek geografickej lokalite a bez obmedzenia dodávateľa, a tiež byť schopní ju rýchlo opustiť.
Prvé kroky
V prvom rade sme sa chceli spoľahnúť na moderné technológie a riešenia, ktoré by tímom umožnili rýchlejší vývojový cyklus a minimalizovali prevádzkové náklady na interakciu s platformou, ktorá poskytuje energiu.
Samozrejme, prvá vec, ktorá nám prišla na myseľ, bol Kubernetes, ale neboli sme nadšení a urobili sme malý prieskum, aby sme zistili, či je to správna voľba. Hodnotili sme iba opensource riešenia a v neférovom boji Kubernetes bezpodmienečne zvíťazil.
Ďalej prišla otázka výberu nástroja na vytváranie klastrov. Porovnali sme najobľúbenejšie riešenia: kops, kubespray, kubeadm.
Na začiatok sa nám zdalo, že kubeadm je príliš komplikovaná cesta, skôr ako nejaký vynálezca „bicykla“ a kops nemal dostatočnú flexibilitu.
A víťazom sa stal:
Začali sme experimentovať s našou vlastnou virtualizáciou a AWS a snažili sme sa vytvoriť niečo, čo je približne podobné nášmu predchádzajúcemu vzoru správy zdrojov, kde všetci zdieľali rovnaký „klaster“. A teraz máme prvý klaster 10 malých virtuálnych strojov, z ktorých pár sa nachádza v AWS. Začali sme sa tam snažiť migrovať tímy, všetko sa zdalo byť „dobré“ a príbeh mohol byť dokončený, ale...
Prvé problémy
Ansible je to, na čom je postavený kubespray, nie je to nástroj, ktorý vám umožní sledovať IaC: pri spúšťaní/vyraďovaní uzlov sa neustále niečo pokazilo a bol potrebný nejaký zásah a pri použití rôznych OS sa playbook správal inak. . Ako počet tímov a uzlov v klastri rástol, začali sme si všímať, že dokončenie playbooku trvalo dlhšie a dlhšie, a preto bol náš rekord 3,5 hodiny, čo váš? 🙂
A zdá sa, že kubespray je len Ansible a všetko je jasné na prvý pohľad, ale:
Na začiatku cesty bolo úlohou spustiť kapacity len v AWS a na virtualizácii, no potom, ako sa často stáva, sa požiadavky zmenili.
Vo svetle toho sa ukázalo, že náš starý model kombinovania zdrojov do jedného orchestračného systému nebol vhodný – v prípade, keď sú klastre veľmi vzdialené a spravujú ich rôzni poskytovatelia.
Ďalej viac. Keď všetky tímy pracujú v rámci toho istého klastra, rôzne služby s nesprávne nainštalovanými NodeSelectors by mohli lietať na „cudzieho“ hostiteľa iného tímu a využívať tam zdroje, a ak bola nastavená poškvrna, neustále sa objavovali požiadavky, že jedna alebo druhá služba nefunguje. nie sú distribuované správne kvôli ľudskému faktoru. Ďalším problémom bol výpočet nákladov, najmä vzhľadom na problémy s distribúciou služieb medzi uzlami.
Samostatným príbehom bolo vydávanie práv zamestnancom: každý tím chcel byť „na čele“ klastra a kompletne ho riadiť, čo by mohlo spôsobiť úplný kolaps, keďže tímy sú od seba v podstate nezávislé.
Čo robiť?
Berúc do úvahy vyššie uvedené a želania tímov byť nezávislejší, urobili sme jednoduchý záver: jeden tím – jeden klaster.
Takže máme druhú:
A potom tretí klaster:
Potom sme začali premýšľať: povedzme, že o rok budú mať naše tímy viac ako jeden klaster? Napríklad v rôznych geografických oblastiach alebo pod kontrolou rôznych poskytovateľov? A niektorí z nich budú chcieť mať možnosť rýchlo nasadiť dočasný klaster na niektoré testy.
Prišiel by plný Kubernetes! Ukázalo sa, že ide o nejaký druh MultiKubernetes.
Všetky tieto klastre zároveň budeme musieť všetci nejako udržiavať, vedieť k nim jednoducho spravovať prístup, ako aj vytvárať nové a vyraďovať staré bez manuálneho zásahu.
Od začiatku našej cesty svetom Kubernetes ubehol nejaký čas a my sme sa rozhodli znovu preskúmať dostupné riešenia. Ukázalo sa, že už na trhu existuje – Rancher 2.2.
V prvej fáze nášho výskumu Rancher Labs už urobilo prvé vydanie verzie 2, ale hoci sa to dalo veľmi rýchlo zvýšiť spustením kontajnera bez externých závislostí s niekoľkými parametrami alebo použitím oficiálnej tabuľky HELM, zdalo sa to hrubé. a nevedeli sme, či sa môžeme spoľahnúť na toto rozhodnutie, či sa rozvinie alebo rýchlo opustí. Paradigma cluster = clicks v samotnom UI nám tiež nevyhovovala a nechceli sme sa viazať na RKE, keďže ide o dosť úzko zameraný nástroj.
Verzia Rancher 2.2 už mala funkčnejší vzhľad a spolu s predchádzajúcimi mala hneď niekoľko zaujímavých funkcií, ako napríklad integráciu s mnohými externými poskytovateľmi, jednotné miesto distribúcie práv a súborov kubeconfig, spustenie kubectl obrázok s vašimi právami v používateľskom rozhraní, vnorené menné priestory aka projekty.
Okolo Ranchera 2 už vznikla aj komunita a na jej správu bol vytvorený poskytovateľ s názvom HashiCorp Terraform, ktorý nám pomohol dať všetko dokopy.
Čo sa stalo
Výsledkom bolo, že sme skončili s jedným malým klastrom so systémom Rancher, ktorý je prístupný všetkým ostatným klastrom, ako aj mnohým klastrom, ktoré sú k nemu pripojené, pričom prístup ku ktorémukoľvek z nich môže byť udelený rovnako jednoducho ako pridanie používateľa do adresára ldap, bez ohľadu na kde sa nachádza a aké zdroje poskytovateľa využíva.
Pomocou gitlab-ci a Terraform bol vytvorený systém, ktorý umožňuje vytvoriť klaster ľubovoľnej konfigurácie v cloudových poskytovateľoch alebo našej vlastnej infraštruktúre a pripojiť ich k Rancherovi. Všetko sa to deje v štýle IaC, kde je každý klaster popísaný úložiskom a jeho stav je verzovaný. Zároveň je väčšina modulov pripojená z externých úložísk, takže zostáva len odovzdať premenné alebo opísať vašu vlastnú konfiguráciu pre inštancie, čo pomáha znižovať percento opakovania kódu.
Samozrejme, naša cesta sa ani zďaleka nekončí a stále je pred nami veľa zaujímavých úloh, ako napríklad jeden pracovný bod s protokolmi a metrikami ľubovoľných klastrov, sieť služieb, gitopy na správu záťaže v multiklastri a mnoho ďalších. Dúfame, že vás naša skúsenosť zaujme!
Článok napísali A. Antipov, A. Ganush, Platform Engineers.
Zdroj: hab.com