Haai Habr!
Ons verteenwoordig die Exness-platformspan. Voorheen het ons kollegas reeds 'n artikel geskryf oor . Vandag wil ons ons ervaring van die migreer van dienste na Kubernetes deel.
Om mee te begin, bied ons u 'n paar syfers vir 'n beter begrip van wat bespreek sal word:
- Ons ontwikkelingsafdeling bestaan uit 100+ mense, insluitend meer as 10 verskillende spanne met selfversorgende QA-, DevOps- en Scrum-prosesse. Ontwikkelingsstapel - Python, PHP, C++, Java en Golang.
- Die grootte van die toets- en produksie-omgewings is ongeveer 2000 houers elk. Hulle loop Rancher v1.6 op hul eie virtualisasie en onder VMware.
Motivering
Soos hulle sê, niks hou vir ewig nie, en Rancher het lank gelede die einde van ondersteuning vir weergawe 1.6 aangekondig. Ja, in meer as drie jaar het ons geleer hoe om dit voor te berei en probleme op te los wat opduik, maar al hoe meer kom ons voor probleme te staan wat nooit reggestel sal word nie. Rancher 1.6 het ook 'n versteende stelsel vir die uitreiking van regte, waar jy amper alles of niks kan doen nie.
Alhoewel eie virtualisasie groter beheer oor databerging en die sekuriteit daarvan verskaf het, het dit bedryfskoste opgelê wat moeilik was om te aanvaar gegewe die konstante groei van die maatskappy, die aantal projekte en vereistes daarvoor.
Ons wou IaC-standaarde volg en, indien nodig, kapasiteit vinnig bekom, in enige geografiese ligging en sonder 'n verkoperslot, en dit ook vinnig kan laat vaar.
Eerste stappe
Eerstens wou ons staatmaak op moderne tegnologieë en oplossings wat spanne in staat sal stel om 'n vinniger ontwikkelingsiklus te hê en bedryfskoste te verminder vir interaksie met die platform wat krag verskaf.
Natuurlik was die eerste ding wat by ons opgekom het Kubernetes, maar ons het nie opgewonde geraak nie en het 'n bietjie navorsing gedoen om te sien of dit die regte keuse was. Ons het slegs opensource-oplossings geëvalueer, en in 'n onregverdige stryd het Kubernetes onvoorwaardelik gewen.
Volgende het die vraag gekom om 'n instrument vir die skep van groepe te kies. Ons het die gewildste oplossings vergelyk: kops, kubespray, kubeadm.
Om mee te begin, het kubeadm vir ons gelyk na 'n te ingewikkelde pad, eerder soos 'n soort uitvinder van 'n "fiets", en kops het nie genoeg buigsaamheid gehad nie.
En die wenner was:
Ons het begin eksperimenteer met ons eie virtualisasie en AWS en probeer om iets te herskep wat min of meer soortgelyk is aan ons vorige hulpbronbestuurspatroon, waar almal dieselfde "cluster" gedeel het. En nou het ons ons eerste groep van 10 klein virtuele masjiene, waarvan 'n paar in AWS geleë is. Ons het begin om spanne daarheen te migreer, alles het gelyk of “goed” was en die storie kon klaar wees, maar...
Eerste probleme
Ansible is waarop kubespray gebou is, dit is nie 'n instrument wat jou toelaat om IaC te volg nie: wanneer nodusse in bedryf gestel/afgestel is, het iets voortdurend verkeerd geloop en 'n soort ingryping was nodig, en wanneer verskillende bedryfstelsels gebruik word, het die speelboek anders opgetree. anders. . Namate die aantal spanne en nodusse in die groep gegroei het, het ons begin agterkom dat die speelboek al hoe langer neem om te voltooi, en gevolglik was ons rekord 3,5 uur, wat van joune? 🙂
En dit lyk of kubespray net Ansible is, en alles is met die eerste oogopslag duidelik, maar:
Aan die begin van die reis was die taak om kapasiteit slegs in AWS en op virtualisering bekend te stel, maar toe, soos dikwels gebeur, het die vereistes verander.
In die lig hiervan het dit duidelik geword dat ons ou patroon van die samevoeging van hulpbronne in een orkestrasiestelsel nie geskik was nie – in die geval waar die klusters baie afgeleë is en deur verskillende verskaffers bestuur word.
Verder meer. Wanneer alle spanne binne dieselfde groep werk, kon verskeie dienste met foutief geïnstalleerde NodeSelectors na die "vreemde" gasheer van 'n ander span vlieg en hulpbronne daar gebruik, en as vlek gestel is, was daar voortdurend versoeke dat die een of ander diens nie werk nie, nie korrek versprei nie as gevolg van menslike faktor. Nog 'n probleem was die berekening van die koste, veral met inagneming van die probleme met die verspreiding van dienste oor nodusse.
'n Afsonderlike storie was die uitreiking van regte aan werknemers: elke span wou "aan die hoof" van die groep wees en dit heeltemal bestuur, wat 'n totale ineenstorting kan veroorsaak, aangesien die spanne basies onafhanklik van mekaar is.
Wat om te doen?
Met inagneming van bogenoemde en die wense van die spanne om meer onafhanklik te wees, het ons 'n eenvoudige gevolgtrekking gemaak: een span - een groepering.
So ons het 'n tweede een:
En dan die derde groep:
Toe begin ons dink: kom ons sê ons spanne sal oor 'n jaar meer as een groep hê? In verskillende geografiese gebiede, byvoorbeeld, of onder die beheer van verskillende verskaffers? En sommige van hulle sal vinnig 'n tydelike groepie vir sommige toetse wil kan ontplooi.
Volle Kubernetes sou kom! Dit is 'n soort MultiKubernetes, blyk dit.
Terselfdertyd sal ons almal op een of ander manier al hierdie groeperings moet in stand hou, toegang daartoe maklik kan bestuur, asook nuwes moet skep en oues moet uitskakel sonder handmatige ingryping.
'n Geruime tyd het verloop sedert die begin van ons reis in die wêreld van Kubernetes, en ons het besluit om die beskikbare oplossings weer te ondersoek. Dit het geblyk dat dit reeds op die mark bestaan - Rancher 2.2.
In die eerste stadium van ons navorsing het Rancher Labs reeds die eerste weergawe van weergawe 2 gemaak, maar hoewel dit baie vinnig verhoog kon word deur 'n houer sonder eksterne afhanklikhede met 'n paar parameters te begin of die amptelike HELM Chart te gebruik, het dit kru gelyk aan ons, en ons het nie geweet of ons op hierdie besluit kan staatmaak of dit ontwikkel of vinnig laat vaar sal word nie. Die cluster = clicks-paradigma in die UI self het ons ook nie gepas nie, en ons wou nie aan RKE gekoppel word nie, aangesien dit 'n taamlik eng gefokusde hulpmiddel is.
Weergawe Rancher 2.2 het reeds 'n meer werkbare voorkoms gehad en, saam met die voriges, 'n klomp interessante kenmerke uit die boks gehad, soos integrasie met baie eksterne verskaffers, 'n enkele verspreidingspunt van regte en kubeconfig-lêers, die bekendstelling van 'n kubectl prent met jou regte in die UI, geneste naamruimtes aka projekte.
Daar was ook 'n gemeenskap wat reeds rondom Rancher 2 gevorm is, en 'n verskaffer genaamd HashiCorp Terraform is geskep om dit te bestuur, wat ons gehelp het om alles saam te stel.
Wat het gebeur
Gevolglik het ons uiteindelik met een klein groepie wat Rancher bestuur, toeganklik vir alle ander groepe, sowel as baie groepe wat daaraan gekoppel is, toegang tot enigeen wat so eenvoudig verleen kan word as om 'n gebruiker by die ldap-gids te voeg, ongeag van waar dit geleë is en watter verskaffer se hulpbronne dit gebruik.
Met behulp van gitlab-ci en Terraform is 'n stelsel geskep wat jou toelaat om 'n groepering van enige konfigurasie in wolkverskaffers of ons eie infrastruktuur te skep en dit aan Rancher te koppel. Dit alles word in die IaC-styl gedoen, waar elke groepering deur 'n bewaarplek beskryf word, en die toestand daarvan word geweer. Terselfdertyd word die meeste modules vanaf eksterne bewaarplekke gekoppel, sodat al wat oorbly, is om veranderlikes deur te gee of jou persoonlike konfigurasie vir gevalle te beskryf, wat help om die persentasie kodeherhaling te verminder.
Natuurlik is ons reis nog lank nie verby nie en daar lê nog baie interessante take voor, soos 'n enkele punt van werk met logs en metrieke van enige groepe, diensnetwerk, gitops vir die bestuur van vragte in 'n multicluster en nog baie meer. Ons hoop jy vind ons ervaring interessant!
Die artikel is geskryf deur A. Antipov, A. Ganush, Platform Engineers.
Bron: will.com