{"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\/da\/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, autoskalering og automatisering af implementering. Del 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kubernetes er et fremragende v\u00e6rkt\u00f8j til at k\u00f8re Docker-containere i en klyngemilj\u00f8 i produktion. Men der er opgaver, som Kubernetes ikke kan l\u00f8se. Ved hyppig implementering i produktionsmilj\u00f8et har vi brug for en fuldt automatiseret Blue\/Green deployment for at undg\u00e5 nedetid i denne proces, hvor det ogs\u00e5 er n\u00f8dvendigt at h\u00e5ndtere eksterne HTTP-anmodninger og udf\u00f8re SSL-udtr\u00e6kning. Dette kr\u00e6ver integration med en lastbalancer, s\u00e5som ha-proxy. En anden udfordring er semi-automatiseret skalering af selve Kubernetes-klyngen, n\u00e5r man arbejder i et cloud-milj\u00f8, for eksempel delvis nedskalering af klyngen om natten.<\/p>\n

Selvom Kubernetes ikke har disse funktioner lige \u00abud af boksen\u00bb, giver det API'er, som kan udnyttes til at l\u00f8se s\u00e5danne opgaver. V\u00e6rkt\u00f8jer til automatiseret Blue\/Green deployment og skalering af Kubernetes-klyngen er blevet udviklet under Cloud RTI-projektet, som er baseret p\u00e5 open-source.<\/p>\n

I denne artikel, som er en transskription af en video, beskrives, hvordan man konfigurerer Kubernetes sammen med andre open-source komponenter for at opn\u00e5 et produktionsklart milj\u00f8, der uden nedetid i produktionen modtager koden fra git commit-\u00e6ndringer.<\/p>\n

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

DEVOXX UK. Kubernetes i produktion: Blue\/Green deployment, autoskalering og automatisering af implementering. Del 1<\/a><\/noindex><\/p>\n

S\u00e5 snart du har f\u00e5et adgang til dine applikationer fra den eksterne verden, kan du g\u00e5 videre med at fuldautomatisere ops\u00e6tningen, det vil sige n\u00e5 til det punkt, hvor du kan udf\u00f8re en git commit og sikre, at denne git commit ender i produktion. Det er indlysende, at n\u00e5r disse skridt implementeres, og implementeringen finder sted, \u00f8nsker vi ikke at opleve nedetid. S\u00e5 enhver automatisering i Kubernetes starter med API'et. <\/p>\n

\"DEVOXX
\n
\nKubernetes er ikke det v\u00e6rkt\u00f8j, der kan bruges produktivt \u00ablige ud af boksen\u00bb. Selvf\u00f8lgelig kan du g\u00f8re det s\u00e5dan, bruge kubectl osv., men API'et er virkelig den mest interessante og nyttige del af denne platform. Ved at bruge API'et som et s\u00e6t funktioner kan du f\u00e5 adgang til n\u00e6sten alt, hvad du \u00f8nsker at g\u00f8re i Kubernetes. Selve kubectl bruger ogs\u00e5 REST API. <\/p>\n

Dette er REST, s\u00e5 du kan bruge ethvert sprog og v\u00e6rkt\u00f8j til at arbejde med dette API, men brugerbibliotekerne vil g\u00f8re dit liv meget lettere. Mit team har skrevet to s\u00e5danne biblioteker: et til Java \/ OSGi og et til Go. Det andet bruges ikke s\u00e5 ofte, men uanset hvad har du disse nyttige v\u00e6rkt\u00f8jer til r\u00e5dighed. De udg\u00f8r delvist et licenseret open-source projekt. Der findes mange s\u00e5danne biblioteker til forskellige sprog, s\u00e5 du kan v\u00e6lge dem, der passer bedst til dine behov. <\/p>\n

\"DEVOXX
\n
\nS\u00e5 f\u00f8r du g\u00e5r i gang med at automatisere implementeringen, skal du s\u00f8rge for, at denne proces ikke vil v\u00e6re udsat for nedetid. For eksempel udf\u00f8rer vores team produktionsimplementering midt p\u00e5 dagen, n\u00e5r folk bruger applikationerne mest, s\u00e5 det er meget vigtigt at undg\u00e5 forsinkelser i denne proces. For at undg\u00e5 nedetid anvendes der to metoder: blue\/green-implementering eller rolling update. I det sidstn\u00e6vnte tilf\u00e6lde, hvis du har 5 replikaer af applikationen, bliver de opdateret \u00e9n efter \u00e9n. Denne metode fungerer fremragende, men den egner sig ikke, hvis der k\u00f8rer forskellige versioner af applikationen samtidigt under implementeringen. I s\u00e5 fald kan du opdatere brugergr\u00e6nsefladen, mens backenden k\u00f8rer den gamle version, og applikationen vil stoppe med at fungere. Derfor er det ret udfordrende at arbejde under s\u00e5danne forhold. <\/p>\n

Dette er en af grundene til, at vi foretr\u00e6kker at bruge blue\/green-implementering til automatisk at implementere vores applikationer. Ved denne metode skal du sikre dig, at der kun er \u00e9n aktiv version af applikationen p\u00e5 et givent tidspunkt. <\/p>\n

Mechanismen for blue\/green-implementering ser s\u00e5ledes ud. Vi modtager trafik til vores applikationer gennem ha-proxy, som dirigerer den til de aktive replikaer af applikationen med samme version. <\/p>\n

N\u00e5r der udf\u00f8res en ny implementering, bruger vi Deployer, som f\u00e5r nye komponenter, og den implementerer den nye version. Implementeringen af den nye version af applikationen betyder, at et nyt s\u00e6t replikaer \"opstilles\", hvorefter disse replikaer af den nye version startes i en separat, ny pod. Men ha-proxy ved endnu ikke noget om dem og dirigerer i \u00f8jeblikket ingen arbejdsbyrde til dem.<\/p>\n

Derfor er det f\u00f8rst n\u00f8dvendigt at udf\u00f8re en sundhedstjek af de nye versioner for at sikre, at replikaerne er klar til at h\u00e5ndtere arbejdsbyrden.<\/p>\n

\"DEVOXX
\n
\nAlle implementeringskomponenter skal underst\u00f8tte en form for sundhedstjek. Dette kan v\u00e6re et meget simpelt HTTP-kald, hvor du f\u00e5r en statuskode 200, eller en mere dybdeg\u00e5ende kontrol, hvor du tjekker forbindelsen mellem replikaerne og databasen samt andre tjenester, stabiliteten af forbindelserne i det dynamiske milj\u00f8, samt om alt k\u00f8rer og fungerer korrekt. Denne proces kan v\u00e6re ret kompliceret. <\/p>\n

\"DEVOXX
\n
\nN\u00e5r systemet har sikret sig, at alle opdaterede replikaer fungerer korrekt, vil Deployer opdatere konfigurationen og videresende den korrekte confd, der omkonfigurerer ha-proxy. <\/p>\n

\"DEVOXX
\n
\nF\u00f8rst efter dette vil trafikken blive sendt til pod'en med replikaerne af den nye version, og den gamle pod forsvinder. <\/p>\n

\"DEVOXX
\n
\nDenne mekanisme er ikke en funktion af Kubernetes. Konceptet Blue\/green deployment har eksisteret i lang tid og har altid brugt en belastningsbalance. F\u00f8rst dirigerer du al trafik til den gamle version af applikationen, og efter opdateringen flytter du det helt til den nye version. Dette princip anvendes ikke kun i Kubernetes.<\/p>\n

Nu vil jeg pr\u00e6sentere en ny implementeringskomponent \u2013 Deployer, som udf\u00f8rer sundhedstjek, rekonfigurerer proxyen og s\u00e5 videre. Dette er et koncept, der ikke henviser til den ydre verden og eksisterer inden i Kubernetes. Jeg vil vise, hvordan man kan oprette sit eget Deployer-koncept ved hj\u00e6lp af open-source v\u00e6rkt\u00f8jer. <\/p>\n

S\u00e5 det f\u00f8rste, som Deployer g\u00f8r, er at oprette en Replikations Controller (RC) ved hj\u00e6lp af Kubernetes API'en. Denne API opretter pods og services til yderligere udrulning, det vil sige den opretter et helt nyt cluster til vores applikationer. S\u00e5 snart RC'en har sikret sig, at replikaerne er startet, udf\u00f8res en sundhedstjek for deres funktionalitet. Til dette bruger Deployer kommandoen GET \/health. Den starter de relevante kontrolkomponenter og tjekker alle elementer, der er n\u00f8dvendige for, at clusteren fungerer. <\/p>\n

\"DEVOXX
\n
\nN\u00e5r alle pods har rapporteret om deres \"sundhed\", opretter Deployer et nyt konfigurationselement \u2013 et distribueret lager etcd, som bruges indenfor Kubernetes, herunder til at gemme konfigurationen for belastningsfordeleren. Vi skriver data til etcd, og et lille v\u00e6rkt\u00f8j, confd, overv\u00e5ger etcd for nye data. <\/p>\n

Hvis det opdager \u00e6ndringer i den oprindelige konfiguration, genererer det en ny konfigurationsfil og sender den til ha-proxy. I dette tilf\u00e6lde genstartes ha-proxy uden at miste nogen forbindelser, og den adresserer belastningen til de nye services, som underst\u00f8tter den nye version af vores applikationer. <\/p>\n

\"DEVOXX
\n
\nSom du kan se, er der ikke noget kompliceret her p\u00e5 trods af m\u00e6ngden af komponenter. Du skal blot v\u00e6re opm\u00e6rksom p\u00e5 API'en og etcd. Jeg vil gerne fort\u00e6lle om en open-source deployer, som vi selv bruger \u2013 Amdatu Kubernetes Deployer.<\/p>\n

\"DEVOXX
\n
\nDet er et v\u00e6rkt\u00f8j til orkestrering af Kubernetes-udrulninger med f\u00f8lgende funktioner: <\/p>\n