Aupa Habr!
Exness plataformako taldea ordezkatzen dugu. Aurretik, gure lankideek artikulu bat idatzi zuten jada . Gaur zerbitzuak Kubernetesera migratzeko esperientzia partekatu nahi dugu.
Hasteko, zenbaki batzuk eskaintzen dizkizugu eztabaidatuko dena hobeto ulertzeko:
- Gure garapen-saila 100 pertsona baino gehiagok osatzen dute, QA, DevOps eta Scrum prozesu autosufizienteak dituzten 10 talde ezberdin baino gehiago barne. Garapen pila - Python, PHP, C++, Java eta Golang.
- Proba eta ekoizpen inguruneen tamaina 2000 ontzi ingurukoa da. Rancher v1.6 exekutatzen ari dira beren birtualizazioan eta VMware azpian.
Motibazioa
Esaten dutenez, ezer ez da betiko, eta Rancherrek 1.6 bertsioaren laguntzaren amaiera iragarri zuen duela dezente. Bai, hiru urte baino gehiagotan ikasi dugu nola prestatu eta sortzen diren arazoak konpontzen, baina gero eta maizago inoiz konponduko ez diren arazoen aurrean aurkitzen gara. Rancher 1.6-k eskubideak jaulkitzeko sistema bat ere badu, non ia dena edo ezer egin dezakezun.
Jabedun birtualizazioak datuen biltegiratzeari eta haien segurtasunari buruzko kontrol handiagoa ematen bazuen ere, onartzeko zailak ziren operazio-kostuak ezartzen zituen, enpresaren etengabeko hazkundea, proiektu kopurua eta horien eskakizunak kontuan hartuta.
IaC estandarrak jarraitu nahi genituen eta, behar izanez gero, ahalmena azkar lortu, edozein kokapen geografikotan eta saltzaileen blokeorik gabe, eta, gainera, azkar bertan behera utzi ahal izan.
Lehen urratsak
Lehenik eta behin, teknologia eta soluzio modernoetan oinarritu nahi genuen, taldeek garapen-ziklo azkarragoa izan dezaten eta potentzia ematen duen plataformarekin elkarreragiteko kostu operatiboak minimizatzeko.
Noski, burura etorri zitzaigun lehenengo gauza Kubernetes izan zen, baina ez ginen ilusiorik egin eta ikerketa txiki bat egin genuen aukera egokia zen ikusteko. Kode irekiko irtenbideak soilik ebaluatu genituen, eta bidegabeko borroka batean, Kubernetesek baldintzarik gabe irabazi zuen.
Jarraian, klusterrak sortzeko tresna aukeratzearen galdera etorri zen. Irtenbide ezagunenak alderatu ditugu: kops, kubespray, kubeadm.
Hasteko, kubeadm bide korapilatsuegia iruditu zitzaigun, βbizikletaβ baten asmatzaile moduko bat bezala, eta kops-ek ez zuen nahikoa malgutasunik.
Eta irabazlea izan zen:
Gure birtualizazioarekin eta AWSarekin esperimentatzen hasi ginen, gure aurreko baliabideen kudeaketa ereduaren antzeko zerbait birsortu nahian, non guztiek "kluster" bera partekatzen zuten. Eta orain 10 makina birtual txikiz osatutako lehen multzoa dugu, horietako pare bat AWSn kokatuta. Taldeak hara migratzen saiatzen hasi ginen, dena βonaβ zegoela zirudien, eta istorioa amaitu zitekeela, baina...
Lehen arazoak
Ansible da kubespray eraikitzen dena, ez da IaC jarraitzea ahalbidetzen duen tresna bat: nodoak martxan jartzean/desaktibatzen direnean, zerbait etengabe gaizki joan zen eta nolabaiteko esku-hartzea behar zen, eta sistema eragile desberdinak erabiltzean, jolas-liburua ezberdin portatu zen. . Klusterreko talde eta nodo kopurua hazten joan zen heinean, playbook-a gero eta luzeago behar zela osatzeari ekin genion, eta, ondorioz, gure errekorra 3,5 ordukoa zen, eta zurearekin? π
Eta badirudi kubespray Ansible besterik ez dela, eta dena argi dago lehen begiratuan, baina:
Bidaiaren hasieran, zeregina AWS-n eta birtualizazioan soilik gaitasunak abiaraztea zen, baina gero, askotan gertatzen den bezala, baldintzak aldatu egin ziren.
Horren harira, argi geratu zen baliabideak orkestrazio-sistema batean konbinatzeko gure eredu zaharra ez zela egokia, klusterrak oso urrun dauden eta hornitzaile ezberdinek kudeatzen dituzten kasuetan.
Gainera. Talde guztiek kluster berean lan egiten dutenean, oker instalatutako NodeSelectors duten hainbat zerbitzuk beste talde baten ostalari "atzerriko" batera hegan egin dezakete eta bertan baliabideak erabil ditzakete, eta kutsadura ezarriz gero, etengabeko eskaerak zeuden zerbitzu bat edo beste funtzionatzen ez zuelako. ez da behar bezala banatu giza faktorea dela eta. Beste arazo bat kostua kalkulatzea zen, batez ere zerbitzuak nodoen artean banatzeko arazoak kontuan hartuta.
Istorio bereizi bat izan zen langileei eskubideak ematea: talde bakoitzak klusterraren "buruan" egon eta guztiz kudeatu nahi zuen, eta horrek erabateko kolapsoa eragin zezakeen, taldeak bata bestearengandik independenteak baitira funtsean.
Zer egin nahi duzu?
Aurrekoa eta taldeen burujabeagoak izateko nahia kontuan hartuta, ondorio sinple bat atera dugu: talde bat - kluster bat.
Beraz, bigarren bat lortu dugu:
Eta gero hirugarren multzoa:
Orduan pentsatzen hasi ginen: demagun urtebete barru gure taldeek kluster bat baino gehiago izango dutela? Eremu geografiko ezberdinetan, adibidez, edo hornitzaile ezberdinen kontrolpean? Eta horietako batzuek proba batzuetarako aldi baterako kluster bat azkar zabaldu ahal izango dute.
Kubernetes osoa etorriko litzateke! Hau MultiKubernetes moduko bat da, antza.
Aldi berean, guztiok nolabait kluster horiek guztiak mantendu beharko ditugu, haietarako sarbidea erraz kudeatu ahal izango ditugu, baita berriak sortu eta zaharrak eskuz esku-hartzerik gabe kendu ere.
Denbora pixka bat igaro da Kubernetesen munduan gure bidaia hasi zenetik, eta eskura ditugun irtenbideak berriro aztertzea erabaki genuen. Agertu zen dagoeneko merkatuan badagoela - Rancher 2.2.
Gure ikerketaren lehen fasean, Rancher Labsek 2. bertsioaren lehen bertsioa egina zuen jada, baina parametro pare batekin kanpoko menpekotasunik gabeko edukiontzi bat abiaraziz edo HELM Chart ofiziala erabiliz oso azkar planteatu zitekeen arren, gordina zirudien. guri, eta ez genekien erabaki honetan garatuko den ala azkar abandonatuko ote zen fidatu gaitezkeen. Cluster = clicks paradigma UI-n bertan ere ez zitzaigun egokitu, eta ez genuen RKEra lotu nahi izan, fokatutako tresna nahiko estua baita.
Rancher 2.2 bertsioak jada itxura egingarriagoa zuen eta, aurrekoekin batera, ezaugarri interesgarri mordoa zituen kutxatik kanpo, hala nola, kanpoko hornitzaile askorekin integratzea, eskubideen banaketa puntu bakarra eta kubeconfig fitxategiak, kubectl bat abiarazteko. irudia zure eskubideekin UI-n, habiaraturiko izen-espazioak aka proiektuak.
Rancher 2-ren inguruan jadanik eratutako komunitate bat ere bazegoen, eta hura kudeatzeko HashiCorp Terraform izeneko hornitzailea sortu zen, eta horrek dena bateratzen lagundu zigun.
Zer gertatu zen
Ondorioz, Rancher exekutatzen ari den kluster txiki batekin amaitu genuen, beste kluster guztientzat eskuragarria, baita hari konektatutako kluster askori ere, eta horietako edozeinetarako sarbidea eman daiteke erabiltzaile bat ldap direktoriora gehitzea besterik gabe, edozein dela ere. non dagoen eta zein hornitzailearen baliabideak erabiltzen dituen.
Gitlab-ci eta Terraform erabiliz, hodeiko hornitzaileetan edo gure azpiegitura propioetan edozein konfigurazio kluster bat sortzeko eta Rancher-era konektatzeko aukera ematen duen sistema bat sortu zen. Hori guztia IaC estiloan egiten da, non kluster bakoitza biltegi batek deskribatzen duen, eta bere egoera bertsionatu egiten da. Aldi berean, modulu gehienak kanpoko biltegietatik konektatzen dira, beraz, geratzen dena aldagaiak pasatzea edo zure konfigurazio pertsonalizatua deskribatzea besterik ez da, eta horrek kode errepikapenaren ehunekoa murrizten laguntzen du.
Jakina, gure ibilbidea oso urrun dago eta zeregin interesgarri asko daude aurretik, hala nola lan-puntu bakarra edozein klusterren erregistro eta neurgailuekin, zerbitzu-sareak, kargak multikluster batean kudeatzeko gitop-ak eta askoz gehiago. Espero dugu gure esperientzia interesgarria izatea!
Artikulua A. Antipov, A. Ganush, Platform Engineers-ek idatzi dute.
Iturria: www.habr.com