Szia Habr!
Az Exness platform csapatát képviseljük. Korábban kollégáink már írtak cikket erről . Ma szeretnénk megosztani tapasztalatainkat a szolgáltatások Kubernetesre történő migrálásával kapcsolatban.
Kezdésként ajánlunk néhány számot, hogy jobban megértse, miről lesz szó:
- Fejlesztési részlegünk több mint 100 főből áll, köztük több mint 10 különböző, önellátó QA, DevOps és Scrum folyamatokkal rendelkező csapatból. Fejlesztési verem - Python, PHP, C++, Java és Golang.
- A teszt- és gyártási környezet mérete egyenként körülbelül 2000 konténer. A Rancher v1.6-ot futtatják saját virtualizációjukon és VMware alatt.
motiváció
Ahogy mondani szokták, semmi sem tart örökké, és a Rancher már régen bejelentette, hogy véget ért az 1.6-os verzió támogatása. Igen, több mint három év alatt megtanultuk, hogyan készítsük elő, és hogyan oldjuk meg a felmerülő problémákat, de egyre gyakrabban találkozunk olyan problémákkal, amelyeket soha nem lehet helyrehozni. A Rancher 1.6-ban is van egy csontosított rendszer a jogok kiadására, ahol vagy szinte mindent megtehet, vagy semmit.
A szabadalmaztatott virtualizáció ugyan nagyobb kontrollt biztosított az adattárolás és annak biztonsága felett, de a cég folyamatos növekedése, a projektek száma és a velük szemben támasztott követelmények miatt nehezen vállalható működési költségeket jelentett.
Szerettük volna követni az IaC szabványokat, és szükség esetén gyorsan, bármilyen földrajzi helyen, szállítói zár nélkül kapni kapacitást, és gyorsan lemondani is.
Az első lépések
Mindenekelőtt olyan modern technológiákra és megoldásokra szerettünk volna támaszkodni, amelyek lehetővé teszik a csapatok számára, hogy gyorsabb fejlesztési ciklusban dolgozzanak, és minimálisra csökkentsék a működési költségeket az energiát biztosító platformmal való együttműködés során.
Természetesen elsőre a Kubernetes jutott eszünkbe, de nem izgultunk, és kicsit utánajártunk, hogy jó-e a választás. Kizárólag nyílt forráskódú megoldásokat értékeltünk, és tisztességtelen csatában a Kubernetes feltétel nélkül nyert.
Ezután következett a klaszterek létrehozására szolgáló eszköz kiválasztásának kérdése. Összehasonlítottuk a legnépszerűbb megoldásokat: kops, kubespray, kubeadm.
Kezdetben a kubeadm túl bonyolult útnak tűnt számunkra, inkább amolyan „bicikli” feltalálójának, és a kops nem volt elég rugalmas.
A nyertes pedig ez lett:
Kísérletezni kezdtünk a saját virtualizációnkkal és AWS-vel, megpróbálva újra létrehozni valamit, ami nagyjából hasonló a korábbi erőforrás-kezelési mintánkhoz, ahol mindenki ugyanazt a „fürtöt” osztja. És most megvan az első 10 kis virtuális gépből álló fürtünk, amelyek közül néhány az AWS-ben található. Elkezdtünk csapatokat migrálni oda, minden „jónak” tűnt, és a sztori befejezhető, de...
Első Problémák
Az Ansible az, amire a kubespray épül, nem egy olyan eszköz, amely lehetővé teszi az IaC követését: a csomópontok üzembe helyezésekor/leszerelésekor valami állandóan elromlott, és valamilyen beavatkozásra volt szükség, illetve különböző operációs rendszerek használatakor a játékkönyv másként viselkedett. . Ahogy a klaszterben lévő csapatok és csomópontok száma nőtt, azt vettük észre, hogy a játékfüzet elkészítése egyre tovább tart, és ennek eredményeként a rekordunk 3,5 óra volt, mi a helyzet a tiéddel? 🙂
És úgy tűnik, hogy a kubespray csak Ansible, és első pillantásra minden világos, de:
Az út elején az volt a feladat, hogy csak AWS-ben és virtualizációs kapacitásokat indítsanak el, de aztán, ahogy az lenni szokott, megváltoztak a követelmények.
Ennek fényében világossá vált, hogy a régi mintánk, amely szerint az erőforrásokat egy hangszerelési rendszerbe egyesítettük, nem volt megfelelő - abban az esetben, ha a klaszterek nagyon távol vannak, és különböző szolgáltatók kezelik őket.
Tovább tovább. Amikor minden csapat ugyanazon a klaszteren belül dolgozik, a különböző szolgáltatások a helytelenül telepített NodeSelector-okkal egy másik csapat „idegen” gazdagépére repülhettek, és ott hasznosították az erőforrásokat, és ha szennyeződés történt, állandó kérések érkeztek, hogy egyik vagy másik szolgáltatás nem működik, emberi tényező miatt nem oszlik meg megfelelően. Egy másik probléma a költségek kiszámítása volt, különös tekintettel a szolgáltatások csomópontok közötti elosztásának problémáira.
Külön sztori volt a munkavállalók jogainak kiadása: minden csapat a klaszter „élén” akart állni és azt teljesen menedzselni, ami akár teljes összeomlást is okozhat, hiszen a csapatok alapvetően függetlenek egymástól.
Mit kell tenni?
Figyelembe véve a fentieket és a csapatok függetlenebb akaratát, egy egyszerű következtetést vontunk le: egy csapat - egy klaszter.
Tehát kaptunk egy másodikat:
És akkor a harmadik klaszter:
Aztán elkezdtünk gondolkodni: tegyük fel, hogy egy év múlva több klaszter lesz a csapatainkban? Például különböző földrajzi területeken, vagy különböző szolgáltatók ellenőrzése alatt? Néhányuk pedig szeretne gyorsan telepíteni egy ideiglenes fürtöt bizonyos tesztekhez.
Teljes Kubernetes jönne! Ez egyfajta MultiKubernetes, kiderül.
Ugyanakkor mindannyiunknak valamilyen módon karban kell tartanunk ezeket a klasztereket, könnyen kezelnünk kell a hozzáférésüket, valamint manuális beavatkozás nélkül újakat hozzunk létre és le kell szerelnünk a régieket.
A Kubernetes világában tett utazásunk kezdete óta eltelt egy kis idő, és úgy döntöttünk, hogy újra megvizsgáljuk az elérhető megoldásokat. Kiderült, hogy már létezik a piacon - Rancher 2.2.
Kutatásunk első szakaszában a Rancher Labs már elkészítette a 2-es verzió első kiadását, de bár egy külső függőségek nélküli konténer elindításával néhány paraméterrel vagy a hivatalos HELM Chart használatával nagyon gyorsan fel lehetett emelni, ez durvának tűnt. nekünk, és nem tudtuk, hogy támaszkodhatunk-e erre a döntésre, hogy kidolgozzák vagy gyorsan feladják. A cluster = clicks paradigma magában az UI-ban szintén nem jött be nekünk, és nem akartunk az RKE-hez kötődni, mivel ez egy meglehetősen szűk fókuszú eszköz.
A Rancher 2.2-es verzió már működőképes megjelenésű, és a korábbiakkal együtt egy csomó érdekes funkciót tartalmazott, mint például a sok külső szolgáltatóval való integráció, a jogok és a kubeconfig fájlok egyetlen terjesztési pontja, a kubectl elindítása kép a felhasználói felületen meglévő jogaival, beágyazott névterek, más néven projektek.
A Rancher 2 körül már kialakult egy közösség is, ennek menedzselésére pedig egy HashiCorp Terraform nevű szolgáltató jött létre, ami segített nekünk mindent összerakni.
Mi történt
Ennek eredményeként egy kis fürtben futott a Rancher, amely elérhető az összes többi klaszter számára, valamint számos, hozzá kapcsolódó fürt számára, amelyek bármelyikéhez hozzáférést biztosíthatunk egyszerűen úgy, hogy hozzáadunk egy felhasználót az ldap könyvtárhoz, függetlenül attól, hogy hol található és melyik szolgáltató erőforrásait használja.
A gitlab-ci és a Terraform segítségével olyan rendszert hoztak létre, amely lehetővé teszi a felhőszolgáltatókban vagy a saját infrastruktúránkban tetszőleges konfigurációjú klaszter létrehozását és a Rancherrel való összekapcsolását. Mindez IaC stílusban történik, ahol minden fürt le van írva egy repository-val, és az állapota verziószámmal történik. Ugyanakkor a legtöbb modul külső tárolókból csatlakozik, így már csak a változók átadása vagy az egyedi konfiguráció leírása marad hátra, ami segít csökkenteni a kódismétlések százalékos arányát.
Természetesen az utunk még korántsem ért véget, és sok érdekes feladat vár még hátra, mint például egyetlen munkapont a fürtök naplóival és metrikáival, szervizháló, gitopok a terhelések kezelésére egy multiclusterben és még sok más. Reméljük, hogy élményünket érdekesnek találja!
A cikket A. Antipov, A. Ganush, Platform Engineers írta.
Forrás: will.com