Kubernetes is een geweldig hulpmiddel voor het uitvoeren van Docker-containers in een geclusterde productieomgeving. Er zijn echter problemen die Kubernetes niet kan oplossen. Voor frequente productie-implementaties hebben we een volledig geautomatiseerde Blue/Green-implementatie nodig om downtime in het proces te voorkomen, waarbij ook externe HTTP-verzoeken moeten worden afgehandeld en SSL-offloads moeten worden uitgevoerd. Dit vereist integratie met een load balancer zoals ha-proxy. Een andere uitdaging is het semi-automatisch schalen van het Kubernetes-cluster zelf wanneer het in een cloudomgeving draait, bijvoorbeeld door het cluster 's nachts gedeeltelijk terug te schalen.
Hoewel Kubernetes deze functies niet standaard heeft, biedt het wel een API die u kunt gebruiken om soortgelijke problemen op te lossen. Tools voor geautomatiseerde Blue/Green-implementatie en schaling van een Kubernetes-cluster zijn ontwikkeld als onderdeel van het Cloud RTI-project, dat tot stand is gekomen op basis van open source.
Dit artikel, een videotranscriptie, laat zien hoe je Kubernetes samen met andere open source-componenten instelt om een productieklare omgeving te creëren die code van een Git-commit accepteert zonder downtime in de productie.
Dus zodra je vanuit de buitenwereld toegang hebt tot je applicaties, kun je beginnen met het volledig opzetten van de automatisering, dat wil zeggen, het naar het stadium brengen waarin je een git commit kunt uitvoeren en ervoor kunt zorgen dat deze git commit in productie komt. Bij het implementeren van deze stappen, bij het implementeren van de implementatie, willen we uiteraard geen downtime tegenkomen. Elke automatisering in Kubernetes begint dus met de API.
Kubernetes is geen tool die out-of-the-box productief kan worden ingezet. Natuurlijk kun je dat doen, kubectl gebruiken enzovoort, maar toch is de API het meest interessante en nuttige aan dit platform. Door de API als een reeks functies te gebruiken, hebt u toegang tot vrijwel alles wat u in Kubernetes wilt doen. kubectl zelf maakt ook gebruik van de REST API.
Dit is REST, dus je kunt elke taal of tool gebruiken om met deze API te werken, maar je leven zal veel gemakkelijker worden gemaakt door aangepaste bibliotheken. Mijn team heeft twee van dergelijke bibliotheken geschreven: één voor Java/OSGi en één voor Go. De tweede wordt niet vaak gebruikt, maar deze handige dingen heb je in ieder geval tot je beschikking. Het is een gedeeltelijk gelicentieerd open-sourceproject. Er zijn veel van dergelijke bibliotheken voor verschillende talen, dus u kunt degene kiezen die het beste bij u past.
Voordat u begint met het automatiseren van uw implementatie, moet u er dus voor zorgen dat het proces geen downtime met zich meebrengt. Ons team voert productie-implementaties bijvoorbeeld midden op de dag uit, wanneer mensen de applicaties het meest gebruiken. Het is dus belangrijk om vertragingen in dit proces te voorkomen. Om downtime te voorkomen, worden 2 methoden gebruikt: blauw/groene implementatie of rolling update. In het laatste geval worden, als u vijf replica's van de applicatie draait, deze één voor één bijgewerkt. Deze methode werkt prima, maar is niet geschikt als u tijdens het implementatieproces verschillende versies van de applicatie tegelijkertijd laat draaien. In dit geval kunt u de gebruikersinterface bijwerken terwijl de backend de oude versie gebruikt, waardoor de applicatie niet meer werkt. Daarom is het werken in dergelijke omstandigheden vanuit programmeeroogpunt behoorlijk moeilijk.
Dit is één van de redenen waarom wij de voorkeur geven aan blauw/groene implementatie om de implementatie van onze applicaties te automatiseren. Met deze methode moet u ervoor zorgen dat er slechts één versie van de applicatie tegelijk actief is.
Het blauw/groene implementatiemechanisme ziet er als volgt uit. We ontvangen verkeer voor onze applicaties via ha-proxy, die het doorstuurt naar actieve replica's van de applicatie van dezelfde versie.
Wanneer er een nieuwe implementatie wordt gemaakt, gebruiken we Deployer, die de nieuwe componenten krijgt en de nieuwe versie implementeert. Het inzetten van een nieuwe versie van een applicatie betekent dat er een nieuwe set replica’s wordt ‘opgehoogd’, waarna deze replica’s van de nieuwe versie in een aparte, nieuwe pod worden gelanceerd. Ha-proxy weet er echter niets van en stuurt er nog geen werklast naar toe.
Daarom is het allereerst noodzakelijk om een prestatiecontrole uit te voeren van nieuwe versies van de statuscontrole om ervoor te zorgen dat de replica's gereed zijn voor de belasting.
Alle implementatiecomponenten moeten een of andere vorm van statuscontrole ondersteunen. Dit kan een heel eenvoudige HTTP call check zijn, wanneer je een code ontvangt met status 200, of een meer diepgaande check, waarbij je de verbinding van de replica’s met de database en andere services, de stabiliteit van de dynamische omgevingsverbindingen controleert en of alles correct start en werkt. Dit proces kan behoorlijk complex zijn.
Nadat het systeem heeft geverifieerd dat alle bijgewerkte replica's werken, zal Deployer de configuratie bijwerken en de juiste confd doorgeven, waardoor ha-proxy opnieuw wordt geconfigureerd.
Pas daarna zal het verkeer naar de pod met replica's van de nieuwe versie worden geleid en zal de oude pod verdwijnen.
Dit mechanisme is geen kenmerk van Kubernetes. Het concept van blauw/groen-implementatie bestaat al geruime tijd en er is altijd gebruik gemaakt van een load balancer. Eerst stuurt u al het verkeer naar de oude versie van de applicatie en na de update zet u dit volledig over naar de nieuwe versie. Dit principe wordt niet alleen in Kubernetes gebruikt.
Nu zal ik u kennis laten maken met een nieuwe implementatiecomponent: Deployer, die statuscontroles uitvoert, proxy's opnieuw configureert, enzovoort. Dit is een concept dat niet van toepassing is op de buitenwereld en binnen Kubernetes bestaat. Ik laat je zien hoe je met open source tools je eigen Deployer-concept kunt creëren.
Het eerste dat Deployer doet, is dus een RC-replicatiecontroller maken met behulp van de Kubernetes API. Deze API creëert pods en services voor verdere implementatie, dat wil zeggen, het creëert een volledig nieuw cluster voor onze applicaties. Zodra RC ervan overtuigd is dat de replica's zijn gestart, voert het een Health check uit op hun functionaliteit. Hiervoor gebruikt Deployer de opdracht GET /health. Het voert de juiste scancomponenten uit en controleert alle elementen die de werking van het cluster ondersteunen.
Nadat alle peulen hun status hebben gerapporteerd, maakt Deployer een nieuw configuratie-element - etcd gedistribueerde opslag, dat intern door Kubernetes wordt gebruikt, inclusief het opslaan van de load balancer-configuratie. We schrijven gegevens naar etcd, en een kleine tool genaamd confd monitors etcd voor nieuwe gegevens.
Als het wijzigingen in de initiële configuratie detecteert, genereert het een nieuw instellingenbestand en draagt dit over naar ha-proxy. In dit geval start ha-proxy opnieuw op zonder enige verbinding te verliezen en richt het de belasting op nieuwe services die ervoor zorgen dat de nieuwe versie van onze applicaties werkt.
Zoals je kunt zien, is er, ondanks de overvloed aan componenten, hier niets ingewikkelds. Je hoeft alleen maar meer aandacht te besteden aan de API en etcd. Ik wil je vertellen over de opensource-deployer die wij zelf gebruiken: Amdatu Kubernetes Deployer.
Het is een tool voor het orkestreren van Kubernetes-implementaties en heeft de volgende kenmerken:
- Blauw/Groene inzet;
- het opzetten van een externe load balancer;
- beheer van implementatiedescriptoren;
- het beheren van de daadwerkelijke inzet;
- het controleren van de functionaliteit van Health checks tijdens de implementatie;
- implementatie van omgevingsvariabelen in pods.
Deze Deployer is bovenop de Kubernetes API gebouwd en biedt een REST API voor het beheren van handvatten en implementaties, evenals een Websocket API voor het streamen van logs tijdens het implementatieproces.
Het plaatst de configuratiegegevens van de load balancer in etcd, zodat u geen ha-proxy hoeft te gebruiken met kant-en-klare ondersteuning, maar eenvoudig uw eigen load balancer-configuratiebestand kunt gebruiken. Amdatu Deployer is geschreven in Go, net als Kubernetes zelf, en heeft een licentie van Apache.
Voordat ik deze versie van de implementer begon te gebruiken, gebruikte ik de volgende implementatiedescriptor, die de parameters specificeert die ik nodig heb.
Een van de belangrijke parameters van deze code is het inschakelen van de vlag “useHealthCheck”. We moeten specificeren dat er tijdens het implementatieproces een sanity check moet worden uitgevoerd. Deze instelling kan worden uitgeschakeld wanneer de implementatie containers van derden gebruikt die niet hoeven te worden geverifieerd. Deze descriptor geeft ook het aantal replica's en de frontend-URL aan die ha-proxy nodig heeft. Aan het einde staat de podspecificatievlag "podspec", die Kubernetes aanroept voor informatie over poortconfiguratie, afbeelding, enz. Dit is een vrij eenvoudige JSON-descriptor.
Een andere tool die deel uitmaakt van het open-source Amdatu-project is Deploymentctl. Het heeft een gebruikersinterface voor het configureren van implementaties, slaat de implementatiegeschiedenis op en bevat webhooks voor callbacks van externe gebruikers en ontwikkelaars. U mag de gebruikersinterface niet gebruiken omdat Amdatu Deployer zelf een REST API is, maar deze interface kan de implementatie veel eenvoudiger voor u maken zonder dat er een API bij betrokken is. Deploymentctl is geschreven in OSGi/Vertx met behulp van Angular 2.
Ik zal het bovenstaande nu op het scherm demonstreren met behulp van een vooraf opgenomen opname, zodat u niet hoeft te wachten. We gaan een eenvoudige Go-applicatie inzetten. Maak je geen zorgen als je Go nog niet eerder hebt geprobeerd. Het is een heel eenvoudige applicatie, dus je zou het wel moeten kunnen begrijpen.
Hier maken we een HTTP-server die alleen reageert op /health, dus deze applicatie test alleen de statuscheck en niets anders. Als de controle slaagt, wordt de onderstaande JSON-structuur gebruikt. Het bevat de versie van de applicatie die door de implementeerder zal worden geïmplementeerd, het bericht dat u bovenaan het bestand ziet en het Booleaanse gegevenstype - of onze applicatie werkt of niet.
Ik heb een beetje vals gespeeld met de laatste regel, omdat ik bovenaan het bestand een vaste Booleaanse waarde heb geplaatst, waardoor ik in de toekomst zelfs een "ongezonde" applicatie kan implementeren. We zullen dit later afhandelen.
Dus laten we beginnen. Eerst controleren we op de aanwezigheid van actieve pods met behulp van de opdracht ~ kubectl get pods en, op basis van het ontbreken van een reactie van de frontend-URL, zorgen we ervoor dat er momenteel geen implementaties plaatsvinden.
Vervolgens zie je de Deploymentctl-interface die ik noemde, waarin implementatieparameters worden ingesteld: naamruimte, applicatienaam, implementatieversie, aantal replica's, front-end URL, containernaam, afbeelding, resourcelimieten, poortnummer voor gezondheidscontrole, enz.. Resourcelimieten zijn erg belangrijk, omdat u hierdoor de maximaal mogelijke hoeveelheid hardware kunt gebruiken. Hier kunt u ook het implementatielogboek bekijken.
Als je nu het commando ~ kubectl get pods herhaalt, kun je zien dat het systeem gedurende 20 seconden “bevriest”, gedurende welke ha-proxy opnieuw wordt geconfigureerd. Hierna start de pod en is onze replica te zien in het implementatielogboek.
Ik heb de wachttijd van 20 seconden uit de video verwijderd en nu kun je op het scherm zien dat de eerste versie van de applicatie is geïmplementeerd. Dit alles werd gedaan met behulp van alleen de gebruikersinterface.
Laten we nu de tweede versie proberen. Om dit te doen, verander ik het bericht van de applicatie van "Hallo, Kubernetes!" op “Hallo, Deployer!”, maakt het systeem deze image en plaatst deze in het Docker-register, waarna we eenvoudigweg opnieuw op de knop “Deploy” klikken in het Deploymentctl-venster. In dit geval wordt het implementatielogboek automatisch gestart op dezelfde manier als bij het implementeren van de eerste versie van de applicatie.
Het commando ~ kubectl get pods laat zien dat er momenteel twee versies van de applicatie actief zijn, maar de frontend laat zien dat we nog steeds versie 2 gebruiken.
De load balancer wacht tot de statuscontrole is voltooid voordat het verkeer wordt omgeleid naar de nieuwe versie. Na 20 seconden schakelen we over naar curl en zien dat we nu versie 2 van de applicatie hebben geïmplementeerd en de eerste is verwijderd.
Dit was de inzet van een “gezonde” applicatie. Laten we eens kijken wat er gebeurt als ik voor een nieuwe versie van de applicatie de parameter Healthy verander van true in false, dat wil zeggen dat ik probeer een ongezonde applicatie te implementeren die de statuscheck niet heeft doorstaan. Dit kan gebeuren als er tijdens de ontwikkelingsfase configuratiefouten in de applicatie zijn gemaakt en deze in deze vorm naar productie is gestuurd.
Zoals u kunt zien, doorloopt de implementatie alle bovenstaande stappen en ~kubectl get pods laat zien dat beide pods actief zijn. Maar in tegenstelling tot de vorige implementatie toont het logboek de time-outstatus. Dat wil zeggen dat vanwege het feit dat de statuscheck is mislukt, de nieuwe versie van de applicatie niet kan worden geïmplementeerd. Als gevolg hiervan ziet u dat het systeem is teruggekeerd naar het gebruik van de oude versie van de applicatie en dat de nieuwe versie eenvoudigweg is verwijderd.
Het goede hieraan is dat zelfs als er een groot aantal gelijktijdige verzoeken binnenkomen in de applicatie, ze de downtime niet eens zullen merken tijdens het implementeren van de implementatieprocedure. Als u deze applicatie test met behulp van het Gatling-framework, dat zoveel mogelijk verzoeken verzendt, wordt geen van deze verzoeken verwijderd. Dit betekent dat onze gebruikers versie-updates niet eens in realtime zullen opmerken. Als het niet lukt, wordt er verder gewerkt aan de oude versie; als het lukt, stappen gebruikers over naar de nieuwe versie.
Er is maar één ding dat kan mislukken: als de gezondheidscontrole slaagt, maar de applicatie faalt zodra de werklast erop wordt toegepast, dat wil zeggen dat de ineenstorting pas zal plaatsvinden nadat de implementatie is voltooid. In dit geval moet u handmatig teruggaan naar de oude versie. Daarom hebben we gekeken hoe we Kubernetes kunnen gebruiken met de open-sourcetools die ervoor zijn ontworpen. Het implementatieproces zal veel eenvoudiger zijn als u deze tools in uw Build/Deploy-pijplijnen inbouwt. Tegelijkertijd kunt u, om de implementatie te starten, de gebruikersinterface gebruiken of dit proces volledig automatiseren door bijvoorbeeld commit to master te gebruiken.
Onze Build Server maakt een Docker-image en duwt deze in Docker Hub of welk register u ook gebruikt. Docker Hub ondersteunt webhook, zodat we implementatie op afstand via Deployer kunnen activeren op de manier die hierboven wordt weergegeven. Op deze manier kunt u de implementatie van uw applicatie naar potentiële productie volledig automatiseren.
Laten we verder gaan met het volgende onderwerp: het schalen van het Kubernetes-cluster. Houd er rekening mee dat de kubectl-opdracht een schalingsopdracht is. Met meer hulp kunnen we het aantal replica's in ons bestaande cluster eenvoudig vergroten. In de praktijk willen we echter meestal het aantal knooppunten vergroten in plaats van het aantal pods.
Tegelijkertijd moet u tijdens werkuren mogelijk de kosten van Amazon-services verhogen, en 's nachts moet u mogelijk het aantal actieve applicatie-exemplaren verminderen om de kosten van Amazon-services te verlagen. Dit betekent niet dat het schalen van alleen het aantal pods voldoende zal zijn, want zelfs als een van de knooppunten inactief is, zul je Amazon er nog steeds voor moeten betalen. Dat wil zeggen dat u naast het schalen van de pods ook het aantal gebruikte machines moet schalen.
Dit kan een uitdaging zijn, want of we nu Amazon of een andere cloudservice gebruiken, Kubernetes weet niets over het aantal machines dat wordt gebruikt. Er ontbreekt een tool waarmee u het systeem op knooppuntniveau kunt schalen.
We zullen dus voor zowel knooppunten als pods moeten zorgen. We kunnen de lancering van nieuwe knooppunten eenvoudig schalen met behulp van de AWS API en Scaling group-machines om het aantal Kubernetes-werkknooppunten te configureren. U kunt ook cloud-init of een soortgelijk script gebruiken om knooppunten in het Kubernetes-cluster te registreren.
De nieuwe machine start in de Scaling-groep, initieert zichzelf als knooppunt, registreert zich in het masterregister en begint te werken. Hierna kunt u het aantal replica's voor gebruik op de resulterende knooppunten verhogen. Het terugschalen vergt meer inspanning, omdat je ervoor moet zorgen dat een dergelijke stap niet leidt tot de vernietiging van reeds actieve applicaties na het uitschakelen van “onnodige” machines. Om een dergelijk scenario te voorkomen, moet u de knooppunten op de status ‘niet-roosterbaar’ zetten. Dit betekent dat de standaardplanner deze knooppunten negeert bij het plannen van DaemonSet-pods. De planner verwijdert niets van deze servers, maar lanceert daar ook geen nieuwe containers. De volgende stap is het verwijderen van het drainknooppunt, dat wil zeggen het overbrengen van running pods ervan naar een andere machine, of andere knooppunten die hiervoor voldoende capaciteit hebben. Zodra u zeker weet dat er geen containers meer op deze knooppunten staan, kunt u deze uit Kubernetes verwijderen. Hierna houden ze simpelweg op te bestaan voor Kubernetes. Vervolgens moet u de AWS API gebruiken om onnodige knooppunten of machines uit te schakelen.
U kunt Amdatu Scalerd gebruiken, een andere open-source schalingstool vergelijkbaar met de AWS API. Het biedt een CLI om knooppunten in een cluster toe te voegen of te verwijderen. De interessante functie is de mogelijkheid om de planner te configureren met behulp van het volgende json-bestand.
De getoonde code reduceert de clustercapaciteit met de helft tijdens de nachtperiode. Het configureert zowel het aantal beschikbare replica's als de gewenste capaciteit van het Amazon-cluster. Door deze planner te gebruiken, wordt het aantal knooppunten 's nachts automatisch verminderd en 's ochtends vergroot, waardoor de kosten voor het gebruik van knooppunten van een cloudservice zoals Amazon worden bespaard. Deze functie is niet ingebouwd in Kubernetes, maar als je Scalrd gebruikt, kun je dit platform opschalen zoals jij dat wilt.
Ik wil erop wijzen dat veel mensen tegen mij zeggen: “Dat is allemaal goed en wel, maar hoe zit het met mijn database, die meestal statisch is?” Hoe kun je zoiets draaien in een dynamische omgeving als Kubernetes? Naar mijn mening moet je dit niet doen, je moet niet proberen een datawarehouse in Kubernetes te draaien. Dit is technisch mogelijk en er zijn tutorials op internet over dit onderwerp, maar het zal je leven ernstig compliceren.
Ja, er is een concept van persistente winkels in Kubernetes, en je kunt proberen datastores zoals Mongo of MySQL te gebruiken, maar dit is een behoorlijk arbeidsintensieve taak. Dit komt door het feit dat datawarehouses de interactie met een dynamische omgeving niet volledig ondersteunen. De meeste databases vereisen een aanzienlijke configuratie, inclusief handmatige configuratie van het cluster, houden niet van automatisch schalen en andere soortgelijke zaken.
Daarom moet u uw leven niet ingewikkelder maken door te proberen een datawarehouse in Kubernetes te runnen. Organiseer hun werk op de traditionele manier met behulp van bekende diensten en geef Kubernetes eenvoudigweg de mogelijkheid om deze te gebruiken.
Ter afsluiting van het onderwerp wil ik u graag kennis laten maken met het Cloud RTI-platform op basis van Kubernetes, waar mijn team aan werkt. Het biedt gecentraliseerde logboekregistratie, applicatie- en clustermonitoring en vele andere handige functies die van pas zullen komen. Het maakt gebruik van verschillende open-sourcetools zoals Grafana om monitoring weer te geven.
Er was een vraag over waarom de ha-proxy load balancer met Kubernetes zou worden gebruikt. Goede vraag, want er zijn momenteel 2 niveaus van taakverdeling. Kubernetes-services bevinden zich nog steeds op virtuele IP-adressen. Je kunt ze niet gebruiken voor poorten op externe hostmachines, want als Amazon zijn cloudhost overbelast, zal het adres veranderen. Daarom plaatsen we ha-proxy vóór de services - om een meer statische structuur te creëren zodat verkeer naadloos met Kubernetes kan communiceren.
Een andere goede vraag is: hoe kun je omgaan met wijzigingen in het databaseschema als je een blauw/groene implementatie uitvoert? Feit is dat, ongeacht het gebruik van Kubernetes, het veranderen van het databaseschema een moeilijke taak is. U moet ervoor zorgen dat het oude en nieuwe schema compatibel zijn, waarna u de database kunt bijwerken en vervolgens de applicaties zelf kunt bijwerken. U kunt de database hot-swappen en vervolgens de applicaties bijwerken. Ik ken mensen die een compleet nieuw databasecluster hebben opgestart met een nieuw schema. Dit is een optie als je een schemaloze database zoals Mongo hebt, maar het is sowieso geen gemakkelijke taak. Indien u verder geen vragen heeft, bedankt voor uw aandacht!
Sommige advertenties 🙂
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, , een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over
Bron: www.habr.com