Dag Allemaal! Mijn naam is Pavel Agaletsky. Ik werk als teamleider in een team dat het Lamoda bezorgsysteem ontwikkelt. In 2018 sprak ik op de HighLoad++ conferentie en vandaag wil ik graag een transcriptie van mijn rapport presenteren.

Mijn onderwerp is gewijd aan de ervaring van ons bedrijf met het implementeren van systemen en diensten in verschillende omgevingen. Beginnend vanaf onze prehistorie, toen we alle systemen in gewone virtuele servers implementeerden, eindigend met de geleidelijke overgang van Nomad naar implementatie in Kubernetes. Ik zal je vertellen waarom we het deden en welke problemen we daarbij tegenkwamen.

Applicaties implementeren op VM

Laten we beginnen met het feit dat drie jaar geleden alle systemen en diensten van het bedrijf op reguliere virtuele servers werden geïmplementeerd. Technisch gezien was het zo georganiseerd dat alle code voor onze systemen werd opgeslagen en geassembleerd met behulp van automatische assemblagetools, met behulp van jenkins. Met behulp van Ansible werd het uitgerold van ons versiebeheersysteem naar virtuele servers. Bovendien werd elk systeem dat ons bedrijf had op ten minste twee servers geïmplementeerd: één op de kop, de tweede op de staart. Deze twee systemen waren absoluut identiek aan elkaar in al hun instellingen, vermogen, configuratie, enz. Het enige verschil tussen hen was dat de kop gebruikersverkeer ontving, terwijl de staart nooit gebruikersverkeer ontving.

Waar was het voor?

Toen we nieuwe releases van onze applicatie uitrolden, wilden we een naadloze uitrol garanderen, dat wil zeggen zonder merkbare gevolgen voor gebruikers. Dit werd bereikt dankzij het feit dat de volgende gecompileerde release met behulp van Ansible tot in de puntjes werd uitgerold. Daar konden de mensen die betrokken waren bij de implementatie controleren of alles in orde was: alle statistieken, secties en applicaties werkten; de benodigde scripts worden gelanceerd. Pas nadat ze ervan overtuigd waren dat alles in orde was, werd het verkeer omgeschakeld. Het begon naar de server te gaan die voorheen de staart was. En degene die voorheen het hoofd was, bleef zonder gebruikersverkeer, terwijl er nog steeds de vorige versie van onze applicatie op stond.

Het was dus naadloos voor de gebruikers. Omdat het schakelen onmiddellijk gebeurt, omdat het simpelweg het schakelen van de balancer is. U kunt heel eenvoudig teruggaan naar de vorige versie door simpelweg de balancer terug te schakelen. We konden ook verifiëren dat de applicatie al in productie kon worden genomen voordat deze gebruikersverkeer ontving, wat best handig was.

Welke voordelen zagen we in dit alles?

1. Allereerst is het genoeg het werkt gewoon. Iedereen begrijpt hoe een dergelijk implementatieschema werkt, omdat de meeste mensen ooit op reguliere virtuele servers hebben geïmplementeerd.
2. Dit is genoeg betrouwbaar, aangezien de implementatietechnologie eenvoudig is en door duizenden bedrijven is getest. Miljoenen servers worden op deze manier ingezet. Het is moeilijk om iets kapot te maken.
3. En eindelijk konden we komen atomaire implementaties. Implementaties die gelijktijdig plaatsvinden voor gebruikers, zonder merkbare schakelstap tussen de oude en de nieuwe versie.

Maar we zagen ook verschillende tekortkomingen in dit alles:

1. Naast de productieomgeving, de ontwikkelomgeving, zijn er nog andere omgevingen. Bijvoorbeeld qa en preproductie. Destijds hadden we veel servers en ongeveer 60 services. Om deze reden was het noodzakelijk onderhoud voor elke service de nieuwste versie ervan virtuele machine. Als u bibliotheken wilt bijwerken of nieuwe afhankelijkheden wilt installeren, moet u dit bovendien in alle omgevingen doen. U moest ook het tijdstip waarop u de volgende nieuwe versie van uw applicatie gaat implementeren, synchroniseren met het tijdstip waarop devops de benodigde omgevingsinstellingen uitvoert. In dit geval is het gemakkelijk om in een situatie terecht te komen waarin onze omgeving in alle omgevingen tegelijk enigszins anders zal zijn. In een QA-omgeving zullen er bijvoorbeeld enkele versies van bibliotheken zijn, en in een productieomgeving zullen er verschillende zijn, wat tot problemen zal leiden.
2. Moeilijkheden bij het bijwerken van afhankelijkheden jouw toepassing. Het hangt niet van jou af, maar van het andere team. Namelijk van het devops-team dat de servers onderhoudt. Je moet ze een passende taak geven en een beschrijving geven van wat je wilt doen.
3. Destijds wilden we ook de grote grote monolieten die we hadden opsplitsen in afzonderlijke kleine diensten, omdat we begrepen dat er steeds meer zouden komen. We hadden er toen al meer dan 100. Voor elke nieuwe dienst was het nodig om een ​​aparte nieuwe virtuele machine te creëren, die ook onderhouden en ingezet moest worden. Bovendien heb je niet één auto nodig, maar minimaal twee. Daarbij komt nog de QA-omgeving. Dit veroorzaakt problemen en maakt het moeilijker voor u om nieuwe systemen te bouwen en te gebruiken. complex, duur en langdurig proces.

Daarom hebben we besloten dat het handiger zou zijn om van het inzetten van reguliere virtuele machines over te stappen naar het inzetten van onze applicaties in een dockercontainer. Als je docker hebt, heb je een systeem nodig dat de applicatie in een cluster kan draaien, omdat je niet zomaar een container kunt verhogen. Meestal wilt u bijhouden hoeveel containers er gehesen worden, zodat deze automatisch heffen. Om deze reden moesten we een besturingssysteem selecteren.

We hebben er lang over nagedacht welke we zouden nemen. Feit is dat deze implementatiestack op reguliere virtuele servers destijds enigszins verouderd was, omdat ze niet over de nieuwste versies van besturingssystemen beschikten. Op een gegeven moment was er zelfs FreeBSD, wat niet erg handig was om te ondersteunen. We begrepen dat we zo snel mogelijk naar docker moesten migreren. Onze devops keken naar hun bestaande ervaring met verschillende oplossingen en kozen voor een systeem als Nomad.

Schakel over naar Nomade

Nomad is een product van HashiCorp. Ze staan ​​ook bekend om hun andere oplossingen:

"Consul" is een hulpmiddel voor het ontdekken van diensten.

"Terravorm" - een systeem voor het beheren van servers waarmee u ze kunt configureren via configuratie, de zogenaamde infrastructuur-as-a-code.

"Zwerver" stelt u in staat virtuele machines lokaal of in de cloud te implementeren via specifieke configuratiebestanden.

Nomad leek destijds een vrij eenvoudige oplossing waar snel op overgeschakeld kon worden zonder de hele infrastructuur te veranderen. Bovendien is het vrij eenvoudig te leren. Daarom hebben we ervoor gekozen als filtersysteem voor onze container.

Wat heb je nodig om je systeem op Nomad te implementeren?

1. Allereerst heb je nodig docker-afbeelding jouw toepassing. U moet het bouwen en in de docker-imagerepository plaatsen. In ons geval is dit een artefact - een systeem waarmee je er verschillende artefacten van verschillende typen in kunt stoppen. Het kan archieven, docker-afbeeldingen, PHP-pakketten voor componisten, NPM-pakketten, enzovoort opslaan.
2. Ook nodig configuratiebestand, waarmee Nomad vertelt wat, waar en in welke hoeveelheid u wilt inzetten.

Als we het over Nomad hebben, gebruikt het de HCL-taal als informatiebestandsformaat, wat staat voor HashiCorp-configuratietaal. Dit is een superset van Yaml waarmee u uw service in Nomad-termen kunt beschrijven.

Hiermee kunt u aangeven hoeveel containers u wilt implementeren, van welke afbeeldingen u tijdens de implementatie verschillende parameters wilt doorgeven. U stuurt dit bestand dus naar Nomad en het lanceert op basis daarvan containers in productie.

In ons geval realiseerden we ons dat het simpelweg schrijven van absoluut identieke HCL-bestanden voor elke service niet erg handig zou zijn, omdat er veel services zijn en je ze soms wilt bijwerken. Het komt voor dat één dienst niet in één instantie wordt ingezet, maar in verschillende instanties. Een van de systemen die we in productie hebben, heeft bijvoorbeeld meer dan 100 exemplaren in productie. Ze draaien op dezelfde afbeeldingen, maar verschillen in configuratie-instellingen en configuratiebestanden.

Daarom hebben we besloten dat het voor ons handig zou zijn om al onze configuratiebestanden voor implementatie in één gemeenschappelijke opslagplaats op te slaan. Zo waren ze zichtbaar: ze waren makkelijk te onderhouden en we konden zien welke systemen we hadden. Indien nodig is het ook eenvoudig om iets bij te werken of te wijzigen. Het toevoegen van een nieuw systeem is ook niet moeilijk: u hoeft alleen maar een configuratiebestand in de nieuwe map aan te maken. Daarin bevinden zich de volgende bestanden: service.hcl, die een beschrijving van onze service bevat, en enkele env-bestanden waarmee deze service kan worden geconfigureerd wanneer deze in productie wordt geïmplementeerd.

Sommige van onze systemen worden echter niet in één exemplaar in productie genomen, maar in meerdere exemplaren tegelijk. Daarom hebben we besloten dat het voor ons handig zou zijn om de configuraties niet in hun pure vorm op te slaan, maar in hun sjabloonvorm. En wij kozen Jinja 2. In dit formaat slaan we zowel de configuraties van de service zelf op als de env-bestanden die daarvoor nodig zijn.

Daarnaast hebben we in de repository een implementatiescript geplaatst dat gemeenschappelijk is voor alle projecten, waarmee u uw service kunt lanceren en implementeren in productie, in de gewenste omgeving, op het gewenste doel. In het geval dat we onze HCL-configuratie in een sjabloon veranderden, begon het HCL-bestand, dat voorheen een normale Nomad-configuratie was, er in dit geval een beetje anders uit te zien.

Dat wil zeggen dat we enkele configuratielocatievariabelen hebben vervangen door ingevoegde variabelen die uit env-bestanden of andere bronnen zijn gehaald. Bovendien hebben we de mogelijkheid gekregen om HCL-bestanden dynamisch te verzamelen, dat wil zeggen dat we niet alleen gewone variabele-invoegingen kunnen gebruiken. Omdat jinja lussen en voorwaarden ondersteunt, kunt u daar ook configuratiebestanden maken, die veranderen afhankelijk van waar u uw applicaties precies implementeert.

U wilt uw service bijvoorbeeld inzetten voor pre-productie en productie. Laten we zeggen dat u in pre-productie geen cron-scripts wilt uitvoeren, maar de service gewoon op een apart domein wilt zien om er zeker van te zijn dat deze functioneert. Voor iedereen die de dienst inzet, ziet het proces er heel eenvoudig en transparant uit. Het enige wat u hoeft te doen is het bestand implement.sh uit te voeren en op te geven welke service u wilt implementeren en voor welk doel. U wilt een bepaald systeem bijvoorbeeld inzetten in Rusland, Wit-Rusland of Kazachstan. Om dit te doen, wijzigt u eenvoudigweg een van de parameters en beschikt u over het juiste configuratiebestand.

Wanneer de Nomad-service al in uw cluster is geïmplementeerd, ziet het er als volgt uit.

Ten eerste heb je een soort balancer buiten nodig, die al het gebruikersverkeer ontvangt. Het gaat samenwerken met Consul en gaat daaruit na waar, op welke node, op welk IP-adres een specifieke dienst staat die bij een bepaalde domeinnaam hoort. Diensten in Consul komen van Nomad zelf. Omdat dit producten van hetzelfde bedrijf zijn, zijn ze behoorlijk verwant aan elkaar. We kunnen zeggen dat Nomad out-of-the-box alle services kan registreren die erin zijn gelanceerd in Consul.

Zodra uw front-end load balancer weet naar welke service verkeer moet worden gestuurd, stuurt deze dit door naar de juiste container of meerdere containers die bij uw toepassing passen. Natuurlijk moet er ook aan de veiligheid worden gedacht. Hoewel alle services op dezelfde virtuele machines in containers draaien, vereist dit meestal dat de vrije toegang van de ene service naar de andere wordt voorkomen. Dit hebben we bereikt door segmentatie. Elke dienst werd gelanceerd in een eigen virtueel netwerk, waarop routeringsregels en regels voor het toestaan/weigeren van toegang tot andere systemen en diensten werden voorgeschreven. Ze kunnen zich zowel binnen als buiten dit cluster bevinden. Als u bijvoorbeeld wilt voorkomen dat een service verbinding maakt met een specifieke database, kunt u dit doen via segmentatie op netwerkniveau. Dat betekent dat u, zelfs per ongeluk, niet per ongeluk verbinding kunt maken vanuit de testomgeving met uw productiedatabase.

Hoeveel heeft de transitie ons gekost aan personeel?

De transitie van het gehele bedrijf naar Nomad duurde ongeveer 5-6 maanden. We gingen per dienst verder, maar in een vrij snel tempo. Elk team moest zijn eigen containers voor de services maken.

We hebben een zodanige aanpak gekozen dat elk team onafhankelijk verantwoordelijk is voor de docker-images van hun systemen. DevOps bieden de algemene infrastructuur die nodig is voor de implementatie, dat wil zeggen ondersteuning voor het cluster zelf, ondersteuning voor het CI-systeem, enzovoort. En destijds hebben we ruim 60 systemen laten verhuizen naar Nomad, wat neerkwam op zo’n tweeduizend containers.

Devops is verantwoordelijk voor de algemene infrastructuur van alles wat met implementatie en servers te maken heeft. En elk ontwikkelteam is op zijn beurt verantwoordelijk voor het implementeren van containers voor zijn specifieke systeem, omdat het het team is dat weet wat het doorgaans nodig heeft in een bepaalde container.

Redenen om Nomad te verlaten

Welke voordelen hebben we behaald door over te stappen op implementatie met onder andere Nomad en docker?

1. Wij gelijke voorwaarden geboden voor alle omgevingen. Bij de ontwikkeling, QA-omgeving, pre-productie en productie worden dezelfde containerimages gebruikt, met dezelfde afhankelijkheden. Je hebt dus vrijwel geen kans dat wat in productie komt niet is wat je eerder lokaal of in je testomgeving hebt getest.
2. Wij vonden ook dat het genoeg is eenvoudig een nieuwe dienst toevoegen. Vanuit het oogpunt van implementatie worden nieuwe systemen heel eenvoudig gelanceerd. Ga gewoon naar de repository waar de configuraties worden opgeslagen, voeg daar nog een configuratie voor uw systeem toe en u bent klaar. U kunt uw systeem in productie nemen zonder extra inspanningen van devops.
3. Alle configuratiebestanden in één gemeenschappelijke opslagplaats bleek in behandeling te zijn. Toen we onze systemen implementeerden met behulp van virtuele servers, gebruikten we Ansible, waarbij de configuraties zich in dezelfde repository bevonden. Voor de meeste ontwikkelaars was dit echter iets moeilijker om mee te werken. Hier is het aantal configuraties en code dat u moet toevoegen om de service te implementeren veel kleiner geworden. Bovendien is het voor ontwikkelaars heel gemakkelijk om dit te repareren of te wijzigen. In het geval van overgangen, bijvoorbeeld naar een nieuwe versie van Nomad, kunnen ze alle bedieningsbestanden die zich op dezelfde plaats bevinden, overnemen en in bulk bijwerken.

Maar we kwamen ook verschillende nadelen tegen:

Het bleek dat wij kon geen naadloze implementatie realiseren in het geval van Nomade. Wanneer containers onder verschillende omstandigheden worden uitgerold, kan het blijken dat deze draait, en Nomad beschouwt het als een container die klaar is om verkeer te ontvangen. Dit gebeurde voordat de applicatie erin zelfs maar de kans had om te starten. Om deze reden begon het systeem gedurende een korte periode 500 fouten te produceren, omdat het verkeer naar een container begon te gaan die nog niet klaar was om deze te accepteren.

Wij zijn er enkele tegengekomen door de moerassen. De belangrijkste bug is dat Nomad niet goed overweg kan met een groot cluster als je veel systemen en containers hebt. Wanneer je één van de servers die in het Nomad cluster is opgenomen eruit wilt halen voor onderhoud, is de kans vrij groot dat het cluster niet zo lekker aanvoelt en uit elkaar valt. Sommige containers kunnen bijvoorbeeld vallen en niet stijgen - dit gaat u later veel kosten als al uw productiesystemen zich in een cluster bevinden dat wordt beheerd door Nomad.

Daarom besloten we na te denken over waar we heen moesten. Op dat moment werden we ons veel bewuster van wat we wilden bereiken. Namelijk: we willen betrouwbaarheid, iets meer functies dan Nomad biedt, en een volwassener, stabieler systeem.

In dit opzicht viel onze keuze op Kubernetes als het populairste platform voor het lanceren van clusters. Zeker gezien het formaat en aantal van onze containers groot genoeg was. Voor dergelijke doeleinden leek Kubernetes het meest geschikte systeem waar we naar konden kijken.

Overgang naar Kubernetes

Ik zal je iets vertellen over de basisconcepten van Kubernetes en hoe ze verschillen van Nomad.

Allereerst is het meest basale concept in Kubernetes het concept van pod. Peul is een groep van een of meer containers die altijd samen draaien. En ze werken altijd alsof ze strikt op één virtuele machine werken. Ze zijn voor elkaar toegankelijk via IP 127.0.0.1 op verschillende poorten.

Laten we aannemen dat je een PHP-applicatie hebt die bestaat uit nginx en php-fpm - het klassieke schema. Hoogstwaarschijnlijk wilt u zowel nginx- als php-fpm-containers te allen tijde bij elkaar houden. Met Kubernetes kunt u dit bereiken door ze als één gemeenschappelijke pod te beschrijven. Dit is precies wat we niet konden bereiken met Nomad.

Het tweede concept luidt inzet. Het feit is dat de capsule zelf een kortstondig iets is; het begint en verdwijnt. Wil je eerst al je eerdere containers vernietigen en dan in één keer nieuwe versies lanceren, of wil je ze geleidelijk uitrollen, dan is dit het proces waarvoor het concept van deployment verantwoordelijk is. Het beschrijft hoe u uw pods inzet, in welke hoeveelheid en hoe u ze kunt bijwerken.

Het derde concept luidt service. Uw service is feitelijk uw systeem, dat wat verkeer ontvangt en dit vervolgens doorstuurt naar een of meer pods die overeenkomen met uw service. Dat wil zeggen, u kunt zeggen dat al het binnenkomende verkeer naar die en die dienst met die en die naam naar deze specifieke pods moet worden gestuurd. En tegelijkertijd biedt het u verkeersbalans. Dat wil zeggen dat u twee pods van uw toepassing kunt starten, en al het binnenkomende verkeer wordt gelijkmatig verdeeld over de pods die aan deze service zijn gerelateerd.

En het vierde basisconcept is Ingress. Dit is een dienst die draait op een Kubernetes-cluster. Het fungeert als een externe load balancer die alle verzoeken overneemt. Met behulp van de Kubernetes API kan Ingress bepalen waar deze verzoeken naartoe moeten worden gestuurd. Bovendien doet hij dit zeer flexibel. Je kunt zeggen dat alle verzoeken aan deze host en die en die URL naar deze service worden verzonden. En deze verzoeken die naar deze host en naar een andere URL komen, worden naar een andere service verzonden.

Het leukste vanuit het perspectief van iemand die een applicatie ontwikkelt, is dat je het allemaal zelf kunt beheren. Door de Ingress-configuratie in te stellen, kunt u al het verkeer dat naar die en die API komt, naar aparte containers sturen die bijvoorbeeld in Go zijn geschreven. Maar dit verkeer, dat naar hetzelfde domein komt, maar naar een andere URL, moet naar containers worden gestuurd die in PHP zijn geschreven, waar veel logica is, maar ze zijn niet erg snel.

Als we al deze concepten vergelijken met Nomad, kunnen we zeggen dat de eerste drie concepten allemaal samen Service zijn. En dat laatste concept ontbreekt in Nomad zelf. We hebben hiervoor een externe balancer gebruikt: het kan haproxy, nginx, nginx+, enzovoort zijn. Bij een kubus hoeft u dit aanvullende concept niet apart te introduceren. Als je Ingress echter intern bekijkt, is het nginx, haproxy of traefik, maar min of meer ingebouwd in Kubernetes.

Alle concepten die ik heb beschreven zijn in feite bronnen die binnen een Kubernetes-cluster bestaan. Om ze in de kubus te beschrijven wordt een yaml-formaat gebruikt, dat in het geval van Nomad beter leesbaar en vertrouwder is dan HCL-bestanden. Maar structureel beschrijven ze hetzelfde in het geval van bijvoorbeeld pod. Ze zeggen: ik wil daar die en die pods inzetten, met die en die afbeeldingen, in die en die hoeveelheden.

Bovendien realiseerden we ons dat we niet elke afzonderlijke bron met de hand wilden creëren: implementatie, services, Ingress, enz. In plaats daarvan wilden we elk van onze systemen tijdens de implementatie beschrijven in termen van Kubernetes, zodat we niet alle benodigde resource-afhankelijkheden handmatig in de juiste volgorde opnieuw hoefden te creëren. Helm werd gekozen als het systeem waarmee we dit konden doen.

Basisconcepten in Helm

Helm is pakket manager voor Kubernetes. Het lijkt erg op hoe pakketbeheerders in programmeertalen werken. Ze stellen u in staat een dienst op te slaan die bijvoorbeeld bestaat uit deployment nginx, deployment php-fpm, config for Ingress, configmaps (dit is een entiteit waarmee u env en andere parameters voor uw systeem kunt instellen) in de vorm van zo- grafieken genoemd. Tegelijkertijd Helm draait bovenop Kubernetes. Dat wil zeggen, dit is niet een soort systeem dat opzij staat, maar gewoon een andere dienst die in de kubus wordt gelanceerd. Je communiceert ermee via de API via een consoleopdracht. Het gemak en de schoonheid ervan is dat zelfs als het roer kapot gaat of u het uit het cluster verwijdert, uw diensten niet zullen verdwijnen, aangezien het roer in wezen alleen dient om het systeem te starten. Kubernetes is dan zelf verantwoordelijk voor de performance en staat van dienstverlening.

Dat beseften wij ook sjabloonisering, wat we voorheen zelf moesten doen door jinja in onze configuraties te introduceren, is een van de belangrijkste kenmerken van helm. Alle configuraties die u voor uw systemen maakt, worden in helm opgeslagen in de vorm van sjablonen, een beetje vergelijkbaar met jinja, maar in feite met behulp van de sjablonen van de Go-taal, waarin helm is geschreven, zoals Kubernetes.

Helm voegt nog een paar concepten voor ons toe.

tabel - dit is een omschrijving van uw dienst. In andere pakketbeheerders zou het een pakket, bundel of iets dergelijks worden genoemd. Hier heet het diagram.

Values zijn de variabelen die u wilt gebruiken om uw configuraties op basis van sjablonen op te bouwen.

Sinds. Elke keer dat een service die wordt ingezet met behulp van helm, een incrementele versie van de release ontvangt. Helm onthoudt wat de serviceconfiguratie was in de vorige release, de release daarvoor, enzovoort. Als u daarom wilt terugdraaien, voert u gewoon de opdracht helm callback uit, waarbij u naar de vorige releaseversie verwijst. Zelfs als de corresponderende configuratie in uw repository niet beschikbaar is op het moment van terugdraaien, zal helm nog steeds onthouden wat het was en uw systeem terugzetten naar de staat waarin het zich bevond in de vorige release.

In het geval dat we helm gebruiken, veranderen reguliere configuraties voor Kubernetes ook in sjablonen waarin het mogelijk is om variabelen en functies te gebruiken en voorwaardelijke instructies toe te passen. Op deze manier kunt u uw serviceconfiguratie verzamelen, afhankelijk van de omgeving.

In de praktijk hebben we besloten om het net iets anders te doen dan bij Nomad. Als in Nomad zowel de implementatieconfiguraties als de n-variabelen die nodig waren om onze service te implementeren in één repository waren opgeslagen, hebben we hier besloten om ze in twee afzonderlijke repository's te verdelen. De “deploy”-repository slaat alleen n-variabelen op die nodig zijn voor de implementatie, en de “helm”-repository slaat configuraties of grafieken op.

Wat heeft dit ons opgeleverd?

Ondanks dat we in de configuratiebestanden zelf geen echt gevoelige gegevens opslaan. Bijvoorbeeld wachtwoorden voor databases. Ze worden als geheim opgeslagen in Kubernetes, maar toch zijn er nog bepaalde zaken waar we niet iedereen toegang toe willen geven. Daarom is de toegang tot de “implementatie”-repository beperkter en bevat de “helm”-repository eenvoudigweg een beschrijving van de dienst. Om deze reden is het veilig toegankelijk voor een groter aantal mensen.

Omdat we niet alleen productie hebben, maar ook andere omgevingen, kunnen we dankzij deze scheiding onze roerkaarten hergebruiken om niet alleen diensten in te zetten voor de productie, maar bijvoorbeeld ook voor een QA-omgeving. Zelfs om ze lokaal in te zetten met behulp van Minikubus - dit is iets om Kubernetes lokaal uit te voeren.

Binnen elke repository hebben we voor elke service een indeling in afzonderlijke mappen achtergelaten. Dat wil zeggen dat er in elke map sjablonen staan ​​die verband houden met het bijbehorende diagram en die de bronnen beschrijven die moeten worden ingezet om ons systeem te laten draaien. We hebben alleen envs in de 'implementeer'-repository gelaten. In dit geval hebben we geen gebruik gemaakt van sjablonen met Jinja, omdat helm zelf kant-en-klare sjablonen biedt - dit is een van de belangrijkste functies ervan.

We hebben een implementatiescript achtergelaten - deploy.sh, dat de lancering voor implementatie met behulp van helm vereenvoudigt en standaardiseert. Dus voor iedereen die wil implementeren, ziet de implementatie-interface er precies hetzelfde uit als bij de implementatie via Nomad. Dezelfde implement.sh, de naam van uw service en waar u deze wilt implementeren. Hierdoor komt het roer intern op gang. Het verzamelt op zijn beurt configuraties uit sjablonen, voegt de benodigde waardebestanden erin in, implementeert ze vervolgens en lanceert ze in Kubernetes.

Bevindingen

De Kubernetes-service lijkt complexer dan Nomad.

Hier komt uitgaand verkeer naar Ingress. Dit is slechts de frontcontroller, die alle verzoeken overneemt en deze vervolgens naar de diensten stuurt die overeenkomen met de verzoekgegevens. Het bepaalt deze op basis van configuraties die deel uitmaken van de beschrijving van uw applicatie in roer en die ontwikkelaars zelf hebben ingesteld. De service verzendt verzoeken naar zijn pods, dat wil zeggen naar specifieke containers, en verdeelt inkomend verkeer tussen alle containers die bij deze service horen. En we mogen natuurlijk niet vergeten dat we op netwerkniveau niets anders mogen doen dan beveiliging. Daarom werkt segmentatie in een Kubernetes-cluster, dat is gebaseerd op tagging. Alle services hebben bepaalde tags waaraan de toegangsrechten van de services tot bepaalde externe/interne bronnen binnen of buiten het cluster zijn gekoppeld.

Toen we de overstap maakten, zagen we dat Kubernetes alle mogelijkheden van Nomad had, die we eerder hadden gebruikt, en ook veel nieuwe dingen had toegevoegd. Het kan worden uitgebreid via plug-ins, en in feite via aangepaste brontypen. Dat wil zeggen dat u niet alleen de mogelijkheid heeft om iets te gebruiken dat kant-en-klaar bij Kubernetes wordt geleverd, maar om uw eigen bron en service te creëren die uw bron leest. Dit geeft u extra mogelijkheden om uw systeem uit te breiden zonder dat u Kubernetes opnieuw hoeft te installeren en zonder dat er aanpassingen nodig zijn.

Een voorbeeld van dergelijk gebruik is Prometheus, dat binnen ons Kubernetes-cluster draait. Om ervoor te zorgen dat het statistieken van een bepaalde service gaat verzamelen, moeten we een extra type bron, de zogenaamde servicemonitor, aan de servicebeschrijving toevoegen. Prometheus begint, vanwege het feit dat het een aangepast resourcetype kan lezen wanneer het in Kubernetes wordt gelanceerd, automatisch met het verzamelen van statistieken van het nieuwe systeem. Het is best handig.

De eerste implementatie die we met Kubernetes hebben uitgevoerd, was in maart 2018. En gedurende deze tijd hebben wij er nooit problemen mee ondervonden. Het werkt redelijk stabiel zonder noemenswaardige bugs. Bovendien kunnen we het nog verder uitbreiden. Tegenwoordig hebben we genoeg van de mogelijkheden die het heeft, en we zijn erg tevreden over het tempo van de ontwikkeling van Kubernetes. Momenteel staan ​​er ruim 3000 containers in Kubernetes. Het cluster beslaat verschillende knooppunten. Tegelijkertijd is het bruikbaar, stabiel en zeer controleerbaar.

Bron: www.habr.com