Hei Habr!
Vi representerer Exness-plattformteamet. Tidligere har våre kolleger allerede skrevet en artikkel om . I dag ønsker vi å dele vår erfaring med å migrere tjenester til Kubernetes.
Til å begynne med tilbyr vi deg noen tall for en bedre forståelse av hva som vil bli diskutert:
- Vår utviklingsavdeling består av 100+ personer, inkludert mer enn 10 forskjellige team med selvforsynt QA, DevOps og Scrum prosesser. Utviklingsstabel - Python, PHP, C++, Java og Golang.
- Størrelsen på test- og produksjonsmiljøene er ca. 2000 containere hver. De kjører Rancher v1.6 på sin egen virtualisering og under VMware.
Motivasjon
Som de sier, ingenting varer evig, og Rancher annonserte slutten på støtten for versjon 1.6 for ganske lenge siden. Ja, på mer enn tre år har vi lært å forberede det og løse problemer som oppstår, men oftere og oftere står vi overfor problemer som aldri vil bli rettet. Rancher 1.6 har også et forbenet system for å utstede rettigheter, hvor du enten kan gjøre nesten alt eller ingenting.
Selv om proprietær virtualisering ga større kontroll over datalagring og dens sikkerhet, påførte den driftskostnader som var vanskelige å akseptere gitt selskapets konstante vekst, antall prosjekter og krav til dem.
Vi ønsket å følge IaC-standarder og om nødvendig skaffe kapasitet raskt, uansett geografisk plassering og uten leverandørlås, og også raskt kunne forlate den.
Første trinn
Først av alt ønsket vi å stole på moderne teknologier og løsninger som ville tillate team å ha en raskere utviklingssyklus og minimere driftskostnadene for samhandling med plattformen som gir kraft.
Selvfølgelig var det første vi tenkte på Kubernetes, men vi ble ikke begeistret og gjorde litt research for å se om det var det riktige valget. Vi evaluerte kun åpen kildekode-løsninger, og i en urettferdig kamp vant Kubernetes betingelsesløst.
Deretter kom spørsmålet om å velge et verktøy for å lage klynger. Vi sammenlignet de mest populære løsningene: kops, kubespray, kubeadm.
Til å begynne med virket kubeadm for oss å være en for komplisert sti, snarere som en slags oppfinner av en "sykkel", og kops hadde ikke nok fleksibilitet.
Og vinneren ble:
Vi begynte å eksperimentere med vår egen virtualisering og AWS, og prøvde å gjenskape noe som omtrent ligner på vårt tidligere ressursstyringsmønster, der alle delte samme «klynge». Og nå har vi vår første klynge med 10 små virtuelle maskiner, hvorav et par er plassert i AWS. Vi begynte å prøve å migrere team dit, alt så ut til å være "bra", og historien kunne bli ferdig, men...
Første problemer
Ansible er det kubespray er bygget på, det er ikke et verktøy som lar deg følge IaC: ved idriftsettelse/avvikling av noder gikk noe konstant galt og en slags intervensjon var nødvendig, og når du brukte forskjellige OSer, oppførte playbook seg annerledes. annerledes . Etter hvert som antallet lag og noder i klyngen vokste, begynte vi å legge merke til at det tok lengre og lengre tid å fullføre spilleboken, og som et resultat var rekorden vår på 3,5 timer, hva med din? 🙂
Og det virker som kubespray bare er Ansible, og alt er klart ved første øyekast, men:
I begynnelsen av reisen var oppgaven å lansere kapasiteter kun i AWS og på virtualisering, men så endret kravene seg, som ofte skjer.
I lys av dette ble det klart at vårt gamle mønster med å kombinere ressurser i ett orkestreringssystem ikke var egnet – i tilfellet hvor klyngene er svært avsidesliggende og administreres av ulike tilbydere.
Dessuten. Når alle team jobber innenfor samme klynge, kunne ulike tjenester med feil installerte NodeSelectors fly til den "fremmede" verten til et annet team og bruke ressurser der, og hvis det ble angitt smuss, var det konstante forespørsler om at en eller annen tjeneste ikke fungerte, ikke distribuert riktig på grunn av menneskelig faktor. Et annet problem var å beregne kostnadene, spesielt med tanke på problemene med å distribuere tjenester på tvers av noder.
En egen historie var utstedelsen av rettigheter til ansatte: hvert team ønsket å være "i spissen" av klyngen og administrere den fullstendig, noe som kan føre til en fullstendig kollaps, siden teamene i utgangspunktet er uavhengige av hverandre.
Hva du skal gjøre?
Med hensyn til ovenstående og ønskene til teamene om å være mer uavhengige, gjorde vi en enkel konklusjon: ett team - en klynge.
Så vi fikk en andre:
Og så den tredje klyngen:
Så begynte vi å tenke: la oss si at om et år vil teamene våre ha mer enn én klynge? I ulike geografiske områder, for eksempel, eller under kontroll av ulike tilbydere? Og noen av dem vil raskt kunne distribuere en midlertidig klynge for noen tester.
Full Kubernetes ville komme! Dette er en slags MultiKubernetes, viser det seg.
Samtidig vil vi alle på en eller annen måte ha behov for å vedlikeholde alle disse klyngene, enkelt kunne administrere tilgang til dem, samt opprette nye og avvikle gamle uten manuell inngripen.
Det har gått litt tid siden begynnelsen av reisen vår i Kubernetes-verdenen, og vi bestemte oss for å undersøke de tilgjengelige løsningene på nytt. Det viste seg at den allerede eksisterer på markedet - Rancher 2.2.
På den første fasen av forskningen vår hadde Rancher Labs allerede laget den første utgivelsen av versjon 2, men selv om den kunne økes veldig raskt ved å lansere en container uten eksterne avhengigheter med et par parametere eller bruke det offisielle HELM-diagrammet, virket det grovt. til oss, og vi visste ikke om vi kunne stole på denne beslutningen om den vil bli utviklet eller raskt forlatt. Klynge = klikk-paradigmet i selve UI passet heller ikke for oss, og vi ønsket ikke å bli bundet til RKE, siden det er et ganske snevert fokusert verktøy.
Versjon Rancher 2.2 hadde allerede et mer brukbart utseende og hadde, sammen med de forrige, en haug med interessante funksjoner ut av boksen, for eksempel integrasjon med mange eksterne leverandører, et enkelt distribusjonspunkt for rettigheter og kubeconfig-filer, lansering av en kubectl bilde med dine rettigheter i brukergrensesnittet, nestede navnerom aka prosjekter.
Det var også et fellesskap som allerede var dannet rundt Rancher 2, og en leverandør kalt HashiCorp Terraform ble opprettet for å administrere det, noe som hjalp oss med å sette alt sammen.
Hva skjedde
Som et resultat endte vi opp med en liten klynge som kjørte Rancher, tilgjengelig for alle andre klynger, samt mange klynger koblet til den, tilgang til hvilken som helst kan gis like enkelt som å legge til en bruker i ldap-katalogen, uavhengig av hvor den befinner seg og hvilken leverandørs ressurser den bruker.
Ved å bruke gitlab-ci og Terraform ble det laget et system som lar deg lage en klynge av enhver konfigurasjon i skyleverandører eller vår egen infrastruktur og koble dem til Rancher. Alt dette gjøres i IaC-stilen, der hver klynge er beskrevet av et depot, og dens tilstand er versjonert. Samtidig er de fleste moduler koblet til fra eksterne depoter, slik at alt som gjenstår er å sende variabler eller beskrive din egendefinerte konfigurasjon for forekomster, noe som bidrar til å redusere prosentandelen av kodegjentakelse.
Selvfølgelig er reisen vår langt fra over, og det er fortsatt mange interessante oppgaver foran oss, for eksempel et enkelt arbeidspunkt med logger og beregninger for alle klynger, servicenettverk, gitops for håndtering av belastninger i en multicluster og mye mer. Vi håper du finner vår opplevelse interessant!
Artikkelen er skrevet av A. Antipov, A. Ganush, Platform Engineers.
Kilde: www.habr.com