Ehi Habr!
Rappresentemu a squadra di a piattaforma Exness. Nanzu, i nostri culleghi digià scrittu un articulu circa . Oghje vulemu sparte a nostra sperienza di migrazione di servizii à Kubernetes.
Per principià, vi prupunemu qualchi numeri per una megliu capiscenu di ciò chì serà discutitu:
- U nostru dipartimentu di sviluppu hè custituitu da più di 100 persone, cumprese più di 10 squadre diverse cù processi QA, DevOps è Scrum autosufficienti. Stack di sviluppu - Python, PHP, C++, Java è Golang.
- A dimensione di l'ambienti di prova è di produzzione hè di circa 2000 cuntenituri ognunu. Eseguinu Rancher v1.6 nantu à a so propria virtualizazione è sottu VMware.
Motivazione
Comu dicenu, nunda ùn dura per sempre, è Rancher hà annunziatu a fine di u supportu per a versione 1.6 un bellu pezzu fà. Iè, in più di trè anni, avemu amparatu à preparà è risolve i prublemi chì si presentanu, ma più è più spessu avemu affruntatu prublemi chì ùn saranu mai curretti. Rancher 1.6 hà ancu un sistema ossificatu per l'emissione di diritti, induve pudete fà quasi tuttu o nunda.
Ancu s'è a virtualizazione proprietaria hà furnitu un cuntrollu più grande di l'almacenamiento di dati è a so sicurità, hà impostu costi operativi chì eranu difficiuli d'accettà datu a crescita constante di a cumpagnia, u numeru di prughjetti è esigenze per elli.
Vulemu seguità i normi IaC è, se ne necessariu, ottene a capacità rapidamente, in ogni locu geugraficu è senza serratura di u venditore, è ancu pudè abbandunà rapidamente.
primu passu
Prima di tuttu, avemu vulsutu cunfidendu tecnulugii muderni è soluzioni chì permettenu à e squadre di avè un ciculu di sviluppu più veloce è minimizzà i costi operativi per interagisce cù a piattaforma chì furnisce u putere.
Di sicuru, u primu chì hè vinutu à a nostra mente era Kubernetes, ma ùn avemu micca entusiasmu è avemu fattu un pocu di ricerca per vede s'ellu era a scelta bona. Avemu evaluatu solu suluzioni opensource, è in una battaglia ingiusta, Kubernetes hà vintu incondizionatamente.
Dopu hè stata a quistione di sceglie un strumentu per creà clusters. Avemu paragunatu i suluzioni più populari: kops, kubespray, kubeadm.
Per principià, kubeadm ci pareva esse un caminu troppu cumplicatu, piuttostu cum'è una spezia d'inventore di una "bicicletta", è kops ùn anu micca abbastanza flessibilità.
È u vincitore era:
Avemu cuminciatu à sperimentà a nostra propria virtualizazione è AWS, pruvendu à ricreà qualcosa quasi simile à u nostru mudellu di gestione di risorse precedente, induve tutti spartevanu u stessu "cluster". È avà avemu u nostru primu cluster di 10 picculi macchine virtuali, un coppiu di quale sò situati in AWS. Avemu cuminciatu à pruvà à migrà e squadre quì, tuttu pareva esse "bonu", è a storia puderia esse finita, ma...
Primi prublemi
Ansible hè ciò chì kubespray hè custruitu, ùn hè micca un strumentu chì vi permette di seguità IaC: quandu i nodi di cumissioni / decommissioning, qualcosa andava constantemente sbagliatu è era necessariu un tipu d'intervenzione, è quandu si usava diversi OS, u playbook si comportava in modu diversu. . Cume u numeru di squadre è nodi in u cluster criscenu, avemu cuminciatu à nutà chì u playbook pigghiava più è più longu per esse cumpletu, è in u risultatu, u nostru record era 3,5 ore, chì ne di u vostru? 🙂
È pare chì kubespray hè solu Ansible, è tuttu hè chjaru à prima vista, ma:
À u principiu di u viaghju, u compitu era di lancià capacità solu in AWS è nantu à a virtualizazione, ma dopu, cum'è spessu succede, i bisogni cambiavanu.
In vista di questu, hè diventatu chjaru chì u nostru vechju mudellu di cumminà risorse in un sistema di orchestrazione ùn era micca adattatu - in u casu induve i clusters sò assai remoti è sò gestiti da diversi fornituri.
In più di più. Quandu tutti i squadre travaglianu in u stessu cluster, diversi servizii cù NodeSelectors installati incorrectamente puderanu volà à l'ospiti "stranieri" di un altru squadra è utilizendu risorse quì, è se a contaminazione hè stata stabilita, ci sò richieste constanti chì un o un altru serviziu ùn funziona micca, micca distribuitu currettamente per via di u fattore umanu. Un altru prublema era di calculà u costu, soprattuttu cunsiderà i prublemi in a distribuzione di servizii in i nodi.
Una storia separata era l'emissione di diritti à l'impiegati: ogni squadra vulia esse "à u capu" di u cluster è gestione completamente, chì puderia causà un colapsu cumpletu, postu chì e squadre sò basamente indipendenti l'una di l'altru.
Cumu serà?
Pigliendu à u sopra è i desideri di e squadre per esse più indipendenti, avemu fattu una cunclusione simplice: una squadra - un cluster.
Allora avemu una seconda:
È dopu u terzu cluster:
Tandu avemu principiatu à pinsà : diciamu chì in un annu i nostri squadre averà più di un cluster ? In diverse zoni geografiche, per esempiu, o sottu u cuntrollu di diversi fornituri? È alcuni di elli volenu esse capace di implementà rapidamente un cluster temporale per qualchi teste.
Kubernetes cumpletu veneranu! Questu hè un tipu di MultiKubernetes, risulta.
À u listessu tempu, tutti avemu bisognu di mantene in qualchì modu tutti questi clusters, esse capace di gestisce facilmente l'accessu à elli, è ancu di creà novi è disfunzione di i vechji senza intervenzione manuale.
Qualchì tempu hè passatu da u principiu di u nostru viaghju in u mondu di Kubernetes, è avemu decisu di riesaminà e soluzioni dispunibili. Hè risultatu chì esiste digià in u mercatu - Rancher 2.2.
À a prima tappa di a nostra ricerca, Rancher Labs avia digià fattu a prima versione di a versione 2, ma ancu s'ellu puderia esse risuscitatu assai rapidamente lanciando un cuntinuu senza dependenze esterne cù un paru di parametri o utilizendu u Chart HELM ufficiale, pareva crudu. à noi, è ùn sapemu micca s'ellu ci pudemu cunfidassi nantu à sta decisione s'ellu serà sviluppatu o rapidamente abbandunatu. U paradigma cluster = clics in l'UI stessu ùn ci cunvene micca, è ùn vuliamu micca esse ligatu à RKE, postu chì hè un strumentu piuttostu strettu.
A versione Rancher 2.2 hà digià avutu un aspettu più praticabile è, inseme cù i precedenti, hà avutu una mansa di funzioni interessanti fora di a scatula, cum'è l'integrazione cù parechji fornituri esterni, un puntu unicu di distribuzione di diritti è i fugliali kubeconfig, lanciando un kubectl. imagine cù i vostri diritti in l'UI, spazii di nomi nidificati aka prughjetti.
Ci era ancu una cumunità digià formata intornu à Rancher 2, è un fornitore chjamatu HashiCorp Terraform hè statu creatu per gestisce, chì ci hà aiutatu à mette tuttu inseme.
Chì hè accadutu
In u risultatu, avemu finitu cun un picculu cluster in esecuzione Rancher, accessibile à tutti l'altri clusters, è ancu parechji clusters cunnessi à questu, l'accessu à qualsiasi di quale pò esse cuncessu cum'è l'aghjustà un utilizatore à u cartulare ldap, indipendentemente da induve si trova è quale risorse di u fornitore usa.
Utilizendu gitlab-ci è Terraform, hè statu creatu un sistema chì vi permette di creà un cluster di qualsiasi cunfigurazione in i fornitori di nuvola o a nostra propria infrastruttura è cunnette à Rancher. Tuttu chistu hè fattu in u stilu IaC, induve ogni cluster hè descrittu da un repository, è u so statu hè versionatu. À u listessu tempu, a maiò parte di i moduli sò cunnessi da i repositori esterni in modu chì tuttu ciò chì resta hè di passà variabili o di descriverà a vostra cunfigurazione persunalizata per l'istanze, chì aiuta à riduce u percentuale di ripetizione di codice.
Di sicuru, u nostru viaghju hè luntanu da esse finitu è ci sò sempre assai travaglii interessanti avanti, cum'è un unicu puntu di travagliu cù logs è metriche di qualsiasi clusters, mesh di serviziu, gitops per a gestione di carichi in un multicluster è assai più. Speremu chì truvate a nostra sperienza interessante!
L'articulu hè statu scrittu da A. Antipov, A. Ganush, Platform Engineers.
Source: www.habr.com