{"id":83787,"date":"2020-06-03T07:42:26","date_gmt":"2020-06-03T05:42:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2"},"modified":"2020-06-03T07:42:26","modified_gmt":"2020-06-03T05:42:26","slug":"devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","title":{"rendered":"DEVOXX UK. Kubernetes i produktion: Blue\/Green deployment, autoskalning och automatisering av distribution. Del 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kubernetes \u00e4r ett utm\u00e4rkt verktyg f\u00f6r att k\u00f6ra Docker-containrar i en klustrad produktionsmilj\u00f6. Men det finns uppgifter som Kubernetes inte kan l\u00f6sa. Vid frekvent distribution i produktionsmilj\u00f6 beh\u00f6ver vi en helt automatiserad Blue\/Green-distribution f\u00f6r att undvika driftstopp i denna process, d\u00e4r det ocks\u00e5 \u00e4r n\u00f6dv\u00e4ndigt att hantera externa HTTP-f\u00f6rfr\u00e5gningar och genomf\u00f6ra SSL-avlastning. Detta kr\u00e4ver integration med en lastbalanserare, s\u00e5som ha-proxy. En annan uppgift \u00e4r semi-automatiserad skalning av sj\u00e4lva Kubernetes-klustret n\u00e4r man arbetar i molnmilj\u00f6, till exempel delvis nedskalning av klustret under nattetid.<\/p>\n

\u00c4ven om Kubernetes inte har dessa funktioner direkt \"ur l\u00e5dan\", erbjuder det ett API som kan anv\u00e4ndas f\u00f6r att l\u00f6sa s\u00e5dana uppgifter. Verktyg f\u00f6r automatiserad Blue\/Green-distribution och skalning av Kubernetes-klustret har utvecklats inom projektet Cloud RTI, som skapats baserat p\u00e5 \u00f6ppen programvara.<\/p>\n

I denna artikel, en avkodning av videon, diskuteras hur man konfigurerar Kubernetes tillsammans med andra komponenter med \u00f6ppen k\u00e4llkod f\u00f6r att skapa en produktionsklar milj\u00f6 som oavbrutet tar emot kod fr\u00e5n git commit.<\/p>\n

\"DEVOXX<\/a><\/noindex><\/p>\n

DEVOXX UK. Kubernetes i produktion: Blue\/Green-distribution, automatisk skalning och automatisering av distribution. Del 1<\/a><\/noindex><\/p>\n

S\u00e5 snart du har f\u00e5tt tillg\u00e5ng till dina applikationer fr\u00e5n den externa v\u00e4rlden, kan du p\u00e5b\u00f6rja den fullst\u00e4ndiga automatiseringsinst\u00e4llningen, det vill s\u00e4ga att ta den till en punkt d\u00e4r du kan g\u00f6ra en git commit och vara s\u00e4ker p\u00e5 att denna git commit n\u00e5r produktionen. Naturligtvis vill vi inte uppleva driftstopp vid genomf\u00f6randet av dessa steg under distributionen. S\u00e5 varje automatisering i Kubernetes b\u00f6rjar med API:et. <\/p>\n

\"DEVOXX
\n
\nKubernetes \u00e4r inte ett verktyg som kan anv\u00e4ndas produktivt \"direkt ur l\u00e5dan\". Sj\u00e4lvklart kan du g\u00f6ra s\u00e5, anv\u00e4nda kubectl och s\u00e5 vidare, men API:et \u00e4r \u00e4nd\u00e5 det mest intressanta och anv\u00e4ndbara med denna plattform. Genom att anv\u00e4nda API:et som en upps\u00e4ttning funktioner kan du f\u00e5 tillg\u00e5ng till n\u00e4stan allt du vill g\u00f6ra i Kubernetes. Kubectl sj\u00e4lv anv\u00e4nder ocks\u00e5 REST API. <\/p>\n

Det h\u00e4r \u00e4r REST, s\u00e5 du kan anv\u00e4nda vilket spr\u00e5k och verktyg som helst f\u00f6r att arbeta med det h\u00e4r API:et, men anv\u00e4ndarbiblioteken kommer att g\u00f6ra ditt liv betydligt enklare. Mitt team har skrivit tv\u00e5 s\u00e5dana bibliotek: ett f\u00f6r Java \/ OSGi och ett f\u00f6r Go. Det andra anv\u00e4nds inte s\u00e5 ofta, men ni har dessa anv\u00e4ndbara verktyg tillg\u00e4ngliga. De utg\u00f6r ett delvis licensierat open-source-projekt. Det finns m\u00e5nga s\u00e5dana bibliotek f\u00f6r olika spr\u00e5k, s\u00e5 du kan v\u00e4lja de som passar b\u00e4st. <\/p>\n

\"DEVOXX
\n
\nS\u00e5 innan du b\u00f6rjar automatisera distributionen, \u00e4r det viktigt att s\u00e4kerst\u00e4lla att denna process inte drabbas av n\u00e5gra driftstopp. Till exempel genomf\u00f6r v\u00e5rt team produktiondistribution mitt p\u00e5 dagen, n\u00e4r folk anv\u00e4nder applikationerna som mest, s\u00e5 det \u00e4r mycket viktigt att undvika f\u00f6rseningar i denna process. F\u00f6r att undvika driftstopp anv\u00e4nds tv\u00e5 metoder: blue\/green distribution eller glidande uppdatering (rolling update). I det senare fallet, om du har fem replikas av applikationen, uppdateras de sekventiellt en efter en. Denna metod fungerar utm\u00e4rkt, men den \u00e4r inte l\u00e4mplig om du har olika versioner av applikationen som k\u00f6rs samtidigt under distributionsprocessen. I s\u00e5 fall kan du uppdatera anv\u00e4ndargr\u00e4nssnittet medan backend fortfarande arbetar med den gamla versionen, vilket skulle inneb\u00e4ra att applikationen skulle upph\u00f6ra att fungera. D\u00e4rf\u00f6r \u00e4r det ganska komplicerat ur en programmeringssynvinkel att arbeta i s\u00e5dana f\u00f6rh\u00e5llanden. <\/p>\n

Detta \u00e4r en av anledningarna till att vi f\u00f6redrar att anv\u00e4nda blue\/green deployment f\u00f6r att automatisera distributionen av v\u00e5ra applikationer. Med denna metod m\u00e5ste du s\u00e4kerst\u00e4lla att endast en version av applikationen \u00e4r aktiv vid en given tidpunkt. <\/p>\n

Blue\/green deployment-mekanismen fungerar enligt f\u00f6ljande. Vi f\u00e5r trafik till v\u00e5ra applikationer via ha-proxy, som dirigerar det till de k\u00f6rande replikas av applikationen med samma version. <\/p>\n

N\u00e4r en ny distribution g\u00f6rs anv\u00e4nder vi Deployer, som tillhandah\u00e5lls nya komponenter, och den genomf\u00f6r distributionen av den nya versionen. Distributionen av den nya versionen av applikationen inneb\u00e4r att en ny upps\u00e4ttning repliker \"startas\", och dessa repliker av den nya versionen k\u00f6rs i en separat, ny pod. Men ha-proxy har ingen k\u00e4nnedom om dem och dirigerar fortfarande ingen arbetsbelastning till dem.<\/p>\n

D\u00e4rf\u00f6r \u00e4r det i f\u00f6rsta hand n\u00f6dv\u00e4ndigt att utf\u00f6ra en h\u00e4lsokontroll av de nya versionerna f\u00f6r att s\u00e4kerst\u00e4lla att replikerna \u00e4r redo att hantera belastningen.<\/p>\n

\"DEVOXX
\n
\nAlla distributionskomponenter m\u00e5ste st\u00f6dja n\u00e5gon form av h\u00e4lsokontroll. Detta kan vara en mycket enkel kontroll med en HTTP-anrop, d\u00e4r du f\u00e5r en statuskod 200, eller en mer djupg\u00e5ende kontroll d\u00e4r du kontrollerar replikerna med databasen och andra tj\u00e4nster, stabiliteten i f\u00f6rbindelserna i den dynamiska milj\u00f6n, och att allt startar och fungerar korrekt. Denna process kan vara ganska komplex. <\/p>\n

\"DEVOXX
\n
\nN\u00e4r systemet har verifierat att alla uppdaterade repliker fungerar, kommer Deployer att uppdatera konfigurationen och \u00f6verf\u00f6ra r\u00e4tt confd, som omkonfigurerar ha-proxy. <\/p>\n

\"DEVOXX
\n
\nF\u00f6rst efter detta kommer trafiken att dirigeras till podden med repliker av den nya versionen, medan den gamla podden f\u00f6rsvinner. <\/p>\n

\"DEVOXX
\n
\nDenna mekanism \u00e4r inte unik f\u00f6r Kubernetes. Konceptet med Blue\/green deployment har funnits l\u00e4nge, och det har alltid anv\u00e4nt en lastbalanserare. F\u00f6rst dirigerar du all trafik till den gamla versionen av applikationen, och efter uppdateringen v\u00e4xlar du helt \u00f6ver till den nya versionen. Detta princip g\u00e4ller inte bara i Kubernetes.<\/p>\n

Nu ska jag introducera er till den nya distributionskomponenten \u2013 Deployer, som utf\u00f6r h\u00e4lsokontroller, omkonfigurerar proxy och s\u00e5 vidare. Detta \u00e4r ett koncept som inte r\u00f6r det externa v\u00e4rlden och existerar inom Kubernetes. Jag kommer att visa hur man kan skapa sitt egna Deployer-koncept med hj\u00e4lp av open source-verktyg. <\/p>\n

S\u00e5, det f\u00f6rsta Deployer g\u00f6r \u00e4r att skapa en replikationskontroller RC med hj\u00e4lp av Kubernetes API. Detta API skapar pods och tj\u00e4nster f\u00f6r vidare distribution, det vill s\u00e4ga det skapar ett helt nytt kluster f\u00f6r v\u00e5ra applikationer. S\u00e5 snart RC har bekr\u00e4ftat att replikerna har startat, g\u00f6r den en statuskontroll av deras funktion, Health check. F\u00f6r detta anv\u00e4nds kommandot GET \/health i Deployer. Det aktiverar motsvarande kontrollkomponenter och kontrollerar alla element som g\u00f6r att klustret fungerar. <\/p>\n

\"DEVOXX
\n
\nN\u00e4r alla pods har rapporterat sitt \"h\u00e4lsotillst\u00e5nd\", skapar Deployer en ny konfigurationspost \u2013 ett distribuerat lagringssystem etcd, som anv\u00e4nds internt inom Kubernetes, inklusive f\u00f6r att lagra konfigurationen f\u00f6r lastbalanseraren. Vi skriver data till etcd, och ett litet verktyg, confd, \u00f6vervakar etcd f\u00f6r nya data. <\/p>\n

Om det uppt\u00e4cker n\u00e5gra \u00e4ndringar i den ursprungliga konfigurationen, genererar det en ny konfigurationsfil och \u00f6verf\u00f6r den till ha-proxy. I detta fall startar ha-proxy om utan att f\u00f6rlora n\u00e5gra anslutningar och dirigerar belastningen till de nya tj\u00e4nster som st\u00f6der den nya versionen av v\u00e5ra applikationer. <\/p>\n

\"DEVOXX
\n
\nSom ni ser, trots m\u00e4ngden komponenter, finns det inget sv\u00e5rt h\u00e4r. Du beh\u00f6ver bara \u00e4gna mer uppm\u00e4rksamhet \u00e5t API och etcd. Jag vill ber\u00e4tta om en open-source-deployer som vi sj\u00e4lva anv\u00e4nder \u2013 Amdatu Kubernetes Deployer.<\/p>\n

\"DEVOXX
\n
\nDetta \u00e4r ett verktyg f\u00f6r orkestrering av Kubernetes-distributioner, med f\u00f6ljande funktioner: <\/p>\n