Hé Habr!
Wij vertegenwoordigen het Exness platformteam. Eerder schreven onze collega’s er al een artikel over . Vandaag willen we onze ervaringen delen met het migreren van services naar Kubernetes.
Om te beginnen bieden we u enkele cijfers voor een beter begrip van wat er zal worden besproken:
- Onze ontwikkelingsafdeling bestaat uit meer dan 100 mensen, waaronder meer dan 10 verschillende teams met zelfvoorzienende QA-, DevOps- en Scrum-processen. Ontwikkelingsstack - Python, PHP, C++, Java en Golang.
- De omvang van de test- en productieomgeving bedraagt elk ongeveer 2000 containers. Ze draaien Rancher v1.6 op hun eigen virtualisatie en onder VMware.
Motivatie
Zoals ze zeggen, niets duurt eeuwig, en Rancher kondigde al lang geleden het einde aan van de ondersteuning voor versie 1.6. Ja, in meer dan drie jaar hebben we geleerd hoe we het moeten voorbereiden en de problemen die zich voordoen, kunnen oplossen, maar steeds vaker worden we geconfronteerd met problemen die nooit zullen worden gecorrigeerd. Rancher 1.6 heeft ook een verstard systeem voor het uitgeven van rechten, waarbij je bijna alles of niets kunt doen.
Hoewel propriëtaire virtualisatie meer controle over de gegevensopslag en de beveiliging ervan bood, legde het bedrijfskosten op die moeilijk te aanvaarden waren gezien de constante groei van het bedrijf, het aantal projecten en de vereisten daarvoor.
We wilden de IaC-standaarden volgen en, indien nodig, snel capaciteit verkrijgen, op elke geografische locatie en zonder leveranciersblokkering, en deze ook snel kunnen verlaten.
Eerste stappen
Allereerst wilden we vertrouwen op moderne technologieën en oplossingen die teams in staat zouden stellen een snellere ontwikkelingscyclus te hebben en de operationele kosten voor interactie met het platform dat stroom levert te minimaliseren.
Het eerste waar we natuurlijk aan dachten was Kubernetes, maar we raakten niet enthousiast en deden wat onderzoek om te zien of dit de juiste keuze was. We hebben alleen opensource-oplossingen geëvalueerd en in een oneerlijke strijd heeft Kubernetes onvoorwaardelijk gewonnen.
Vervolgens kwam de vraag om een tool te kiezen voor het maken van clusters. We hebben de meest populaire oplossingen vergeleken: kops, kubespray, kubeadm.
Om te beginnen leek kubeadm ons een te ingewikkeld pad, eerder een soort uitvinder van een 'fiets', en kops had niet genoeg flexibiliteit.
En de winnaar was:
We begonnen te experimenteren met onze eigen virtualisatie en AWS, in een poging iets te herscheppen dat ongeveer leek op ons vorige resource management-patroon, waarbij iedereen hetzelfde ‘cluster’ deelde. En nu hebben we ons eerste cluster van 10 kleine virtuele machines, waarvan er een paar zich in AWS bevinden. We begonnen te proberen teams daarheen te migreren, alles leek “goed” te zijn en het verhaal kon worden afgerond, maar...
Eerste problemen
Ansible is waar kubespray op is gebouwd, het is geen tool waarmee je IaC kunt volgen: bij het in bedrijf stellen/ontmantelen van knooppunten ging er voortdurend iets mis en was er een of andere interventie nodig, en bij het gebruik van verschillende besturingssystemen gedroeg het draaiboek zich anders. . Naarmate het aantal teams en knooppunten in het cluster groeide, merkten we dat het steeds langer duurde om het draaiboek te voltooien, en als gevolg daarvan bedroeg ons record 3,5 uur. Hoe zit het met dat van jou? 🙂
En het lijkt erop dat kubespray gewoon Ansible is, en alles is op het eerste gezicht duidelijk, maar:
Aan het begin van het traject was het de taak om alleen capaciteiten in AWS en op het gebied van virtualisatie te lanceren, maar daarna veranderden, zoals vaak gebeurt, de vereisten.
In het licht hiervan werd het duidelijk dat ons oude patroon van het combineren van bronnen in één orkestratiesysteem niet geschikt was - in het geval waarin de clusters erg afgelegen zijn en worden beheerd door verschillende providers.
Verder. Wanneer alle teams binnen hetzelfde cluster werken, kunnen verschillende services met verkeerd geïnstalleerde NodeSelectors naar de "buitenlandse" host van een ander team vliegen en daar bronnen gebruiken, en als er een besmetting is ingesteld, zijn er voortdurend verzoeken dat de ene of de andere service niet werkt. niet correct verdeeld vanwege menselijke factoren. Een ander probleem was het berekenen van de kosten, vooral gezien de problemen bij het distribueren van diensten over knooppunten.
Een apart verhaal was de uitgifte van rechten aan werknemers: elk team wilde ‘aan het hoofd’ van het cluster staan en het volledig beheren, wat een volledige ineenstorting zou kunnen veroorzaken, aangezien de teams in principe onafhankelijk van elkaar zijn.
Wat te doen?
Rekening houdend met het bovenstaande en de wens van de teams om onafhankelijker te zijn, kwamen we tot een simpele conclusie: één team – één cluster.
Daarom hebben we een tweede:
En dan het derde cluster:
Toen begonnen we te denken: laten we zeggen dat onze teams over een jaar meer dan één cluster zullen hebben? In verschillende geografische gebieden bijvoorbeeld of onder controle van verschillende aanbieders? En sommigen van hen zullen voor sommige tests snel een tijdelijk cluster willen kunnen inzetten.
Volledige Kubernetes zouden komen! Dit blijkt een soort MultiKubernetes te zijn.
Tegelijkertijd zullen we allemaal op de een of andere manier al deze clusters moeten onderhouden, de toegang daartoe gemakkelijk moeten kunnen beheren, nieuwe moeten creëren en oude moeten ontmantelen zonder handmatige tussenkomst.
Er is enige tijd verstreken sinds het begin van onze reis in de wereld van Kubernetes, en we hebben besloten de beschikbare oplossingen opnieuw te onderzoeken. Het bleek dat het al op de markt bestaat: Rancher 2.2.
In de eerste fase van ons onderzoek had Rancher Labs al de eerste release van versie 2 uitgebracht, maar hoewel deze zeer snel kon worden gerealiseerd door een container te lanceren zonder externe afhankelijkheden met een paar parameters of door de officiële HELM-grafiek te gebruiken, leek het grof voor ons, en we wisten niet of we op deze beslissing konden vertrouwen, of deze ontwikkeld zou worden of snel verlaten zou worden. Het cluster = clicks-paradigma in de gebruikersinterface zelf beviel ons ook niet, en we wilden niet gebonden raken aan RKE, omdat het een tamelijk beperkt gerichte tool is.
Versie Rancher 2.2 had al een werkbaarder uiterlijk en had, samen met de vorige, een aantal interessante features out-of-the-box, zoals integratie met veel externe providers, een enkel distributiepunt voor rechten en kubeconfig-bestanden, het lanceren van een kubectl afbeelding met uw rechten in de gebruikersinterface, geneste naamruimten oftewel projecten.
Er was ook al een community rond Rancher 2 gevormd en er werd een provider genaamd HashiCorp Terraform opgericht om deze te beheren, wat ons hielp alles samen te stellen.
Wat is er gebeurd
Als gevolg hiervan kwamen we terecht bij één klein cluster waarop Rancher draait, toegankelijk voor alle andere clusters, evenals vele clusters die ermee verbonden zijn. Toegang tot elk daarvan kan net zo eenvoudig worden verleend als het toevoegen van een gebruiker aan de ldap-directory, ongeacht waar het zich bevindt en van welke provider het gebruik maakt.
Met behulp van gitlab-ci en Terraform is een systeem gemaakt waarmee je een cluster van elke configuratie in cloudproviders of onze eigen infrastructuur kunt creëren en deze kunt verbinden met Rancher. Dit alles gebeurt in de IaC-stijl, waarbij elk cluster wordt beschreven door een repository en de status ervan wordt bepaald. Tegelijkertijd zijn de meeste modules verbonden vanuit externe repository's, zodat u alleen nog variabelen hoeft door te geven of uw aangepaste configuratie voor instances te beschrijven, waardoor het percentage codeherhalingen wordt verminderd.
Onze reis is natuurlijk nog lang niet voorbij en er liggen nog veel interessante taken in het verschiet, zoals een enkel werkpunt met logs en statistieken van alle clusters, service mesh, gitops voor het beheren van belastingen in een multicluster en nog veel meer. We hopen dat je onze ervaring interessant vindt!
Het artikel is geschreven door A. Antipov, A. Ganush, Platform Engineers.
Bron: www.habr.com