Hej Habr!
Vi representerar Exness-plattformsteamet. VĂ„ra kollegor har tidigare skrivit en artikel om . Idag vill vi dela med oss ââav vĂ„r erfarenhet av att migrera tjĂ€nster till Kubernetes.
Till att börja med erbjuder vi dig nÄgra siffror för att bÀttre förstÄ vad vi kommer att prata om:
- VÄr utvecklingsavdelning bestÄr av 100+ personer, inklusive mer Àn 10 olika team med sjÀlvförsörjande QA, DevOps och Scrum-processer. Utvecklingsstack - Python, PHP, C++, Java och Golang.
- Storleken pÄ test- och produktionsmiljöerna Àr cirka 2000 containrar vardera. De kör Rancher v1.6 pÄ sin egen virtualisering och under VMware.
Motivation
Som de sÀger, ingenting varar för evigt under mÄnen, och Rancher meddelade att stödet för version 1.6 upphörde för ett tag sedan. Ja, under mer Àn tre Är har vi lÀrt oss att förbereda det och lösa nya problem, men allt oftare stötte vi pÄ problem som aldrig kommer att lösas. Rancher 1.6 har ocksÄ ett rigid system för att utfÀrda licenser, dÀr du antingen kan göra nÀstan allt, eller ingenting.
Ăven om inbyggd virtualisering gav större kontroll över datalagring och sĂ€kerhet, medförde det driftskostnader som var svĂ„ra att tolerera med tanke pĂ„ företagets konstanta tillvĂ€xt, antal projekt och krav pĂ„ dem.
Vi ville följa IaC-standarder och vid behov fÄ kapacitet snabbt, pÄ vilken geografisk plats som helst och utan leverantörslÄs, och Àven ha möjlighet att snabbt överge dem.
Första stegen
Först och frÀmst ville vi förlita oss pÄ modern teknik och lösningar som skulle göra det möjligt för team att ha en snabbare utvecklingscykel och minimera driftskostnaderna för att interagera med plattformen som tillhandahÄller kapaciteten.
Naturligtvis var det första som vi tÀnkte pÄ Kubernetes, men vi blev inte upphetsade och gjorde lite research för att se till att vi gjorde rÀtt val. Vi utvÀrderade bara opensource-lösningar, och i en orÀttvis kamp vann Kubernetes hÀnderna ner.
DÀrefter kom frÄgan om att vÀlja ett verktyg för att skapa kluster. Vi jÀmförde de mest populÀra lösningarna: kops, kubespray, kubeadm.
Till att börja med verkade kubeadm för komplicerat för oss, mer som ett slags "Äteruppfinnare av hjulet", och kops saknade flexibilitet.
Och vinnaren blev:
Vi började experimentera med vĂ„r egen virtualisering och AWS, och försökte Ă„terskapa nĂ„got liknande vĂ„rt tidigare resurshanteringsmönster, dĂ€r alla anvĂ€nder samma "kluster". Och nu har vi vĂ„rt första kluster, 10 smĂ„. virtuell maskin, varav ett par finns i AWS. Vi började försöka migrera team dit, och allt verkade gĂ„ bra, och historien kunde ha tagit slut, menâŠ
Första problemen
Ansible, vilket Ă€r vad kubespray Ă€r byggt pĂ„, Ă€r inte ett verktyg som lĂ„ter dig följa IaC: nĂ€r noder togs i/ur drift gick alltid nĂ„got fel och nĂ„gon form av ingripande krĂ€vdes, och spelboken betedde sig annorlunda nĂ€r man anvĂ€nde olika operativsystem. NĂ€r antalet lag och noder i klustret vĂ€xte började vi mĂ€rka att spelboken tog lĂ€ngre och lĂ€ngre tid att köra, och sĂ„ smĂ„ningom var vĂ„rt rekord 3,5 timmar, och ditt? đ
Och det verkar som att kubespray bara Àr Ansible, och allt Àr klart vid första anblicken, men:
I början av resan var uppgiften att lansera kapacitet endast i AWS och pÄ virtualisering, men sedan Àndrades kraven, som ofta hÀnder.
I ljuset av detta blev det tydligt att vÄrt gamla mönster att slÄ samman resurser i ett enda orkestreringssystem inte var lÀmpligt - i de fall dÀr kluster Àr mycket avlÀgsna och hanteras av olika leverantörer.
Mer kommer. NÀr alla team arbetar inom samma kluster kunde olika tjÀnster med felaktigt installerad NodeSelector flyga till en "utlÀndsk" vÀrd hos ett annat team och utnyttja resurser dÀr, och i fallet med flÀckar kom det stÀndiga förfrÄgningar om att den eller den tjÀnsten inte fungerade, inte distribuerades korrekt pÄ grund av den mÀnskliga faktorn. Ett annat problem var kostnadsberÀkning, sÀrskilt med tanke pÄ problemen med att distribuera tjÀnster över noder.
UtfÀrdandet av rÀttigheter till anstÀllda var en separat historia: varje team ville vara "i spetsen" för klustret och helt hantera det, vilket kan orsaka en fullstÀndig kollaps, eftersom teamen för det mesta Àr oberoende av varandra.
Vad göra?
Med hĂ€nsyn till ovanstĂ„ende och teamens önskemĂ„l om att bli mer oberoende, kom vi till en enkel slutsats: ett team â ett kluster.
SĂ„ vi fick en andra:
Och sedan det tredje klustret:
HÀr började vi tÀnka: lÄt oss sÀga att om ett Är kommer vÄra team att ha mer Àn ett kluster? I olika geografiska omrÄden, till exempel, eller under olika leverantörer? Och nÄgra av dem vill snabbt kunna distribuera ett tillfÀlligt kluster för vissa tester.
Det skulle vara en komplett Kubernetes! Det visar sig att detta Àr nÄgon sorts MultiKubernetes.
Samtidigt kommer vi alla att behöva pÄ nÄgot sÀtt underhÄlla alla dessa kluster, enkelt kunna hantera Ätkomst till dem och skapa nya och avveckla gamla utan manuella ingrepp.
Det har gÄtt en tid sedan vi började vÄr resa i Kubernetes-vÀrlden och vi bestÀmde oss för att ompröva de tillgÀngliga lösningarna. Det visade sig att det redan finns pÄ marknaden - Rancher 2.2.
I det första steget av vÄr forskning hade Rancher Labs redan gjort den första versionen av version 2, men Àven om den snabbt kunde lanseras genom att köra en container utan externa beroenden med ett par parametrar eller anvÀnda det officiella HELM-diagrammet, verkade det rÄtt för oss, och vi visste inte om vi kunde lita pÄ den hÀr lösningen, om den skulle utvecklas eller snabbt överges. Kluster = klick-paradigmet i sjÀlva anvÀndargrÀnssnittet passade inte heller oss, och vi ville inte binda oss till RKE, eftersom det Àr ett ganska snÀvt fokuserat verktyg.
Rancher 2.2 hade redan ett mer funktionellt utseende och hade, tillsammans med de tidigare, ett gÀng intressanta funktioner ur lÄdan, sÄsom integration med mÄnga externa leverantörer, en enda distributionspunkt för rÀttigheter och kubeconfig-filer, lansering av en kubectl-bild med dina rÀttigheter i anvÀndargrÀnssnittet, kapslade namnutrymmen aka projekt.
Det fanns ocksÄ en gemenskap som redan bildades runt Rancher 2, och en HashiCorp Terraform-leverantör skapades för att hantera det, vilket hjÀlpte oss att fÄ ihop allt.
Vad hÀnde
Som ett resultat har vi ett litet kluster som kör Rancher, tillgÀngligt för alla andra kluster, sÄvÀl som mÄnga kluster som Àr anslutna till det, Ätkomst till vilket som helst kan beviljas lika enkelt som att lÀgga till en anvÀndare i ldap-katalogen, oavsett var den finns och vilken leverantörs resurser den anvÀnder.
Med hjÀlp av gitlab-ci och Terraform skapade vi ett system som lÄter oss skapa ett kluster av valfri konfiguration i molnleverantörer eller vÄr egen infrastruktur och koppla dem till Rancher. Allt detta görs i IaC-stilen, dÀr varje kluster beskrivs av ett arkiv och dess tillstÄnd Àr versionerad. Samtidigt Àr de flesta moduler anslutna frÄn externa arkiv sÄ att allt som ÄterstÄr Àr att skicka variabler eller beskriva din anpassade konfiguration för instanser, vilket hjÀlper till att minska andelen kodupprepning.
Naturligtvis Àr vÄr resa lÄngt ifrÄn över och det finns fortfarande mÄnga intressanta uppgifter framför oss, som en enda arbetsplats med loggar och mÀtvÀrden för alla kluster, servicenÀt, gitops för att hantera laster i ett multikluster och mycket mer. Vi hoppas att du kommer att finna vÄr upplevelse intressant!
Artikeln skrevs av A. Antipov, A. Ganush, plattformsingenjörer.
KĂ€lla: will.com
