virtuele servers<\/a>, gebruikten we Ansible, waarbij de configuraties in dezelfde repository lagen. Voor de meeste ontwikkelaars was het echter iets moeilijker om hiermee om te gaan. Hierdoor werd de hoeveelheid configuraties en code die je moest toevoegen om een service te deployen aanzienlijk kleiner. Bovendien is het voor DevOps heel gemakkelijk om het aan te passen of te wijzigen. In het geval van migraties, bijvoorbeeld naar een nieuwe versie van Nomad, kunnen ze eenvoudig alle uitvoerende bestanden die zich op dezelfde locatie bevinden, massaal bijwerken.<\/li>\n<\/ol>\n\nMaar we kwamen ook enkele nadelen tegen: <\/p>\n
Het bleek dat we geen naadloze deployments konden bereiken <\/b>met Nomad. Bij het uitrollen van containers uit verschillende omgevingen kon het gebeuren dat een container al werd gestart, en Nomad het beschouwde als klaar om verkeer te accepteren. Dit gebeurde nog voordat de applicatie erin was gestart. Om deze reden begon het systeem gedurende een korte periode 500-fouten te geven, omdat het verkeer begon te sturen naar een container die nog niet klaar was om het te ontvangen. <\/p>\n
We stuiten op enkele bugs<\/b>. De grootste uitdaging is dat Nomad niet goed omgaat met grote clusters, vooral als je veel systemen en containers hebt. Wanneer je een van de servers die deel uitmaakt van het Nomad-cluster wilt onderhouden, is er een aanzienlijke kans dat het cluster destabiliseert en uit elkaar valt. Een deel van de containers kan bijvoorbeeld crashen en niet herstarten \u2014 dit kan je later veel kosten als al je systemen in productie zich in het cluster bevinden dat door Nomad wordt beheerd. <\/p>\n
Daarom hebben we besloten na te denken over onze volgende stappen. Op dat moment waren we veel beter bewust van wat we wilden bereiken. Namelijk: we willen betrouwbaarheid, iets meer functionaliteit dan Nomad biedt, en een volwassener, stabieler systeem. <\/p>\n
In dit opzicht hebben we voor Kubernetes gekozen als de meest populaire platform voor het draaien van clusters. Vooral gezien het feit dat de grootte en het aantal van onze containers behoorlijk groot was. Voor deze doeleinden leek Kubernetes het meest geschikte systeem uit de opties die we konden bekijken. <\/p>\n
Overstap naar Kubernetes<\/h1>\n \nIk wil kort de belangrijkste concepten van Kubernetes bespreken en hoe ze verschillen van Nomad. <\/p>\n
Pod<\/b> is een groep van \u00e9\u00e9n of meerdere containers die altijd samen worden uitgevoerd. Ze functioneren alsof ze altijd op \u00e9\u00e9n virtuele machine draaien. Ze zijn toegankelijk voor elkaar via het IP-adres 127.0.0.1 op verschillende poorten. <\/p>\n
Stel dat je een PHP-applicatie hebt die bestaat uit nginx en php-fpm \u2013 een klassieke opzet. Waarschijnlijk wil je dat zowel de nginx- als de php-fpm-containers altijd samen zijn. Kubernetes maakt dit mogelijk door ze als \u00e9\u00e9n gezamenlijke pod te beschrijven. Dit was precies wat we niet konden bereiken met Nomad.<\/p>\n
Een tweede begrip is deployment<\/b>. Het punt is dat een pod op zich een ephemeraal iets is, het wordt opgestart en verdwijnt. Wil je eerst al je eerdere containers stoppen en dan meteen nieuwe versies lanceren, of wil je ze geleidelijk uitrollen \u2013 dit proces valt onder het begrip deployment. Het beschrijft hoe je je pods implementeert, in welke hoeveelheid en hoe je ze updatet. <\/p>\n
Een derde begrip is voor het SystemD-initiesysteem:<\/b>. Uw service is feitelijk uw systeem dat enig verkeer ontvangt en dit vervolgens naar een of meerdere pods leidt die bij uw service passen. Dit betekent dat u kunt aangeven dat al het inkomende verkeer voor een bepaalde service met een bepaalde naam naar specifiek deze pods moet worden gestuurd. En tegelijkertijd zorgt het voor traffic balancing. U kunt bijvoorbeeld twee pods van uw applicatie starten, en al het inkomende verkeer wordt gelijkmatig verdeeld tussen de betreffende pods van deze service.<\/p>\n
En het vierde belangrijke concept \u2014 Ingress<\/b>. Dit is een service die wordt uitgevoerd in een Kubernetes-cluster. Het fungeert als een externe load balancer die alle aanvragen op zich neemt. Via de Kubernetes API kan Ingress bepalen waar deze aanvragen naartoe moeten worden gestuurd. En dat kan heel flexibel. U kunt aangeven dat alle aanvragen naar deze host en deze bepaalde URL naar deze service moeten worden gestuurd. En de aanvragen die komen naar deze host en een andere URL, moeten naar een andere service worden gestuurd. <\/p>\n
Het mooiste voor de ontwikkelaar van de applicatie is dat je hieraan zelf kunt beheren. Door de Ingress-configuratie in te stellen, kunt u al het verkeer dat binnenkomt op een bepaalde API, naar afzonderlijke containers sturen, bijvoorbeeld geschreven in Go. En dat verkeer, dat binnenkomt op dezelfde domein, maar naar een andere URL, naar containers sturen die zijn geschreven in PHP, waar veel logica aanwezig is, maar die niet erg snel zijn.<\/p>\n
Als we al deze concepten vergelijken met Nomad, kunnen we zeggen dat de eerste drie concepten samen een Service vormen. Het laatste concept ontbreekt in Nomad. We gebruikten hiervoor een externe load balancer: dat kan haproxy, nginx, nginx+ enzovoort zijn. In het geval van Kubernetes hoeft u dit extra concept niet apart in te voeren. Echter, als we Ingress intern bekijken, is het \u043b\u0438\u0431\u043e nginx, \u043b\u0438\u0431\u043e haproxy, \u043b\u0438\u0431\u043e traefik, maar ingebouwd in Kubernetes. <\/p>\n
Al deze concepten die ik beschrijf, zijn in wezen bronnen die bestaan binnen het Kubernetes-cluster. Voor hun beschrijving in Kubernetes wordt het yaml-formaat gebruikt, dat leesbaarder en gebruikelijker is dan HCL-bestanden in het geval van Nomad. Maar structureel beschrijven ze in het geval van bijvoorbeeld een pod hetzelfde. Ze zeggen: ik wil deze pods daar implementeren, met deze imago's, in deze hoeveelheid. <\/p>\n
Basisconcepten in Helm<\/h1>\n \nHelm is een pakketbeheerder<\/b> voor Kubernetes. Het lijkt erg op hoe pakketbeheerders in programmeertalen werken. Ze stellen je in staat om een service, bestaande uit bijvoorbeeld een nginx deployment, een php-fpm deployment, configuratie voor Ingress, configmaps (dit is een entiteit waarmee je env en andere parameters voor je systeem kunt instellen) in de vorm van zogenaamde charts op te slaan. Helm werkt bovenop Kubernetes<\/b>. Dit is dus niet een systeem dat aan de zijlijn staat, maar gewoon weer een service die binnen de cluster draait. Je interacteert met het via zijn API via een commandoregelopdracht. Het gemak en de schoonheid ervan liggen in het feit dat zelfs als Helm kapot gaat of je het uit de cluster verwijdert, jouw services niet verdwijnen, aangezien Helm in wezen alleen dient om het systeem te starten. De werking en status van de services blijft verder het verantwoordelijk van Kubernetes. <\/p>\n
We hebben ook begrepen dat sjablonering<\/b>, die we tot nu toe gedwongen waren zelf te doen door jinja in onze configuraties te integreren, een van de belangrijkste mogelijkheden van Helm is. Alle configuraties die je maakt voor jouw systemen, worden in Helm opgeslagen als sjablonen, die een beetje op jinja lijken, maar in werkelijkheid gebruik maken van de templating van de Go-taal, waarop Helm is geschreven, net als Kubernetes. <\/p>\n
Helm voegt ons nog een paar extra concepten toe. <\/p>\n
Chart<\/b> is de beschrijving van jouw service. In andere pakketbeheerders zou dit een pakket, bundle of iets dergelijks worden genoemd. Hier heet het chart. <\/p>\n
Values <\/b>zijn de variabelen die je wilt gebruiken om jouw configuraties uit sjablonen te bouwen. <\/p>\n
Release<\/b>Elke keer dat een service via helm wordt gedeployed, krijgt het een incrementele versie van de release. Helm onthoudt welke configuratie de service had bij de vorige, voorlaatste release, en zo verder. Dus als het nodig is om terug te rollen, volstaat het om de helm callback-opdracht uit te voeren, waarbij je de vorige versie van de release opgeeft. Zelfs als de overeenkomstige configuratie op dat moment niet beschikbaar is in jouw repository, onthoudt helm nog steeds hoe deze was en zal het jouw systeem terugzetten naar de staat waarin het zich bevond bij de vorige release. <\/p>\n
Wanneer we helm gebruiken, worden de gebruikelijke configuraties voor Kubernetes ook sjablonen waarin je variabelen, functies en conditionele operators kunt gebruiken. Op deze manier kun je de configuratie van jouw service samenstellen afhankelijk van de omgeving.<\/p>\n
Hoewel we in de configuratiebestanden zelf geen echt gevoelige gegevens opslaan, zoals wachtwoorden voor databases. Deze worden opgeslagen als secrets in Kubernetes, maar toch zijn er specifieke elementen waartoe we niet willen dat iedereen toegang heeft. Daarom is de toegang tot de 'deploy'-repository beperkter, terwijl de 'helm'-repository gewoon een beschrijving van de service bevat. Om deze reden kan er veilig toegang worden gegeven aan een breder publiek. <\/p>\n
Omdat we niet alleen productieomgevingen hebben, maar ook andere omgevingen, kunnen we dankzij deze scheiding onze helm-charts hergebruiken om services niet alleen in productie te deployen, maar ook bijvoorbeeld in een QA-omgeving. Zelfs om ze lokaal te draaien met behulp van Minikube<\/i> \u2014 dit is een tool voor het lokaal draaien van Kubernetes. <\/p>\n
Binnen elke repository hebben we de structuur verdeeld in aparte directories voor elke service. Dat wil zeggen, binnen elke directory bevinden zich sjablonen die betrekking hebben op de respectieve chart en de middelen beschrijven die moeten worden gedeployed om ons systeem op te starten. In de repository 'deploy' hebben we alleen de envs achtergelaten. In dit geval hebben we geen sjabloonverwerking met jinja gebruikt, omdat helm zelf sjabloonverwerking out-of-the-box biedt - dit is een van zijn belangrijkste functies. <\/p>\n
We hebben een script voor de deployment achtergelaten - deploy.sh, dat het starten van de deployment met helm vereenvoudigt en standaardiseert. Op deze manier ziet de deployment-interface voor iedereen die wil deployen er exact hetzelfde uit als bij een deployment via Nomad. Hetzelfde deploy.sh, de naam van uw service, en waar u deze wilt deployen. Dit leidt ertoe dat helm van binnenuit wordt gestart. Het verzamelt op zijn beurt de configuraties uit de sjablonen, vult deze aan met de benodigde values-bestanden en deployt vervolgens in Kubernetes. <\/p>\n
Conclusies<\/h1>\n \nDe Kubernetes-service lijkt ingewikkelder dan Nomad. <\/p>\n
Tijdens de overgang zagen we dat Kubernetes alle functies heeft die Nomad, dat we eerder gebruikten, biedt, en voegt bovendien veel nieuwe mogelijkheden toe. Het kan worden uitgebreid via plug-ins en daadwerkelijk via aangepaste type middelen. Dit betekent dat je niet alleen iets kunt gebruiken dat standaard in Kubernetes zit, maar ook je eigen bron en service kunt cre\u00ebren die je bron leest. Dit biedt extra mogelijkheden om je systeem uit te breiden zonder Kubernetes opnieuw te installeren of wijzigingen aan te brengen. <\/p>\n
Een voorbeeld van dit gebruik is Prometheus, dat binnen ons Kubernetes-cluster draait. Om metrics van een bepaalde service te beginnen verzamelen, moeten we een extra type bron, de zogenaamde service-monitor, aan de servicebeschrijving toevoegen. Omdat Prometheus, als het draait in Kubernetes, aangepaste type middelen kan uitlezen, begint het automatisch met het verzamelen van metrics van het nieuwe systeem. Dit is erg handig. <\/p>\n
De eerste deployment die we in Kubernetes hebben gedaan was in maart 2018. En in die tijd hebben we nooit problemen ervaren. Het werkt vrij stabiel zonder significante bugs. Bovendien kunnen we het verder uitbreiden. Tot op heden voldoen de mogelijkheden die het heeft aan onze eisen en we zijn erg tevreden met de ontwikkeling van Kubernetes. Op dit moment zijn er meer dan 3000 containers in Kubernetes. Het cluster bestaat uit verschillende nodes. Het is goed beheerd, stabiel en zeer controleerbaar.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda. \u0412 2018 \u0433\u043e\u0434\u0443 \u044f \u0432\u044b\u0441\u0442\u0443\u043f\u0430\u043b \u043d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 HighLoad++, \u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0445\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0443 \u0441\u0432\u043e\u0435\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u041c\u043e\u044f \u0442\u0435\u043c\u0430 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043e\u043f\u044b\u0442\u0443 \u043d\u0430\u0448\u0435\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u043f\u043e \u0434\u0435\u043f\u043b\u043e\u044e \u0441\u0438\u0441\u0442\u0435\u043c \u0438 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0432 \u0440\u0430\u0437\u043d\u044b\u0435 \u0441\u0440\u0435\u0434\u044b. \u041d\u0430\u0447\u0438\u043d\u0430\u044f \u043e\u0442 \u043d\u0430\u0448\u0438\u0445 \u0434\u043e\u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0432\u0440\u0435\u043c\u0435\u043d, \u043a\u043e\u0433\u0434\u0430 \u043c\u044b \u0434\u0435\u043f\u043b\u043e\u0438\u043b\u0438 \u0432\u0441\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25343,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33654","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Video](\"https:\/\/img.youtube.com\/vi\/oqrb7dWECSo\/hqdefault.jpg\")
\r\n