Hej Habr!
Vi representerar Exness-plattformsteamet. Tidigare har våra kollegor redan 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 en bättre förståelse av vad som kommer att diskuteras:
- 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, och Rancher meddelade att stödet för version 1.6 slutade för ganska länge sedan. Ja, på mer än tre år har vi lärt oss att förbereda det och lösa problem som uppstår, men allt oftare ställs vi inför problem som aldrig kommer att rättas till. Rancher 1.6 har också ett förbenat system för att utfärda rättigheter, där du antingen kan göra nästan allt eller ingenting.
Även om proprietär virtualisering gav större kontroll över datalagring och dess säkerhet, medförde den driftskostnader som var svåra att acceptera med tanke på företagets ständiga tillväxt, antalet projekt och kraven på dem.
Vi ville följa IaC-standarder och vid behov skaffa kapacitet snabbt, oavsett geografisk plats och utan leverantörslås, och även snabbt kunna överge den.
Första stegen
Först och främst ville vi förlita oss på modern teknik och lösningar som skulle tillåta team att ha en snabbare utvecklingscykel och minimera driftskostnaderna för att interagera med plattformen som ger kraft.
Naturligtvis var det första vi tänkte på Kubernetes, men vi blev inte upphetsade och gjorde lite research för att se om det var rätt val. Vi utvärderade bara lösningar med öppen källkod, och i en orättvis kamp vann Kubernetes villkorslöst.
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 tyckte vi oss att kubeadm var en alltför komplicerad väg, snarare som en slags uppfinnare av en "cykel", och kops hade inte tillräckligt med flexibilitet.
Och vinnaren blev:
Vi började experimentera med vår egen virtualisering och AWS och försökte återskapa något som ungefär liknar vårt tidigare resurshanteringsmönster, där alla delade samma "kluster". Och nu har vi vårt första kluster med 10 små virtuella maskiner, varav ett par finns i AWS. Vi började försöka migrera team dit, allt verkade vara "bra", och historien kunde avslutas, men...
Första problemen
Ansible är vad kubespray är byggd på, det är inte ett verktyg som låter dig följa IaC: vid driftsättning/avveckling av noder gick något ständigt fel och någon form av ingripande krävdes, och när man använde olika operativsystem, betedde playbook sig annorlunda. annorlunda . 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 slutföra, och som ett resultat var vårt rekord 3,5 timmar, hur var det med 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 kombinera resurser till ett orkestreringssystem inte var lämpligt - i de fall där klustren är mycket avlägsna och hanteras av olika leverantörer.
Dessutom. När alla team arbetar inom samma kluster kunde olika tjänster med felaktigt installerade NodeSelectors flyga till den "främmande" värden för ett annat team och utnyttja resurser där, och om fläcken sattes in så kom det ständiga förfrågningar om att en eller annan tjänst inte fungerade, inte fördelat korrekt på grund av mänsklig faktor. Ett annat problem var att beräkna kostnaden, särskilt med tanke på problemen med att distribuera tjänster över noder.
En separat historia var utfärdandet av rättigheter till anställda: varje team ville vara "i spetsen" för klustret och helt hantera det, vilket kan orsaka en fullständig kollaps, eftersom teamen i princip är oberoende av varandra.
Vad göra?
Med hänsyn till ovanstående och teamens önskemål om att bli mer oberoende, gjorde vi en enkel slutsats: ett team - ett kluster.
Så vi fick en andra:
Och sedan det tredje klustret:
Sedan 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 kontroll av olika leverantörer? Och några av dem vill snabbt kunna distribuera ett tillfälligt kluster för vissa tester.
Full Kubernetes skulle komma! Det här är någon sorts MultiKubernetes, visar det sig.
Samtidigt kommer vi alla att behöva på något sätt underhålla alla dessa kluster, enkelt kunna hantera åtkomst till dem, samt skapa nya och avveckla gamla utan manuella ingrepp.
Det har gått en tid sedan början av 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 skedet av vår forskning hade Rancher Labs redan gjort den första versionen av version 2, men även om den kunde höjas mycket snabbt genom att lansera en behållare utan externa beroenden med ett par parametrar eller använda det officiella HELM-diagrammet, verkade det rått. till oss, och vi visste inte om vi kunde lita på detta beslut om det kommer att utvecklas eller snabbt överges. Kluster = klick-paradigmet i själva gränssnittet passade inte heller oss, och vi ville inte bli bundna till RKE, eftersom det är ett ganska snävt fokuserat verktyg.
Version Rancher 2.2 hade redan ett mer fungerande 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 namnrymder aka projekt.
Det fanns också en gemenskap som redan bildades runt Rancher 2, och en leverantör som heter HashiCorp Terraform skapades för att hantera det, vilket hjälpte oss att få ihop allt.
Vad hände
Som ett resultat slutade vi med ett litet kluster som körde Rancher, tillgängligt för alla andra kluster, såväl som många kluster anslutna till det, åtkomst till vilka som helst kan beviljas så 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 skapades ett system som låter dig 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, såsom en enda arbetsplats med loggar och mätvärden för alla kluster, servicenät, gitops för att hantera belastningar i ett multikluster och mycket mer. Vi hoppas att du tycker att vår upplevelse är intressant!
Artikeln skrevs av A. Antipov, A. Ganush, plattformsingenjörer.
Källa: will.com