Kubernetes är ett utmärkt verktyg för att köra Docker-containrar i en klustrad produktionsmiljö. Det finns dock problem som Kubernetes inte kan lösa. För frekventa produktionsinstallationer behöver vi en helt automatiserad Blue/Green-distribution för att undvika driftstopp i processen, som också behöver hantera externa HTTP-förfrågningar och utföra SSL-avlastningar. Detta kräver integration med en lastbalanserare som ha-proxy. En annan utmaning är halvautomatisk skalning av själva Kubernetes-klustret när man kör i molnmiljö, till exempel att delvis skala ner klustret på natten.
Även om Kubernetes inte har dessa funktioner direkt, tillhandahåller det ett API som du kan använda för att lösa liknande problem. Verktyg för automatiserad Blue/Green-distribution och skalning av ett Kubernetes-kluster utvecklades som en del av Cloud RTI-projektet, som skapades baserat på öppen källkod.
Den här artikeln, en videotranskription, visar hur du ställer in Kubernetes tillsammans med andra komponenter med öppen källkod för att skapa en produktionsklar miljö som accepterar kod från en git-commit utan driftstopp i produktionen.
Så när du väl har tillgång till dina applikationer från omvärlden kan du börja ställa in automatisering fullt ut, det vill säga ta den till det stadiet där du kan utföra en git-commit och se till att denna git-commit hamnar i produktion. När vi implementerar dessa steg, när vi implementerar implementeringen, vill vi naturligtvis inte stöta på driftstopp. Så, all automatisering i Kubernetes börjar med API:et.
Kubernetes är inte ett verktyg som kan användas produktivt direkt. Naturligtvis kan du göra det, använda kubectl och så vidare, men ändå är API:et det mest intressanta och användbara med den här plattformen. Genom att använda API:et som en uppsättning funktioner kan du komma åt nästan allt du vill göra i Kubernetes. kubectl själv använder också REST API.
Detta är REST, så du kan använda vilket språk eller verktyg som helst för att arbeta med detta API, men ditt liv kommer att göras mycket enklare av anpassade bibliotek. Mitt team skrev två sådana bibliotek: ett för Java/OSGi och ett för Go. Den andra används inte ofta, men du har i alla fall dessa användbara saker till ditt förfogande. De är ett delvis licensierat projekt med öppen källkod. Det finns många sådana bibliotek för olika språk, så du kan välja de som passar dig bäst.
Så innan du börjar automatisera din distribution måste du se till att processen inte kommer att vara föremål för några driftstopp. Till exempel genomför vårt team produktionsinstallationer mitt på dagen när människor använder applikationerna som mest, så det är viktigt att undvika förseningar i denna process. För att undvika driftstopp används två metoder: blå/grön implementering eller rullande uppdatering. I det senare fallet, om du har 2 repliker av programmet igång, uppdateras de sekventiellt efter varandra. Denna metod fungerar utmärkt, men den är inte lämplig om du har olika versioner av programmet som körs samtidigt under distributionsprocessen. I det här fallet kan du uppdatera användargränssnittet medan backend kör den gamla versionen, och applikationen kommer att sluta fungera. Ur programmeringssynpunkt är det därför ganska svårt att arbeta under sådana förhållanden.
Detta är en av anledningarna till att vi föredrar att använda blå/grön distribution för att automatisera distributionen av våra applikationer. Med den här metoden måste du se till att endast en version av programmet är aktiv åt gången.
Den blå/gröna distributionsmekanismen ser ut så här. Vi tar emot trafik för våra applikationer genom ha-proxy, som vidarebefordrar den till körande repliker av applikationen av samma version.
När en ny distribution görs använder vi Deployer, som får de nya komponenterna och distribuerar den nya versionen. Att distribuera en ny version av en applikation innebär att en ny uppsättning repliker "höjs", varefter dessa repliker av den nya versionen lanseras i en separat, ny pod. Ha-proxy vet dock ingenting om dem och dirigerar ingen arbetsbörda till dem ännu.
Därför är det först och främst nödvändigt att utföra en prestandakontroll av nya versioner av hälsokontroll för att säkerställa att replikerna är redo att betjäna lasten.
Alla distributionskomponenter måste stödja någon form av hälsokontroll. Detta kan vara en mycket enkel HTTP-anropskontroll, när du får en kod med status 200, eller en mer djupgående kontroll, där du kontrollerar anslutningen av replikerna med databasen och andra tjänster, stabiliteten i de dynamiska miljöanslutningarna , och om allt startar och fungerar korrekt. Denna process kan vara ganska komplex.
Efter att systemet har verifierat att alla uppdaterade repliker fungerar, kommer Deployer att uppdatera konfigurationen och skicka rätt konfd, vilket kommer att konfigurera om ha-proxy.
Först efter detta kommer trafik att dirigeras till podden med repliker av den nya versionen, och den gamla podden försvinner.
Denna mekanism är inte en funktion hos Kubernetes. Konceptet med blå/grön utbyggnad har funnits ganska länge och det har alltid använt en lastbalanserare. Först dirigerar du all trafik till den gamla versionen av applikationen och efter uppdateringen överför du den helt till den nya versionen. Denna princip används inte bara i Kubernetes.
Nu kommer jag att introducera dig för en ny implementeringskomponent - Deployer, som utför hälsokontroller, konfigurerar om proxyservrar och så vidare. Detta är ett koncept som inte gäller omvärlden och som finns inne i Kubernetes. Jag ska visa dig hur du kan skapa ditt eget Deployer-koncept med hjälp av verktyg med öppen källkod.
Så det första Deployer gör är att skapa en RC-replikeringskontroller med hjälp av Kubernetes API. Detta API skapar poddar och tjänster för vidare distribution, det vill säga det skapar ett helt nytt kluster för våra applikationer. Så snart RC är övertygad om att replikerna har startat kommer den att utföra en hälsokontroll av deras funktionalitet. För att göra detta använder Deployer kommandot GET /health. Den kör lämpliga skanningskomponenter och kontrollerar alla element som stöder driften av klustret.
Efter att alla poddar har rapporterat sin hälsa skapar Deployer ett nytt konfigurationselement - etcd distributed storage, som används internt av Kubernetes, inklusive lagring av lastbalanserarens konfiguration. Vi skriver data till etcd, och ett litet verktyg som heter confd övervakar etcd för ny data.
Om den upptäcker några ändringar i den ursprungliga konfigurationen, genererar den en ny inställningsfil och överför den till ha-proxy. I det här fallet startas ha-proxy om utan att förlora några anslutningar och adresserar belastningen till nya tjänster som gör att den nya versionen av våra applikationer kan fungera.
Som du kan se, trots överflöd av komponenter, finns det inget komplicerat här. Du behöver bara ägna mer uppmärksamhet åt API och etcd. Jag vill berätta om den öppen källkodsdeployer som vi själva använder - Amdatu Kubernetes Deployer.
Det är ett verktyg för orkestrering av Kubernetes-distributioner och har följande funktioner:
- Blå/grön utbyggnad;
- ställa in en extern lastbalanserare;
- hantering av distributionsbeskrivningar;
- hantera den faktiska driftsättningen;
- kontrollera funktionaliteten av hälsokontroller under driftsättning;
- implementering av miljövariabler i pods.
Denna Deployer är byggd ovanpå Kubernetes API och tillhandahåller ett REST API för hantering av handtag och distributioner, samt ett Websocket API för strömmande loggar under distributionsprocessen.
Den lägger in belastningsutjämnarens konfigurationsdata i etcd, så du behöver inte använda ha-proxy med out-of-the-box-stöd, utan enkelt använda din egen konfigurationsfil för lastbalanserare. Amdatu Deployer är skriven i Go, som Kubernetes själv, och är licensierad av Apache.
Innan jag började använda den här versionen av deployern använde jag följande distributionsbeskrivning, som anger parametrarna jag behöver.
En av de viktiga parametrarna i denna kod är att aktivera flaggan "useHealthCheck". Vi måste specificera att en förnuftskontroll måste utföras under driftsättningsprocessen. Den här inställningen kan inaktiveras när distributionen använder tredjepartsbehållare som inte behöver verifieras. Den här beskrivningen anger också antalet repliker och gränssnitts-URL som ha-proxy behöver. I slutet finns podspecifikationsflaggan "podspec", som anropar Kubernetes för information om portkonfiguration, bild osv. Detta är en ganska enkel JSON-beskrivning.
Ett annat verktyg som ingår i Amdatu-projektet med öppen källkod är Deploymentctl. Den har ett användargränssnitt för att konfigurera distributioner, lagrar distributionshistorik och innehåller webhooks för återuppringningar från tredjepartsanvändare och utvecklare. Du får inte använda användargränssnittet eftersom Amdatu Deployer i sig är ett REST API, men det här gränssnittet kan göra implementeringen mycket enklare för dig utan att involvera något API. Deploymentctl är skrivet i OSGi/Vertx med Angular 2.
Jag kommer nu att demonstrera ovanstående på skärmen med hjälp av en förinspelad inspelning så att du inte behöver vänta. Vi kommer att distribuera en enkel Go-applikation. Oroa dig inte om du inte har provat Go tidigare, det är en väldigt enkel applikation så du borde kunna lista ut det.
Här skapar vi en HTTP-server som bara svarar på /health, så denna applikation testar bara hälsokontrollen och inget annat. Om kontrollen godkänns används JSON-strukturen som visas nedan. Den innehåller versionen av applikationen som kommer att distribueras av deployern, meddelandet som du ser överst i filen och den booleska datatypen - oavsett om vår applikation fungerar eller inte.
Jag fuskade lite med den sista raden, eftersom jag placerade ett fast booleskt värde överst i filen, vilket i framtiden kommer att hjälpa mig att distribuera även en "ohälsosam" applikation. Vi kommer att ta itu med detta senare.
Så låt oss börja. Först kontrollerar vi om det finns några pågående pods med kommandot ~ kubectl get pods och baserat på frånvaron av ett svar från frontend-URL:n ser vi till att inga distributioner görs för närvarande.
Nästa på skärmen ser du Deploymentctl-gränssnittet som jag nämnde, där distributionsparametrar är inställda: namnområde, applikationsnamn, distributionsversion, antal repliker, front-end-URL, containernamn, bild, resursgränser, portnummer för hälsokontroll, osv. Resursbegränsningar är mycket viktiga, eftersom de tillåter dig att använda maximalt möjliga mängd hårdvara. Här kan du också se distributionsloggen.
Om du nu upprepar kommandot ~ kubectl get pods kan du se att systemet "fryser" i 20 sekunder, under vilket ha-proxy konfigureras om. Efter detta startar podden och vår replika kan ses i distributionsloggen.
Jag klippte bort den 20 sekunder långa väntan från videon, och nu kan du se på skärmen att den första versionen av applikationen har distribuerats. Allt detta gjordes med endast UI.
Låt oss nu prova den andra versionen. För att göra detta ändrar jag programmets meddelande från "Hej, Kubernetes!" på "Hej, Deployer!", skapar systemet den här bilden och placerar den i Docker-registret, varefter vi helt enkelt klickar på knappen "Deploy" igen i Deploymentctl-fönstret. I det här fallet startas distributionsloggen automatiskt på samma sätt som när den första versionen av programmet distribuerades.
Kommandot ~ kubectl get pods visar att det för närvarande finns 2 versioner av applikationen som körs, men frontend visar att vi fortfarande kör version 1.
Lastbalanseraren väntar på att hälsokontrollen ska slutföras innan trafiken omdirigeras till den nya versionen. Efter 20 sekunder byter vi till curl och ser att vi nu har version 2 av applikationen utplacerad, och den första har tagits bort.
Detta var utplaceringen av en "hälsosam" applikation. Låt oss se vad som händer om jag för en ny version av applikationen ändrar parametern Healthy från sant till falskt, det vill säga jag försöker distribuera en ohälsosam applikation som har misslyckats med hälsokontrollen. Detta kan hända om vissa konfigurationsfel gjordes i applikationen under utvecklingsstadiet och den skickades i produktion i detta formulär.
Som du kan se går installationen igenom alla stegen ovan och ~kubectl get pods visar att båda podarna körs. Men till skillnad från den tidigare driftsättningen visar loggen timeout-statusen. Det vill säga, på grund av att hälsokontrollen misslyckades, kan den nya versionen av applikationen inte distribueras. Som ett resultat ser du att systemet har återgått till att använda den gamla versionen av programmet, och den nya versionen har helt enkelt avinstallerats.
Det som är bra med detta är att även om du har ett stort antal samtidiga förfrågningar som kommer in i applikationen, kommer de inte ens att märka driftstoppet när de implementerar distributionsproceduren. Om du testar den här applikationen med Gatling-ramverket, som skickar så många förfrågningar som möjligt, kommer ingen av dessa förfrågningar att tas bort. Detta innebär att våra användare inte ens kommer att märka versionsuppdateringar i realtid. Om det misslyckas fortsätter arbetet med den gamla versionen; om det lyckas kommer användarna att byta till den nya versionen.
Det finns bara en sak som kan misslyckas - om hälsokontrollen lyckas, men applikationen misslyckas så snart arbetsbelastningen appliceras på den, det vill säga kollapsen kommer att inträffa först efter att implementeringen är klar. I det här fallet måste du manuellt rulla tillbaka till den gamla versionen. Så vi tittade på hur man använder Kubernetes med de öppen källkodsverktyg som är designade för det. Distributionsprocessen blir mycket enklare om du bygger in dessa verktyg i dina Build/Deploy pipelines. Samtidigt, för att starta implementeringen, kan du använda antingen användargränssnittet eller helt automatisera denna process genom att till exempel använda commit to master.
Vår Build Server kommer att skapa en Docker-bild, skjuta in den i Docker Hub eller vilket register du än använder. Docker Hub stöder webhook, så vi kan utlösa fjärrdistribution via Deployer på det sätt som visas ovan. På så sätt kan du helt automatisera distributionen av din applikation till potentiell produktion.
Låt oss gå vidare till nästa ämne - skalning av Kubernetes-klustret. Observera att kommandot kubectl är ett skalningskommando. Med mer hjälp kan vi enkelt öka antalet repliker i vårt befintliga kluster. Men i praktiken vill vi oftast öka antalet noder snarare än pods.
Samtidigt kan du under arbetstid behöva öka, och på natten, för att minska kostnaderna för Amazon-tjänster, kan du behöva minska antalet körande applikationsinstanser. Det betyder inte att det räcker med att skala bara antalet pods, för även om en av noderna är ledig måste du fortfarande betala Amazon för det. Det vill säga, tillsammans med skalning av kapslarna måste du skala antalet maskiner som används.
Detta kan vara utmanande eftersom oavsett om vi använder Amazon eller någon annan molntjänst vet Kubernetes ingenting om antalet maskiner som används. Den saknar ett verktyg som låter dig skala systemet på nodnivå.
Så vi kommer att behöva ta hand om både noder och poddar. Vi kan enkelt skala lanseringen av nya noder med hjälp av AWS API och skalningsgruppmaskiner för att konfigurera antalet Kubernetes-arbetarnoder. Du kan också använda cloud-init eller ett liknande skript för att registrera noder i Kubernetes-klustret.
Den nya maskinen startar i skalningsgruppen, initierar sig själv som en nod, registrerar sig i masterns register och börjar arbeta. Efter detta kan du öka antalet repliker för användning på de resulterande noderna. Att skala ner kräver mer ansträngning, eftersom du måste se till att ett sådant steg inte leder till förstörelse av redan körda applikationer efter att du har stängt av "onödiga" maskiner. För att förhindra ett sådant scenario måste du ställa in noderna till statusen "oschemalagd". Detta innebär att standardschemaläggaren kommer att ignorera dessa noder vid schemaläggning av DaemonSet-poddar. Schemaläggaren kommer inte att ta bort något från dessa servrar, men kommer inte heller att starta några nya behållare där. Nästa steg är att ta bort dräneringsnoden, det vill säga att överföra löpande pods från den till en annan maskin, eller andra noder som har tillräcklig kapacitet för detta. När du har försäkrat dig om att det inte längre finns några behållare på dessa noder kan du ta bort dem från Kubernetes. Efter detta kommer de helt enkelt att upphöra att existera för Kubernetes. Därefter måste du använda AWS API för att inaktivera onödiga noder eller maskiner.
Du kan använda Amdatu Scalerd, ett annat skalningsverktyg med öppen källkod som liknar AWS API. Det tillhandahåller en CLI för att lägga till eller ta bort noder i ett kluster. Dess intressanta funktion är möjligheten att konfigurera schemaläggaren med hjälp av följande json-fil.
Den visade koden reducerar klusterkapaciteten med hälften under nattperioden. Den konfigurerar både antalet tillgängliga repliker och den önskade kapaciteten för Amazon-klustret. Att använda denna schemaläggare kommer automatiskt att minska antalet noder på natten och öka dem på morgonen, vilket sparar kostnaden för att använda noder från en molntjänst som Amazon. Den här funktionen är inte inbyggd i Kubernetes, men genom att använda Scalerd kan du skala den här plattformen hur du vill.
Jag skulle vilja påpeka att många säger till mig: "Det är bra, men hur är det med min databas, som vanligtvis är statisk?" Hur kan du köra något sådant i en dynamisk miljö som Kubernetes? Enligt min åsikt ska man inte göra detta, man ska inte försöka driva ett datalager i Kubernetes. Detta är tekniskt möjligt, och det finns tutorials på Internet om detta ämne, men det kommer allvarligt att komplicera ditt liv.
Ja, det finns ett koncept med beständiga butiker i Kubernetes, och du kan prova att köra databutiker som Mongo eller MySQL, men det här är en ganska arbetskrävande uppgift. Detta beror på att datalager inte fullt ut stöder interaktion med en dynamisk miljö. De flesta databaser kräver betydande konfiguration, inklusive manuell konfiguration av klustret, gillar inte autoskalning och andra liknande saker.
Därför bör du inte komplicera ditt liv genom att försöka driva ett datalager i Kubernetes. Organisera sitt arbete på traditionellt sätt med hjälp av välbekanta tjänster och ge Kubernetes helt enkelt möjligheten att använda dem.
För att avsluta ämnet skulle jag vilja presentera dig för Cloud RTI-plattformen baserad på Kubernetes, som mitt team arbetar med. Den tillhandahåller centraliserad loggning, applikations- och klusterövervakning och många andra användbara funktioner som kommer till användning. Den använder olika verktyg med öppen källkod som Grafana för att visa övervakning.
Det fanns en fråga om varför man använder ha-proxy-lastbalanseraren med Kubernetes. Bra fråga eftersom det för närvarande finns 2 nivåer av lastbalansering. Kubernetes tjänster finns fortfarande på virtuella IP-adresser. Du kan inte använda dem för portar på externa värdmaskiner eftersom om Amazon överbelastas sin molnvärd kommer adressen att ändras. Det är därför vi placerar ha-proxy framför tjänsterna - för att skapa en mer statisk struktur för trafik att kommunicera sömlöst med Kubernetes.
En annan bra fråga är hur kan du ta hand om databasschemaändringar när du gör blå/grön implementering? Faktum är att oavsett användningen av Kubernetes är det en svår uppgift att ändra databasschemat. Du måste se till att det gamla och det nya schemat är kompatibla, varefter du kan uppdatera databasen och sedan uppdatera själva applikationerna. Du kan hot swap databasen och sedan uppdatera applikationerna. Jag vet om folk som har startat upp ett helt nytt databaskluster med ett nytt schema, detta är ett alternativ om du har en systemlös databas som Mongo, men det är inte en lätt uppgift ändå. Om du inte har några fler frågor, tack för din uppmärksamhet!
Några annonser 🙂
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com