Kubernetes er et flott verktøy for å kjøre Docker-beholdere i et gruppert produksjonsmiljø. Det er imidlertid problemer som Kubernetes ikke kan løse. For hyppige produksjonsdistribusjoner trenger vi en helautomatisert blå/grønn distribusjon for å unngå nedetid i prosessen, som også må håndtere eksterne HTTP-forespørsler og utføre SSL-avlastninger. Dette krever integrasjon med en lastbalanser som ha-proxy. En annen utfordring er halvautomatisk skalering av selve Kubernetes-klyngen når den kjøres i et skymiljø, for eksempel delvis nedskalering av klyngen om natten.
Selv om Kubernetes ikke har disse funksjonene ut av esken, gir den en API som du kan bruke til å løse lignende problemer. Verktøy for automatisert blå/grønn distribusjon og skalering av en Kubernetes-klynge ble utviklet som en del av Cloud RTI-prosjektet, som ble opprettet basert på åpen kildekode.
Denne artikkelen, en videoutskrift, viser deg hvordan du setter opp Kubernetes sammen med andre åpen kildekode-komponenter for å lage et produksjonsklart miljø som aksepterer kode fra en git-commit uten nedetid i produksjonen.
Så, når du først har tilgang til applikasjonene dine fra omverdenen, kan du begynne å sette opp automatisering fullt ut, det vil si bringe den til stadiet hvor du kan utføre en git-commit og sørge for at denne git-commit ender opp i produksjon. Når vi implementerer disse trinnene, når vi implementerer distribusjon, ønsker vi naturligvis ikke å oppleve nedetid. Så enhver automatisering i Kubernetes starter med API.
Kubernetes er ikke et verktøy som kan brukes produktivt ut av esken. Selvfølgelig kan du gjøre det, bruke kubectl og så videre, men API er likevel det mest interessante og nyttige med denne plattformen. Ved å bruke API som et sett med funksjoner kan du få tilgang til nesten alt du vil gjøre i Kubernetes. kubectl selv bruker også REST API.
Dette er REST, så du kan bruke hvilket som helst språk eller verktøy for å jobbe med denne API-en, men livet ditt vil bli mye enklere av egendefinerte biblioteker. Teamet mitt skrev 2 slike biblioteker: ett for Java/OSGi og ett for Go. Den andre brukes ikke ofte, men uansett har du disse nyttige tingene til din disposisjon. De er et delvis lisensiert åpen kildekode-prosjekt. Det finnes mange slike biblioteker for ulike språk, så du kan velge de som passer deg best.
Så før du begynner å automatisere distribusjonen, må du sørge for at prosessen ikke vil være gjenstand for nedetid. For eksempel utfører teamet vårt produksjonsdistribusjoner midt på dagen når folk bruker applikasjonene på sitt meste, så det er viktig å unngå forsinkelser i denne prosessen. For å unngå nedetid brukes 2 metoder: blå/grønn distribusjon eller rullende oppdatering. I det siste tilfellet, hvis du har 5 replikaer av programmet kjørende, oppdateres de sekvensielt etter hverandre. Denne metoden fungerer utmerket, men den er ikke egnet hvis du har forskjellige versjoner av applikasjonen som kjører samtidig under distribusjonsprosessen. I dette tilfellet kan du oppdatere brukergrensesnittet mens backend kjører den gamle versjonen, og applikasjonen vil slutte å fungere. Derfor, fra et programmeringssynspunkt, er det ganske vanskelig å jobbe under slike forhold.
Dette er en av grunnene til at vi foretrekker å bruke blå/grønn distribusjon for å automatisere distribusjonen av applikasjonene våre. Med denne metoden må du sørge for at bare én versjon av applikasjonen er aktiv om gangen.
Den blå/grønne distribusjonsmekanismen ser slik ut. Vi mottar trafikk for applikasjonene våre gjennom ha-proxy, som videresender den til kjørende kopier av applikasjonen av samme versjon.
Når en ny distribusjon gjøres, bruker vi Deployer, som får de nye komponentene og distribuerer den nye versjonen. Utplassering av en ny versjon av en applikasjon betyr at et nytt sett med replikaer "heves", hvoretter disse replikaene av den nye versjonen lanseres i en egen, ny pod. Ha-proxy vet imidlertid ingenting om dem og sender ingen arbeidsbelastning til dem ennå.
Derfor er det først og fremst nødvendig å utføre en ytelsessjekk av nye versjoner av helsesjekking for å sikre at replikaene er klare til å betjene lasten.
Alle distribusjonskomponenter må støtte en form for helsesjekk. Dette kan være en veldig enkel HTTP-anropssjekk, når du mottar en kode med status 200, eller en mer dyptgående sjekk, der du sjekker koblingen til replikaene med databasen og andre tjenester, stabiliteten til de dynamiske miljøforbindelsene , og om alt starter og fungerer som det skal. Denne prosessen kan være ganske kompleks.
Etter at systemet har verifisert at alle oppdaterte replikaer fungerer, vil Deployer oppdatere konfigurasjonen og sende riktig confd, som vil rekonfigurere ha-proxy.
Først etter dette vil trafikk bli dirigert til poden med kopier av den nye versjonen, og den gamle poden vil forsvinne.
Denne mekanismen er ikke en funksjon i Kubernetes. Konseptet med blå/grønn utplassering har eksistert ganske lenge, og det har alltid brukt en lastbalanser. Først dirigerer du all trafikk til den gamle versjonen av applikasjonen, og etter oppdateringen overfører du den fullstendig til den nye versjonen. Dette prinsippet brukes ikke bare i Kubernetes.
Nå skal jeg introdusere deg for en ny distribusjonskomponent - Deployer, som utfører helsesjekker, rekonfigurerer proxyer, og så videre. Dette er et konsept som ikke gjelder omverdenen og eksisterer inne i Kubernetes. Jeg skal vise deg hvordan du kan lage ditt eget Deployer-konsept ved å bruke åpen kildekode-verktøy.
Så det første Deployer gjør er å lage en RC-replikeringskontroller ved å bruke Kubernetes API. Denne APIen lager pods og tjenester for videre distribusjon, det vil si at den oppretter en helt ny klynge for applikasjonene våre. Så snart RC er overbevist om at replikaene har startet, vil den utføre en helsesjekk av funksjonaliteten deres. For å gjøre dette bruker Deployer kommandoen GET /health. Den kjører de riktige skannekomponentene og sjekker alle elementer som støtter driften av klyngen.
Etter at alle pods har rapportert helsen sin, oppretter Deployer et nytt konfigurasjonselement - etcd distributed storage, som brukes internt av Kubernetes, inkludert lagring av load balancer-konfigurasjonen. Vi skriver data til etcd, og et lite verktøy kalt confd overvåker etcd for nye data.
Hvis den oppdager endringer i den opprinnelige konfigurasjonen, genererer den en ny innstillingsfil og overfører den til ha-proxy. I dette tilfellet starter ha-proxy på nytt uten å miste noen tilkoblinger og adresserer belastningen til nye tjenester som gjør at den nye versjonen av applikasjonene våre kan fungere.
Som du kan se, til tross for overfloden av komponenter, er det ingenting komplisert her. Du trenger bare å være mer oppmerksom på API og etcd. Jeg vil fortelle deg om åpen kildekode-deployer som vi selv bruker - Amdatu Kubernetes Deployer.
Det er et verktøy for å orkestrere Kubernetes-distribusjoner og har følgende funksjoner:
- blå/grønn utplassering;
- sette opp en ekstern lastbalanser;
- administrasjon av distribusjonsbeskrivelse;
- administrere selve distribusjonen;
- sjekke funksjonaliteten til helsesjekker under distribusjon;
- implementering av miljøvariabler i pods.
Denne deployeren er bygget på toppen av Kubernetes API og gir en REST API for å administrere håndtak og distribusjoner, samt en Websocket API for streaming av logger under distribusjonsprosessen.
Den legger load balancer konfigurasjonsdata inn i etcd, slik at du ikke trenger å bruke ha-proxy med out-of-the-box støtte, men enkelt bruke din egen load balancer konfigurasjonsfil. Amdatu Deployer er skrevet i Go, som Kubernetes selv, og er lisensiert av Apache.
Før jeg begynte å bruke denne versjonen av distribusjonsprogrammet, brukte jeg følgende distribusjonsbeskrivelse, som spesifiserer parameterne jeg trenger.
En av de viktige parameterne til denne koden er å aktivere "useHealthCheck"-flagget. Vi må spesifisere at en tilregnelighetssjekk må utføres under distribusjonsprosessen. Denne innstillingen kan deaktiveres når distribusjonen bruker tredjepartsbeholdere som ikke trenger å verifiseres. Denne beskrivelsen angir også antall replikaer og grensesnitt-URLen som ha-proxy trenger. På slutten er pod-spesifikasjonsflagget "podspec", som kaller Kubernetes for informasjon om portkonfigurasjon, bilde osv. Dette er en ganske enkel JSON-beskrivelse.
Et annet verktøy som er en del av Amdatu-prosjektet med åpen kildekode er Deploymentctl. Den har et brukergrensesnitt for å konfigurere distribusjoner, lagrer distribusjonshistorikk og inneholder webhooks for tilbakeringinger fra tredjepartsbrukere og utviklere. Du kan ikke bruke brukergrensesnittet siden Amdatu Deployer i seg selv er et REST API, men dette grensesnittet kan gjøre distribusjonen mye enklere for deg uten å involvere noen API. Deploymentctl er skrevet i OSGi/Vertx ved å bruke Angular 2.
Jeg vil nå demonstrere ovenstående på skjermen ved å bruke et forhåndsinnspilt opptak slik at du ikke trenger å vente. Vi vil distribuere en enkel Go-applikasjon. Ikke bekymre deg hvis du ikke har prøvd Go før, det er et veldig enkelt program, så du bør kunne finne ut av det.
Her lager vi en HTTP-server som kun reagerer på /health, så denne applikasjonen tester kun helsesjekken og ingenting annet. Hvis kontrollen består, brukes JSON-strukturen vist nedenfor. Den inneholder versjonen av applikasjonen som vil bli distribuert av distribusjonen, meldingen du ser øverst i filen, og den boolske datatypen - om applikasjonen vår fungerer eller ikke.
Jeg jukset litt med den siste linjen, fordi jeg plasserte en fast boolsk verdi øverst i filen, som i fremtiden vil hjelpe meg med å distribuere selv en "usunn" applikasjon. Vi skal ta for oss dette senere.
Så la oss komme i gang. Først sjekker vi for tilstedeværelsen av løpende pods ved å bruke kommandoen ~ kubectl get pods, og basert på fraværet av et svar fra frontend-URLen, sørger vi for at ingen distribusjoner for øyeblikket blir gjort.
Neste på skjermen ser du Deploymentctl-grensesnittet jeg nevnte, der distribusjonsparametere er satt: navneområde, applikasjonsnavn, distribusjonsversjon, antall replikaer, frontend-URL, beholdernavn, bilde, ressursgrenser, portnummer for helsesjekk, osv. . Ressursgrenser er svært viktige, siden de lar deg bruke maksimalt mulig mengde maskinvare. Her kan du også se distribusjonsloggen.
Hvis du nå gjentar kommandoen ~ kubectl get pods, kan du se at systemet "fryser" i 20 sekunder, hvor ha-proxy rekonfigureres. Etter dette starter poden, og replikaen vår kan sees i distribusjonsloggen.
Jeg kuttet ut ventetiden på 20 sekunder fra videoen, og nå kan du se på skjermen at den første versjonen av applikasjonen har blitt distribuert. Alt dette ble gjort med kun brukergrensesnittet.
La oss nå prøve den andre versjonen. For å gjøre dette endrer jeg programmets melding fra "Hei, Kubernetes!" på "Hei, Deployer!", oppretter systemet dette bildet og plasserer det i Docker-registeret, hvoretter vi ganske enkelt klikker på "Deploy"-knappen igjen i Deploymentctl-vinduet. I dette tilfellet startes distribusjonsloggen automatisk på samme måte som den skjedde da den første versjonen av programmet ble distribuert.
Kommandoen ~ kubectl get pods viser at det for øyeblikket er 2 versjoner av applikasjonen som kjører, men frontend viser at vi fortsatt kjører versjon 1.
Lastbalanseren venter på at helsesjekken er fullført før trafikken omdirigeres til den nye versjonen. Etter 20 sekunder bytter vi til curl og ser at vi nå har versjon 2 av applikasjonen utplassert, og den første er slettet.
Dette var utplasseringen av en "sunn" applikasjon. La oss se hva som skjer hvis jeg for en ny versjon av applikasjonen endrer Healthy-parameteren fra sann til usann, det vil si at jeg prøver å distribuere en usunn applikasjon som har mislyktes i helsesjekken. Dette kan skje hvis det ble gjort noen konfigurasjonsfeil i applikasjonen på utviklingsstadiet, og den ble sendt i produksjon i dette skjemaet.
Som du kan se, går distribusjonen gjennom alle trinnene ovenfor og ~kubectl get pods viser at begge podene kjører. Men i motsetning til forrige distribusjon, viser loggen tidsavbruddsstatusen. Det vil si at på grunn av at helsesjekken mislyktes, kan ikke den nye versjonen av applikasjonen distribueres. Som et resultat ser du at systemet har gått tilbake til å bruke den gamle versjonen av applikasjonen, og den nye versjonen har ganske enkelt blitt avinstallert.
Det som er bra med dette er at selv om du har et stort antall samtidige forespørsler som kommer inn i applikasjonen, vil de ikke engang legge merke til nedetiden mens de implementerer distribusjonsprosedyren. Hvis du tester denne applikasjonen ved å bruke Gatling-rammeverket, som sender den så mange forespørsler som mulig, vil ingen av disse forespørslene bli droppet. Dette betyr at brukerne våre ikke en gang vil legge merke til versjonsoppdateringer i sanntid. Hvis det mislykkes, vil arbeidet fortsette med den gamle versjonen; hvis det lykkes, vil brukerne bytte til den nye versjonen.
Det er bare én ting som kan mislykkes - hvis helsesjekken lykkes, men applikasjonen mislykkes så snart arbeidsbelastningen påføres den, det vil si at kollapsen vil skje først etter at distribusjonen er fullført. I dette tilfellet må du manuelt rulle tilbake til den gamle versjonen. Så vi så på hvordan du bruker Kubernetes med åpen kildekode-verktøy designet for det. Distribusjonsprosessen vil være mye enklere hvis du bygger disse verktøyene inn i Build/Deploy pipelines. Samtidig, for å starte utrullingen, kan du bruke enten brukergrensesnittet eller fullautomatisere denne prosessen ved å bruke for eksempel commit to master.
Byggserveren vår lager et Docker-bilde, skyver det inn i Docker Hub eller hvilket register du bruker. Docker Hub støtter webhook, slik at vi kan utløse ekstern distribusjon via Deployer på måten vist ovenfor. På denne måten kan du fullt ut automatisere distribusjonen av applikasjonen din til potensiell produksjon.
La oss gå videre til neste emne - skalering av Kubernetes-klyngen. Merk at kubectl-kommandoen er en skaleringskommando. Med mer hjelp kan vi enkelt øke antallet replikaer i vår eksisterende klynge. Men i praksis ønsker vi vanligvis å øke antall noder i stedet for pods.
Samtidig kan det hende du må øke i arbeidstiden, og om natten, for å redusere kostnadene for Amazon-tjenester, kan det hende du må redusere antall kjørende applikasjonsforekomster. Dette betyr ikke at det vil være nok å skalere bare antall pods, for selv om en av nodene er inaktiv, vil du fortsatt måtte betale Amazon for det. Det vil si, sammen med å skalere podene, må du skalere antall maskiner som brukes.
Dette kan være utfordrende fordi enten vi bruker Amazon eller en annen skytjeneste, vet Kubernetes ingenting om antall maskiner som brukes. Den mangler et verktøy som lar deg skalere systemet på nodenivå.
Så vi må ta vare på både noder og poder. Vi kan enkelt skalere lanseringen av nye noder ved å bruke AWS API og skaleringsgruppemaskiner for å konfigurere antall Kubernetes-arbeidernoder. Du kan også bruke cloud-init eller et lignende skript for å registrere noder i Kubernetes-klyngen.
Den nye maskinen starter i Skaleringsgruppen, starter seg selv som en node, registrerer seg i masterregisteret og begynner å fungere. Etter dette kan du øke antall replikaer for bruk på de resulterende nodene. Nedskalering krever mer innsats, da du må sørge for at et slikt trinn ikke fører til ødeleggelse av allerede kjørende applikasjoner etter å ha slått av "unødvendige" maskiner. For å forhindre et slikt scenario, må du sette nodene til statusen "uplanlagt". Dette betyr at standardplanleggeren vil ignorere disse nodene når du planlegger DaemonSet-poder. Planleggeren vil ikke slette noe fra disse serverne, men vil heller ikke starte noen nye beholdere der. Neste trinn er å fjerne dreneringsnoden, det vil si å overføre løpende pods fra den til en annen maskin, eller andre noder som har tilstrekkelig kapasitet til dette. Når du har forsikret deg om at det ikke lenger er noen beholdere på disse nodene, kan du fjerne dem fra Kubernetes. Etter dette vil de rett og slett slutte å eksistere for Kubernetes. Deretter må du bruke AWS API for å deaktivere unødvendige noder eller maskiner.
Du kan bruke Amdatu Scalerd, et annet åpen kildekode-skaleringsverktøy som ligner på AWS API. Den gir en CLI for å legge til eller fjerne noder i en klynge. Dens interessante funksjon er muligheten til å konfigurere planleggeren ved å bruke følgende json-fil.
Den viste koden halverer klyngekapasiteten i nattperioden. Den konfigurerer både antall tilgjengelige kopier og ønsket kapasitet til Amazon-klyngen. Bruk av denne planleggeren vil automatisk redusere antall noder om natten og øke dem om morgenen, noe som sparer kostnadene ved å bruke noder fra en skytjeneste som Amazon. Denne funksjonen er ikke innebygd i Kubernetes, men ved å bruke Scalerd kan du skalere denne plattformen slik du vil.
Jeg vil gjerne påpeke at mange mennesker sier til meg: "Det er vel og bra, men hva med databasen min, som vanligvis er statisk?" Hvordan kan du kjøre noe slikt i et dynamisk miljø som Kubernetes? Etter min mening bør du ikke gjøre dette, du bør ikke prøve å drive et datavarehus i Kubernetes. Dette er teknisk mulig, og det er veiledninger på Internett om dette emnet, men det vil alvorlig komplisere livet ditt.
Ja, det er et konsept med vedvarende butikker i Kubernetes, og du kan prøve å kjøre databutikker som Mongo eller MySQL, men dette er en ganske arbeidskrevende oppgave. Dette skyldes det faktum at datavarehus ikke fullt ut støtter interaksjon med et dynamisk miljø. De fleste databaser krever betydelig konfigurasjon, inkludert manuell konfigurasjon av klyngen, liker ikke autoskalering og andre lignende ting.
Derfor bør du ikke komplisere livet ditt ved å prøve å drive et datavarehus i Kubernetes. Organiser arbeidet sitt på tradisjonell måte ved å bruke kjente tjenester og gi Kubernetes rett og slett muligheten til å bruke dem.
For å avslutte emnet vil jeg introdusere deg til Cloud RTI-plattformen basert på Kubernetes, som teamet mitt jobber med. Den gir sentralisert logging, applikasjons- og klyngeovervåking og mange andre nyttige funksjoner som vil komme godt med. Den bruker forskjellige åpen kildekode-verktøy som Grafana for å vise overvåking.
Det var et spørsmål om hvorfor bruke ha-proxy load balancer med Kubernetes. Godt spørsmål fordi det for øyeblikket er 2 nivåer av lastbalansering. Kubernetes-tjenester ligger fortsatt på virtuelle IP-adresser. Du kan ikke bruke dem for porter på eksterne vertsmaskiner fordi hvis Amazon overbelaster skyverten sin, vil adressen endres. Dette er grunnen til at vi plasserer ha-proxy foran tjenestene – for å skape en mer statisk struktur for trafikk som kan kommunisere sømløst med Kubernetes.
Et annet godt spørsmål er hvordan kan du ta vare på databaseskjemaendringer når du utfører blå/grønn distribusjon? Faktum er at uansett bruk av Kubernetes, er det en vanskelig oppgave å endre databaseskjemaet. Du må sørge for at det gamle og det nye skjemaet er kompatible, deretter kan du oppdatere databasen og deretter oppdatere selve applikasjonene. Du kan hot-swap databasen og deretter oppdatere applikasjonene. Jeg vet om folk som har startet opp en helt ny databaseklynge med et nytt skjema, dette er et alternativ hvis du har en systemløs database som Mongo, men det er uansett ikke en lett oppgave. Hvis du ikke har flere spørsmål, takk for oppmerksomheten!
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com