Hej Habr!
Ni reprezentas la Exness-platformteamon. Antaŭe, niaj kolegoj jam skribis artikolon pri . Hodiaŭ ni volas dividi nian sperton pri migrado de servoj al Kubernetes.
Komence, ni proponas al vi kelkajn nombrojn por pli bone kompreni tion, kio estos diskutita:
- Nia disvolva fako konsistas el pli ol 100 homoj, inkluzive de pli ol 10 malsamaj teamoj kun memprovizaj QA, DevOps kaj Scrum-procezoj. Disvolva stako - Python, PHP, C++, Java kaj Golang.
- La grandeco de la testaj kaj produktadmedioj estas proksimume 2000 ujoj ĉiu. Ili funkcias Rancher v1.6 per sia propra virtualigo kaj sub VMware.
Motivacio
Kiel oni diras, nenio daŭras eterne, kaj Rancher anoncis la finon de subteno por versio 1.6 antaŭ sufiĉe longa tempo. Jes, en pli ol tri jaroj ni lernis kiel prepari ĝin kaj solvi problemojn, kiuj aperas, sed pli kaj pli ofte ni alfrontas problemojn, kiuj neniam estos korektitaj. Rancher 1.6 ankaŭ havas ositan sistemon por eldonado de rajtoj, kie vi povas aŭ fari preskaŭ ĉion aŭ nenion.
Kvankam proprieta virtualigo disponigis pli grandan kontrolon de datumstokado kaj ĝia sekureco, ĝi trudis funkciigadkostojn kiuj estis malfacile akcepteblaj surbaze de la konstanta kresko de la firmao, la nombro da projektoj kaj postuloj por ili.
Ni volis sekvi IaC-normojn kaj, se necese, akiri kapaciton rapide, en ajna geografia loko kaj sen vendisto-seruro, kaj ankaŭ povi rapide forlasi ĝin.
unuaj paŝoj
Antaŭ ĉio, ni volis fidi je modernaj teknologioj kaj solvoj, kiuj permesus al teamoj havi pli rapidan disvolvan ciklon kaj minimumigi operaciajn kostojn por interagado kun la platformo, kiu provizas potencon.
Kompreneble, la unua afero, kiu venis en nian menson, estis Kubernetes, sed ni ne ekscitiĝis kaj iom esploris por vidi ĉu ĝi estas la ĝusta elekto. Ni taksis nur malfermfontajn solvojn, kaj en maljusta batalo, Kubernetes senkondiĉe venkis.
Poste venis la demando pri elekto de ilo por krei aretojn. Ni komparis la plej popularajn solvojn: kops, kubespray, kubeadm.
Komence, kubeadm ŝajnis al ni tro komplika vojo, prefere kiel ia inventinto de "biciklo", kaj kops ne havis sufiĉe da fleksebleco.
Kaj la gajninto estis:
Ni komencis eksperimenti kun nia propra virtualigo kaj AWS, provante rekrei ion proksimume similan al nia antaŭa mastrumado de rimedoj, kie ĉiuj dividis la saman "areton". Kaj nun ni havas nian unuan areton de 10 malgrandaj virtualaj maŝinoj, kelkaj el kiuj troviĝas en AWS. Ni komencis provi migri teamojn tien, ĉio ŝajnis esti "bona", kaj la rakonto povus esti finita, sed...
Unuaj Problemoj
Ansible estas sur kio kubespray estas konstruita, ĝi ne estas ilo kiu permesas vin sekvi IaC: dum komisiado/malfunkciado de nodoj, io konstante misfunkciis kaj ia interveno estis postulata, kaj kiam oni uzis malsamajn OS-ojn, la ludlibro kondutis alimaniere. . Ĉar la nombro da teamoj kaj nodoj en la areto kreskis, ni komencis rimarki, ke la ludlibro daŭris pli kaj pli longe por kompletigi, kaj kiel rezulto, nia rekordo estis 3,5 horoj, kio pri via? 🙂
Kaj ŝajnas, ke kubespray estas nur Ansible, kaj ĉio estas klara unuavide, sed:
Komence de la vojaĝo, la tasko estis lanĉi kapablojn nur en AWS kaj pri virtualigo, sed poste, kiel ofte okazas, la postuloj ŝanĝiĝis.
En lumo de tio, evidentiĝis, ke nia malnova ŝablono kunigi rimedojn en unu orkestradsistemon ne taŭgas - en la kazo kie la aretoj estas tre malproksimaj kaj estas administritaj de malsamaj provizantoj.
Plu pli. Kiam ĉiuj teamoj laboras ene de la sama areto, diversaj servoj kun malĝuste instalitaj NodeSelectors povis flugi al la "fremda" gastiganto de alia teamo kaj utiligi rimedojn tie, kaj se makulo estis metita, estis konstantaj petoj ke unu aŭ alia servo ne funkciis, ne distribuata ĝuste pro homa faktoro. Alia problemo estis kalkuli la koston, precipe konsiderante la problemojn en distribuado de servoj tra nodoj.
Aparta rakonto estis la emisio de rajtoj al dungitoj: ĉiu teamo volis esti "ĉe la kapo" de la areto kaj tute administri ĝin, kio povus kaŭzi kompletan kolapson, ĉar la teamoj estas esence sendependaj unu de la alia.
Kiel esti?
Konsiderante la suprajn kaj la dezirojn de la teamoj esti pli sendependaj, ni faris simplan konkludon: unu teamo - unu areto.
Do ni ricevis duan:
Kaj tiam la tria areto:
Tiam ni ekpensis: ni diru, ke post unu jaro niaj teamoj havos pli ol unu areton? En malsamaj geografiaj areoj, ekzemple, aŭ sub la kontrolo de malsamaj provizantoj? Kaj iuj el ili volos povi rapide disfaldi provizoran areton por iuj provoj.
Plena Kubernetes venus! Ĉi tio estas ia MultiKubernetes, rezultas.
Samtempe, ni ĉiuj devos iel konservi ĉiujn ĉi tiujn aretojn, povi facile administri aliron al ili, kaj ankaŭ krei novajn kaj malfunkciigi malnovajn sen mana interveno.
Iom da tempo pasis ekde la komenco de nia vojaĝo en la mondo de Kubernetes, kaj ni decidis reekzameni la disponeblajn solvojn. Montriĝis, ke ĝi jam ekzistas sur la merkato - Rancher 2.2.
En la unua etapo de nia esplorado, Rancher Labs jam faris la unuan eldonon de versio 2, sed kvankam ĝi povus esti levita tre rapide lanĉante ujon sen eksteraj dependecoj kun kelkaj parametroj aŭ uzante la oficialan HELM Chart, ĝi ŝajnis kruda. al ni, kaj ni ne sciis, ĉu ni povus fidi je ĉi tiu decido, ĉu ĝi estos disvolvita aŭ rapide forlasita. La paradigmo cluster = klakoj en la UI mem ankaŭ ne konvenis al ni, kaj ni ne volis ligi al RKE, ĉar ĝi estas sufiĉe malvaste fokusita ilo.
Versio Rancher 2.2 jam havis pli realigeblan aspekton kaj, kune kun la antaŭaj, havis amason da interesaj funkcioj el la skatolo, kiel integriĝo kun multaj eksteraj provizantoj, ununura punkto de distribuo de rajtoj kaj kubeconfig dosierojn, lanĉo de kubectl. bildo kun viaj rajtoj en la UI, nestitaj nomspacoj alinome projektoj.
Estis ankaŭ komunumo jam formita ĉirkaŭ Rancher 2, kaj provizanto nomita HashiCorp Terraform estis kreita por administri ĝin, kio helpis nin kunmeti ĉion.
Kio okazis
Kiel rezulto, ni finis kun unu malgranda areto prizorganta Rancher, alirebla por ĉiuj aliaj aretoj, same kiel multaj aretoj ligitaj al ĝi, aliro al iu ajn el kiuj povas esti donita tiel simple kiel aldoni uzanton al la ldap-dosierujo, sendepende de kie ĝi situas kaj kiujn rimedojn de provizanto ĝi uzas.
Uzante gitlab-ci kaj Terraform, sistemo estis kreita, kiu ebligas al vi krei aron de iu ajn agordo en nubaj provizantoj aŭ nia propra infrastrukturo kaj konekti ilin al Rancher. Ĉio ĉi estas farita en la IaC-stilo, kie ĉiu areto estas priskribita de deponejo, kaj ĝia stato estas versionita. Samtempe, plej multaj moduloj estas konektitaj de eksteraj deponejoj, tiel ke ĉio, kio restas, estas pasi variablojn aŭ priskribi vian kutiman agordon por ekzemploj, kio helpas redukti la procenton de koda ripeto.
Kompreneble, nia vojaĝo estas malproksima de finita kaj ankoraŭ estas multaj interesaj taskoj antaŭen, kiel unuopa laborpunkto kun protokoloj kaj metrikoj de iuj aretoj, servomaŝo, gitops por administri ŝarĝojn en multgrupo kaj multe pli. Ni esperas, ke vi trovos nian sperton interesa!
La artikolon verkis A. Antipov, A. Ganush, Platformaj Inĝenieroj.
fonto: www.habr.com