Hej Habr!
Vi repræsenterer Exness-platformsteamet. Tidligere har vores kolleger allerede skrevet en artikel om . I dag vil vi dele vores erfaring med at migrere tjenester til Kubernetes.
Til at begynde med tilbyder vi dig nogle tal for en bedre forståelse af, hvad der vil blive diskuteret:
- Vores udviklingsafdeling består af 100+ mennesker, herunder mere end 10 forskellige teams med selvforsynende QA, DevOps og Scrum processer. Udviklingsstak - Python, PHP, C++, Java og Golang.
- Størrelsen af test- og produktionsmiljøerne er omkring 2000 containere hver. De kører Rancher v1.6 på deres egen virtualisering og under VMware.
Motivation
Som de siger, varer intet evigt, og Rancher annoncerede ophøret med understøttelse af version 1.6 for ganske lang tid siden. Ja, på mere end tre år har vi lært at forberede det og løse problemer, der opstår, men oftere og oftere står vi over for problemer, som aldrig bliver rettet. Rancher 1.6 har også et forbenet system til udstedelse af rettigheder, hvor du enten kan gøre næsten alt eller intet.
Selvom proprietær virtualisering gav større kontrol over datalagring og dets sikkerhed, påførte det driftsomkostninger, som var vanskelige at acceptere i betragtning af virksomhedens konstante vækst, antallet af projekter og kravene til dem.
Vi ønskede at følge IaC-standarder og om nødvendigt skaffe kapacitet hurtigt, på ethvert geografisk sted og uden en leverandørlås, og også hurtigt kunne opgive den.
Første trin
Først og fremmest ønskede vi at stole på moderne teknologier og løsninger, der ville give teams mulighed for at få en hurtigere udviklingscyklus og minimere driftsomkostningerne for at interagere med platformen, der leverer strøm.
Selvfølgelig var det første, der faldt os i tankerne, Kubernetes, men vi blev ikke begejstrede og lavede lidt research for at se, om det var det rigtige valg. Vi evaluerede kun opensource-løsninger, og i en uretfærdig kamp vandt Kubernetes ubetinget.
Dernæst kom spørgsmålet om at vælge et værktøj til at skabe klynger. Vi sammenlignede de mest populære løsninger: kops, kubespray, kubeadm.
Til at starte med forekom kubeadm for os at være en for kompliceret vej, snarere som en slags opfinder af en "cykel", og kops havde ikke nok fleksibilitet.
Og vinderen blev:
Vi begyndte at eksperimentere med vores egen virtualisering og AWS og prøvede at genskabe noget, der nogenlunde ligner vores tidligere ressourcestyringsmønster, hvor alle delte den samme "klynge". Og nu har vi vores første klynge på 10 små virtuelle maskiner, hvoraf et par er placeret i AWS. Vi begyndte at forsøge at migrere hold dertil, alt så ud til at være "godt", og historien kunne blive færdig, men...
Første problemer
Ansible er, hvad kubespray er bygget på, det er ikke et værktøj, der giver dig mulighed for at følge IaC: ved idriftsættelse/afvikling af noder gik noget konstant galt, og en form for indgriben var påkrævet, og ved brug af forskellige OS'er opførte playbook sig anderledes. forskelligt . Efterhånden som antallet af hold og noder i klyngen voksede, begyndte vi at bemærke, at det tog længere og længere tid at færdiggøre playbook, og som et resultat var vores rekord 3,5 timer, hvad med din? 🙂
Og det ser ud til, at kubespray bare er Ansible, og alt er klart ved første øjekast, men:
I begyndelsen af rejsen var opgaven kun at lancere kapaciteter i AWS og på virtualisering, men så ændrede kravene sig, som det ofte sker.
I lyset af dette blev det klart, at vores gamle mønster med at kombinere ressourcer i ét orkestreringssystem ikke var egnet - i det tilfælde, hvor klyngerne er meget fjerntliggende og administreres af forskellige udbydere.
Desuden. Når alle teams arbejder inden for den samme klynge, kunne forskellige tjenester med forkert installerede NodeSelectors flyve til den "fremmede" vært for et andet team og bruge ressourcer der, og hvis der blev sat taint, var der konstant anmodninger om, at den ene eller anden tjeneste ikke virkede, ikke fordelt korrekt på grund af menneskelig faktor. Et andet problem var at beregne omkostningerne, især i betragtning af problemerne med at distribuere tjenester på tværs af noder.
En separat historie var udstedelsen af rettigheder til medarbejderne: hvert team ønskede at være "i spidsen" for klyngen og fuldstændigt styre den, hvilket kunne forårsage et fuldstændigt sammenbrud, da teamene grundlæggende er uafhængige af hinanden.
Hvad skal jeg gøre?
Under hensyntagen til ovenstående og holdenes ønsker om at være mere uafhængige, lavede vi en simpel konklusion: et hold - en klynge.
Så vi fik en anden:
Og så den tredje klynge:
Så begyndte vi at tænke: lad os sige, at vores teams om et år vil have mere end én klynge? I forskellige geografiske områder, for eksempel, eller under kontrol af forskellige udbydere? Og nogle af dem vil gerne hurtigt kunne implementere en midlertidig klynge til nogle tests.
Fuld Kubernetes ville komme! Det her er en slags MultiKubernetes, viser det sig.
Samtidig bliver vi alle på en eller anden måde nødt til at vedligeholde alle disse klynger, være i stand til nemt at administrere adgangen til dem, samt oprette nye og nedlægge gamle uden manuel indgriben.
Der er gået noget tid siden begyndelsen af vores rejse i Kubernetes verden, og vi besluttede at revurdere de tilgængelige løsninger. Det viste sig, at det allerede findes på markedet - Rancher 2.2.
På den første fase af vores forskning havde Rancher Labs allerede lavet den første udgivelse af version 2, men selvom den kunne hæves meget hurtigt ved at lancere en container uden eksterne afhængigheder med et par parametre eller bruge det officielle HELM-diagram, virkede det råt. til os, og vi vidste ikke, om vi kunne stole på denne beslutning, om den vil blive udviklet eller hurtigt opgivet. Cluster = klik-paradigmet i selve UI'en passede heller ikke os, og vi ønskede ikke at blive bundet til RKE, da det er et ret snævert fokuseret værktøj.
Version Rancher 2.2 havde allerede et mere brugbart udseende og havde sammen med de tidligere en masse interessante funktioner ud af boksen, såsom integration med mange eksterne udbydere, et enkelt distributionspunkt for rettigheder og kubeconfig-filer, lancering af en kubectl billede med dine rettigheder i brugergrænsefladen, indlejrede navnerum aka projekter.
Der var også et fællesskab, der allerede var dannet omkring Rancher 2, og en udbyder ved navn HashiCorp Terraform blev oprettet til at administrere det, hvilket hjalp os med at sætte alt sammen.
Hvad skete der
Som et resultat endte vi med en lille klynge, der kørte Rancher, tilgængelig for alle andre klynger, såvel som mange klynger forbundet til den, og adgang til enhver af dem kan gives lige så simpelt som at tilføje en bruger til ldap-mappen, uanset hvor den er placeret, og hvilken udbyders ressourcer den bruger.
Ved hjælp af gitlab-ci og Terraform blev der skabt et system, der giver dig mulighed for at oprette en klynge af enhver konfiguration i cloud-udbydere eller vores egen infrastruktur og forbinde dem til Rancher. Alt dette gøres i IaC-stilen, hvor hver klynge er beskrevet af et lager, og dens tilstand er versioneret. Samtidig er de fleste moduler forbundet fra eksterne repositories, så der kun er tilbage at videregive variabler eller beskrive din brugerdefinerede konfiguration for instanser, hvilket hjælper med at reducere procentdelen af kodegentagelse.
Selvfølgelig er vores rejse langt fra slut, og der er stadig mange interessante opgaver forude, såsom et enkelt arbejdspunkt med logfiler og metrics for alle klynger, servicemesh, gitops til håndtering af belastninger i en multicluster og meget mere. Vi håber, at du finder vores oplevelse interessant!
Artiklen er skrevet af A. Antipov, A. Ganush, Platform Engineers.
Kilde: www.habr.com