Kubernetes er et fantastisk værktøj til at køre Docker-containere i et klynget produktionsmiljø. Der er dog problemer, som Kubernetes ikke kan løse. Til hyppige produktionsimplementeringer har vi brug for en fuldautomatisk Blue/Green-implementering for at undgå nedetid i processen, som også skal håndtere eksterne HTTP-anmodninger og udføre SSL-offloads. Dette kræver integration med en load balancer såsom ha-proxy. En anden udfordring er semi-automatisk skalering af selve Kubernetes-klyngen, når den kører i et skymiljø, for eksempel delvis nedskalering af klyngen om natten.
Selvom Kubernetes ikke har disse funktioner ude af boksen, leverer den en API, som du kan bruge til at løse lignende problemer. Værktøjer til automatiseret Blue/Green-implementering og skalering af en Kubernetes-klynge blev udviklet som en del af Cloud RTI-projektet, som blev skabt baseret på open source.
Denne artikel, en videoudskrift, viser dig, hvordan du opsætter Kubernetes sammen med andre open source-komponenter for at skabe et produktionsklart miljø, der accepterer kode fra en git-commit uden nedetid i produktionen.
Så når du først har adgang til dine applikationer fra omverdenen, kan du begynde at opsætte automatisering fuldt ud, det vil sige bringe den til det stadie, hvor du kan udføre en git-commit og sørge for, at denne git-commit ender i produktion. Når vi implementerer disse trin, når vi implementerer implementeringen, ønsker vi naturligvis ikke at støde på nedetid. Så enhver automatisering i Kubernetes starter med API'en.
Kubernetes er ikke et værktøj, der kan bruges produktivt ud af boksen. Selvfølgelig kan du gøre det, bruge kubectl og så videre, men alligevel er API'et det mest interessante og nyttige ved denne platform. Ved at bruge API'et som et sæt funktioner kan du få adgang til næsten alt, hvad du vil gøre i Kubernetes. kubectl selv bruger også REST API.
Dette er REST, så du kan bruge ethvert sprog eller værktøj til at arbejde med denne API, men dit liv vil blive gjort meget lettere af brugerdefinerede biblioteker. Mit team skrev 2 sådanne biblioteker: et til Java/OSGi og et til Go. Den anden bruges ikke ofte, men under alle omstændigheder har du disse nyttige ting til din rådighed. De er et delvist licenseret open source-projekt. Der er mange sådanne biblioteker til forskellige sprog, så du kan vælge dem, der passer dig bedst.
Så før du begynder at automatisere din implementering, skal du sikre dig, at processen ikke vil være genstand for nogen nedetid. For eksempel udfører vores team produktionsimplementeringer midt på dagen, når folk bruger applikationerne mest, så det er vigtigt at undgå forsinkelser i denne proces. For at undgå nedetid bruges 2 metoder: blå/grøn implementering eller rullende opdatering. I sidstnævnte tilfælde, hvis du har 5 replikaer af programmet kørende, opdateres de sekventielt efter hinanden. Denne metode fungerer godt, men den er ikke egnet, hvis du har forskellige versioner af applikationen kørende samtidigt under implementeringsprocessen. I dette tilfælde kan du opdatere brugergrænsefladen, mens backend kører den gamle version, og applikationen holder op med at fungere. Derfor er det fra et programmeringssynspunkt ret vanskeligt at arbejde under sådanne forhold.
Dette er en af grundene til, at vi foretrækker at bruge blå/grøn implementering til at automatisere implementeringen af vores applikationer. Med denne metode skal du sikre dig, at kun én version af applikationen er aktiv ad gangen.
Den blå/grønne implementeringsmekanisme ser sådan ud. Vi modtager trafik til vores applikationer gennem ha-proxy, som videresender den til kørende replikaer af applikationen af samme version.
Når der laves en ny implementering, bruger vi Deployer, som får de nye komponenter og implementerer den nye version. At implementere en ny version af en applikation betyder, at et nyt sæt replikaer "hæves", hvorefter disse replikaer af den nye version lanceres i en separat, ny pod. Ha-proxy ved dog intet om dem og dirigerer ikke nogen arbejdsbyrde til dem endnu.
Derfor er det først og fremmest nødvendigt at udføre et ydelsestjek af nye versioner af sundhedstjek for at sikre, at replikaerne er klar til at servicere lasten.
Alle implementeringskomponenter skal understøtte en form for sundhedstjek. Dette kan være et meget simpelt HTTP-opkaldstjek, når du modtager en kode med status 200, eller et mere dybtgående tjek, hvor du kontrollerer replikernes forbindelse med databasen og andre tjenester, stabiliteten af de dynamiske miljøforbindelser , og om alt starter og fungerer korrekt. Denne proces kan være ret kompleks.
Når systemet har verificeret, at alle opdaterede replikaer fungerer, vil Deployer opdatere konfigurationen og videregive den korrekte confd, som omkonfigurerer ha-proxy.
Først efter dette vil trafik blive dirigeret til poden med kopier af den nye version, og den gamle pod forsvinder.
Denne mekanisme er ikke en funktion af Kubernetes. Konceptet med blå/grøn implementering har eksisteret i ret lang tid, og det har altid brugt en load balancer. Først dirigerer du al trafik til den gamle version af applikationen, og efter opdateringen overfører du den helt til den nye version. Dette princip bruges ikke kun i Kubernetes.
Nu vil jeg introducere dig til en ny implementeringskomponent - Deployer, som udfører sundhedstjek, omkonfigurerer proxyer og så videre. Dette er et koncept, der ikke gælder for omverdenen og eksisterer inde i Kubernetes. Jeg viser dig, hvordan du kan skabe dit eget Deployer-koncept ved hjælp af open source-værktøjer.
Så den første ting, Deployer gør, er at oprette en RC-replikeringscontroller ved hjælp af Kubernetes API. Denne API opretter pods og tjenester til yderligere udrulning, det vil sige, den skaber en helt ny klynge til vores applikationer. Så snart RC er overbevist om, at replikaerne er startet, vil den udføre et sundhedstjek af deres funktionalitet. For at gøre dette bruger Deployer kommandoen GET /health. Den kører de relevante scanningskomponenter og kontrollerer alle elementer, der understøtter driften af klyngen.
Efter at alle pods har rapporteret deres helbred, opretter Deployer et nyt konfigurationselement - etcd distributed storage, som bruges internt af Kubernetes, herunder lagring af load balancer-konfigurationen. Vi skriver data til etcd, og et lille værktøj kaldet confd overvåger etcd for nye data.
Hvis den registrerer ændringer i den oprindelige konfiguration, genererer den en ny indstillingsfil og overfører den til ha-proxy. I dette tilfælde genstarter ha-proxy uden at miste nogen forbindelser og adresserer belastningen til nye tjenester, der gør det muligt for den nye version af vores applikationer at fungere.
Som du kan se, på trods af overfloden af komponenter, er der ikke noget kompliceret her. Du skal bare være mere opmærksom på API og etcd. Jeg vil gerne fortælle dig om den open source-deployer, som vi selv bruger - Amdatu Kubernetes Deployer.
Det er et værktøj til at orkestrere Kubernetes-implementeringer og har følgende funktioner:
- blå/grøn udrulning;
- opsætning af en ekstern belastningsbalancer;
- styring af implementeringsbeskrivelser;
- styring af den faktiske implementering;
- kontrol af funktionaliteten af sundhedstjek under implementering;
- implementering af miljøvariabler i pods.
Denne Deployer er bygget oven på Kubernetes API og giver en REST API til styring af håndtag og implementeringer samt en Websocket API til streaming af logfiler under implementeringsprocessen.
Det sætter load balancer konfigurationsdataene ind i etcd, så du ikke behøver at bruge ha-proxy med out-of-the-box support, men nemt bruge din egen load balancer konfigurationsfil. Amdatu Deployer er skrevet i Go, ligesom Kubernetes selv, og er licenseret af Apache.
Før jeg begyndte at bruge denne version af deployeren, brugte jeg følgende implementeringsbeskrivelse, som specificerer de parametre, jeg har brug for.
En af de vigtige parametre i denne kode er at aktivere flaget "useHealthCheck". Vi er nødt til at specificere, at et sundhedstjek skal udføres under implementeringsprocessen. Denne indstilling kan deaktiveres, når implementeringen bruger tredjepartscontainere, der ikke skal bekræftes. Denne beskrivelse angiver også antallet af replikaer og frontend-URL'en, som ha-proxy har brug for. Til sidst er pod-specifikationsflaget "podspec", som kalder Kubernetes for information om portkonfiguration, billede osv. Dette er en ret simpel JSON-beskrivelse.
Et andet værktøj, der er en del af open source Amdatu-projektet, er Deploymentctl. Den har en brugergrænseflade til konfiguration af implementeringer, gemmer implementeringshistorik og indeholder webhooks til tilbagekald fra tredjepartsbrugere og udviklere. Du må ikke bruge brugergrænsefladen, da Amdatu Deployer selv er en REST API, men denne grænseflade kan gøre implementeringen meget lettere for dig uden at involvere nogen API. Deploymentctl er skrevet i OSGi/Vertx ved hjælp af Angular 2.
Jeg vil nu demonstrere ovenstående på skærmen ved hjælp af en forudindspillet optagelse, så du ikke behøver at vente. Vi vil implementere en simpel Go-applikation. Bare rolig, hvis du ikke har prøvet Go før, det er et meget simpelt program, så du burde kunne finde ud af det.
Her laver vi en HTTP-server, der kun reagerer på /health, så denne applikation tester kun sundhedstjekket og intet andet. Hvis kontrollen består, bruges JSON-strukturen vist nedenfor. Den indeholder den version af applikationen, der vil blive implementeret af deployeren, meddelelsen, som du ser øverst i filen, og den boolske datatype - uanset om vores applikation virker eller ej.
Jeg snød lidt med den sidste linje, fordi jeg placerede en fast boolesk værdi øverst i filen, som i fremtiden vil hjælpe mig med at implementere selv en "usund" applikation. Vi behandler dette senere.
Så lad os komme i gang. Først tjekker vi for tilstedeværelsen af eventuelle kørende pods ved hjælp af kommandoen ~ kubectl get pods, og baseret på fraværet af et svar fra frontend-URL'en sikrer vi os, at der ikke i øjeblikket foretages nogen implementeringer.
Næste på skærmen ser du Deploymentctl-grænsefladen, som jeg nævnte, hvori implementeringsparametrene er indstillet: navneområde, applikationsnavn, implementeringsversion, antal replikaer, frontend-URL, containernavn, billede, ressourcegrænser, portnummer til sundhedstjek, osv. . Ressourcegrænser er meget vigtige, da de giver dig mulighed for at bruge den størst mulige mængde hardware. Her kan du også se implementeringsloggen.
Hvis du nu gentager kommandoen ~ kubectl get pods, kan du se, at systemet "fryser" i 20 sekunder, hvorefter ha-proxy rekonfigureres. Herefter starter poden, og vores replika kan ses i implementeringsloggen.
Jeg fjernede ventetiden på 20 sekunder fra videoen, og nu kan du se på skærmen, at den første version af applikationen er blevet implementeret. Alt dette blev gjort ved hjælp af kun brugergrænsefladen.
Lad os nu prøve den anden version. For at gøre dette ændrer jeg programmets besked fra "Hej, Kubernetes!" på “Hej, Deployer!”, opretter systemet dette billede og placerer det i Docker-registret, hvorefter vi blot klikker på knappen “Deploy” igen i Deploymentctl-vinduet. I dette tilfælde startes implementeringsloggen automatisk på samme måde, som det skete, da den første version af programmet blev implementeret.
Kommandoen ~ kubectl get pods viser, at der i øjeblikket kører 2 versioner af applikationen, men frontend viser, at vi stadig kører version 1.
Belastningsbalanceren venter på, at sundhedstjekket er fuldført, før trafikken omdirigeres til den nye version. Efter 20 sekunder skifter vi til curl og ser, at vi nu har version 2 af applikationen installeret, og den første er blevet slettet.
Dette var implementeringen af en "sund" applikation. Lad os se, hvad der sker, hvis jeg for en ny version af applikationen ændrer parameteren Sund fra sand til falsk, det vil sige, jeg forsøger at implementere en usund applikation, der har fejlet sundhedstjekket. Dette kan ske, hvis der blev lavet nogle konfigurationsfejl i applikationen på udviklingsstadiet, og den blev sendt i produktion i denne form.
Som du kan se, gennemgår implementeringen alle trinene ovenfor, og ~kubectl get pods viser, at begge pods kører. Men i modsætning til den tidligere implementering viser loggen timeout-statussen. Det vil sige, at på grund af, at sundhedstjekket mislykkedes, kan den nye version af applikationen ikke implementeres. Som et resultat kan du se, at systemet er vendt tilbage til at bruge den gamle version af applikationen, og den nye version er simpelthen blevet afinstalleret.
Det gode ved dette er, at selvom du har et stort antal samtidige anmodninger, der kommer ind i applikationen, vil de ikke engang bemærke nedetiden, mens de implementerer implementeringsproceduren. Hvis du tester denne applikation ved hjælp af Gatling-rammeværket, som sender den så mange anmodninger som muligt, vil ingen af disse anmodninger blive slettet. Det betyder, at vores brugere ikke engang bemærker versionsopdateringer i realtid. Hvis det mislykkes, fortsætter arbejdet med den gamle version; hvis det lykkes, skifter brugerne til den nye version.
Der er kun én ting, der kan mislykkes - hvis sundhedstjekket lykkes, men applikationen fejler, så snart arbejdsbyrden påføres den, det vil sige, at sammenbruddet først sker efter implementeringen er afsluttet. I dette tilfælde skal du manuelt rulle tilbage til den gamle version. Så vi så på, hvordan man bruger Kubernetes med open source-værktøjer designet til det. Implementeringsprocessen bliver meget nemmere, hvis du indbygger disse værktøjer i dine Build/Deploy pipelines. Samtidig kan du for at starte implementeringen bruge enten brugergrænsefladen eller fuldautomatisere denne proces ved at bruge for eksempel commit to master.
Vores Build Server vil oprette et Docker-image, skubbe det ind i Docker Hub eller hvilket register du bruger. Docker Hub understøtter webhook, så vi kan udløse fjernimplementering via Deployer på den måde, der er vist ovenfor. På denne måde kan du fuldt ud automatisere implementeringen af din applikation til potentiel produktion.
Lad os gå videre til næste emne - skalering af Kubernetes-klyngen. Bemærk, at kubectl-kommandoen er en skaleringskommando. Med mere hjælp kan vi nemt øge antallet af replikaer i vores eksisterende klynge. Men i praksis ønsker vi normalt at øge antallet af noder frem for pods.
Samtidig kan det være nødvendigt at øge i arbejdstiden, og om natten, for at reducere omkostningerne ved Amazon-tjenester, skal du muligvis reducere antallet af kørende applikationsforekomster. Det betyder ikke, at det er nok at skalere kun antallet af pods, for selvom en af noderne er inaktiv, skal du stadig betale Amazon for det. Det vil sige, at du sammen med skalering af bælgerne skal skalere antallet af brugte maskiner.
Dette kan være udfordrende, for uanset om vi bruger Amazon eller en anden cloud-tjeneste, ved Kubernetes intet om antallet af maskiner, der bruges. Den mangler et værktøj, der giver dig mulighed for at skalere systemet på nodeniveau.
Så vi bliver nødt til at tage os af både noder og bælg. Vi kan nemt skalere lanceringen af nye noder ved hjælp af AWS API og skaleringsgruppemaskiner til at konfigurere antallet af Kubernetes-arbejderknudepunkter. Du kan også bruge cloud-init eller et lignende script til at registrere noder i Kubernetes-klyngen.
Den nye maskine starter i skaleringsgruppen, starter sig selv som en node, registrerer sig i masterens register og begynder at arbejde. Herefter kan du øge antallet af replikaer til brug på de resulterende noder. Nedskalering kræver mere indsats, da du skal sikre dig, at et sådant trin ikke fører til ødelæggelse af allerede kørende applikationer efter at have slukket "unødvendige" maskiner. For at forhindre et sådant scenarie skal du indstille noderne til statussen "uplanlagt". Dette betyder, at standardplanlæggeren vil ignorere disse noder, når de planlægger DaemonSet-pods. Planlæggeren vil ikke slette noget fra disse servere, men vil heller ikke starte nogen nye containere der. Næste trin er at fordrive afløbsknuden, det vil sige at overføre kørende pods fra den til en anden maskine eller andre noder, der har tilstrækkelig kapacitet til dette. Når du har sikret dig, at der ikke længere er nogen beholdere på disse noder, kan du fjerne dem fra Kubernetes. Herefter vil de simpelthen ophøre med at eksistere for Kubernetes. Dernæst skal du bruge AWS API til at deaktivere unødvendige noder eller maskiner.
Du kan bruge Amdatu Scalerd, et andet open source-skaleringsværktøj, der ligner AWS API. Det giver en CLI til at tilføje eller fjerne noder i en klynge. Dens interessante funktion er evnen til at konfigurere skemalæggeren ved hjælp af følgende json-fil.
Den viste kode reducerer klyngekapaciteten til det halve i natperioden. Den konfigurerer både antallet af tilgængelige replikaer og den ønskede kapacitet for Amazon-klyngen. Brug af denne skemalægger vil automatisk reducere antallet af noder om natten og øge dem om morgenen, hvilket sparer omkostningerne ved at bruge noder fra en skytjeneste som Amazon. Denne funktion er ikke indbygget i Kubernetes, men brug af Scalerd vil give dig mulighed for at skalere denne platform, som du vil.
Jeg vil gerne påpege, at mange mennesker siger til mig: "Det er godt og vel, men hvad med min database, som normalt er statisk?" Hvordan kan du køre sådan noget i et dynamisk miljø som Kubernetes? Efter min mening skal du ikke gøre dette, du skal ikke forsøge at køre et datavarehus i Kubernetes. Dette er teknisk muligt, og der er tutorials på internettet om dette emne, men det vil alvorligt komplicere dit liv.
Ja, der er et koncept med vedvarende butikker i Kubernetes, og du kan prøve at køre datalagre som Mongo eller MySQL, men det er en ret arbejdskrævende opgave. Dette skyldes, at datavarehuse ikke fuldt ud understøtter interaktion med et dynamisk miljø. De fleste databaser kræver betydelig konfiguration, inklusive manuel konfiguration af klyngen, kan ikke lide autoskalering og andre lignende ting.
Derfor bør du ikke komplicere dit liv ved at prøve at køre et datavarehus i Kubernetes. Organiser deres arbejde på den traditionelle måde ved hjælp af velkendte tjenester og giv Kubernetes simpelthen muligheden for at bruge dem.
Som afslutning på emnet vil jeg gerne introducere dig til Cloud RTI-platformen baseret på Kubernetes, som mit team arbejder på. Det giver centraliseret logning, applikations- og klyngeovervågning og mange andre nyttige funktioner, der vil være nyttige. Den bruger forskellige open source-værktøjer såsom Grafana til at vise overvågning.
Der var et spørgsmål om, hvorfor man bruger ha-proxy load balancer med Kubernetes. Godt spørgsmål, fordi der i øjeblikket er 2 niveauer af belastningsbalancering. Kubernetes-tjenester findes stadig på virtuelle IP-adresser. Du kan ikke bruge dem til porte på eksterne værtsmaskiner, fordi hvis Amazon overbelaster sin cloud-vært, vil adressen ændre sig. Det er grunden til, at vi placerer ha-proxy foran tjenesterne - for at skabe en mere statisk struktur for trafik til at kommunikere problemfrit med Kubernetes.
Et andet godt spørgsmål er, hvordan kan du tage dig af databaseskemaændringer, når du laver blå/grøn implementering? Faktum er, at uanset brugen af Kubernetes, er det en vanskelig opgave at ændre databaseskemaet. Du skal sikre dig, at det gamle og det nye skema er kompatible, hvorefter du kan opdatere databasen og derefter opdatere selve applikationerne. Du kan hot-swap databasen og derefter opdatere applikationerne. Jeg kender folk, der har startet en helt ny databaseklynge op med et nyt skema, dette er en mulighed, hvis du har en skemaløs database som Mongo, men det er alligevel ikke en nem opgave. Hvis du ikke har yderligere spørgsmål, tak for din opmærksomhed!
Nogle annoncer 🙂
Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, , en unik analog af entry-level servere, som blev opfundet af os til dig: (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om
Kilde: www.habr.com