Jeg heter Sergej, jeg er fra selskapet ITSumma, og jeg vil fortelle deg hvordan vi nÊrmer oss reservasjon i Kubernetes. I det siste har jeg vÊrt mye involvert i rÄdgivning knyttet til implementering av forskjellige devops-lÞsninger for ulike team, og jeg jobber spesielt med prosjekter som bruker K8s. PÄ konferansen Uptime day 4, som var dedikert til reservasjon i komplekse arkitekturer, holdt jeg en presentasjon om reservasjon av 'kuben', og her er en fri gjengivelse av den. Jeg vil bare pÄ forhÄnd advare om at det ikke er en direkte hÄndbok til handling, men snarere en oppsummering av tanker om det aktuelle temaet.
I prinsippet er overvÄking og reservasjon de to hovedverktÞyene for Ä Þke feiltoleransen til ethvert prosjekt. Men, men i Kubernetes balanseres alt automatisk, vil du si, alt skaleres automatisk, og hvis noe skjer, vil det vil lÞfte seg selv... SÄ ved fÞrste overfladiske undersÞkelse av temaet, svarte internett meg pÄ spÞrsmÄlet om hvordan folk nÊrmer seg reservasjon i K8s, med 'hvorfor?' Mange tror at Kubernetes er en magisk ting som lÞser alle infrastrukturproblemer og sÞrger for at prosjektet aldri vil falle. Men... verden er ikke slik den ser ut.
Hvordan nĂŠrmet vi oss reservasjonsprosessen tidligere? Vi hadde identiske plattformer for hosting - enten virtuelle maskiner eller fysiske servere, servere, der vi brukte tre grunnleggende praksiser:
- kode- og statisk synkronisering
- konfigurasjonssynkronisering
- replikering av databaser
Og vips: i hvilket som helst Þyeblikk kan vi bytte over til reservelÞsningen, alle er lykkelige, vi reiser oss og gÄr.
Hva tilbyr vi for Ă„ Ăžke den kontinuerlige tilgjengeligheten av Kubernetes-applikasjonen vĂ„r? Det fĂžrste som ikke-offisiell dokumentasjon nevner, er Ă„ sette opp mange maskiner, lage mange mestre â antallet mĂ„ oppfylle kravene for Ă„ oppnĂ„ quorum innen klyngen, og pĂ„ hver av de mesterne mĂ„ etcd, API, MC, scheduler osv. vĂŠre oppe. Og det ser egentlig flott ut: nĂ„r flere arbeidsnoder eller mestre svikter, vil klyngen vĂ„r ombalanseres, og applikasjonen fortsetter Ă„ fungere. Det ser igjen ut som magi! Men ofte befinner klyngen vĂ„r seg innenfor ett datasenter, noe som kan reise visse spĂžrsmĂ„l. Hva skjer hvis en gravemaskin kommer og graver opp en kabel, om lynet slĂ„r ned, eller om det skjer en stor oversvĂžmmelse? Alt gĂ„r tapt, klyngen vĂ„r er ikke lenger der. Hvordan nĂŠrme seg reserven med denne siden av problemet i tankene?
Fremfor alt mĂ„ du ha en annen klynge i varm reserve, det vil si en klynge som du kan bytte til nĂ„r som helst. Fra Kuber-standpunktet mĂ„ infrastrukturen vĂŠre helt identisk. SĂ„ hvis det finnes noen ikke-standard plugins for filsystemet, tilpassede lĂžsninger for ingress, mĂ„ de vĂŠre helt identiske pĂ„ de to (eller tre, eller ti, alt etter hvor mye penger og krefter administratorene har) klusterne dine. Du mĂ„ tydelig definere to sett med applikasjoner (deploymentâer, statefulsets, daemonsets, cronjobs osv.): hvilke av dem kan kjĂžre pĂ„ reserven konstant, og hvilke er bedre Ă„ ikke starte fĂžr det skjer en faktisk omkobling.
BÞr vÄr reserveklynge vÊre helt identisk med vÄr produksjonsklynge? Nei. Tidligere, i arbeidet med monolittiske prosjekter og fysisk infrastruktur, holdt vi praktisk talt et helt identisk miljÞ, men i Kubernetes synes jeg ikke dette er nÞdvendig. La oss se pÄ hvorfor.
For example, let's start with the basic entities of Kubernetes â deployments â which should be identical. Applications must be running that can intercept traffic processing at any moment and allow our project to continue functioning. When it comes to configuration files, we need to assess whether they should be identical or not. In other words, if we, sensible people, do not use any prohibited substances and do not keep the database in K8s, then our configmaps should contain access settings for the production database (the backup process of which is built separately). Accordingly, to ensure access to the backup database instance, we need to have a separate configuration file (configmap). We work in the same way with secrets: passwords for database access, API keys; at any given moment, we can either have a production secret or a backup one. Thus, we already have two Kubernetes entities whose backup versions should not be identical to the production ones. The next entity worth stopping at is cronjob. Backup cronjobs must not be identical to the set of cronjobs in the production cluster! If we deploy a backup cluster and spin it up completely with all cronjobs enabled, for example, people will receive two emails from you simultaneously instead of one. Or some data synchronization with external sources will happen twice, and as a result, we start to get sick, cry, scream, and get angry.
So how do people from the internet suggest we organize the backup cluster? The second most popular answer after 'why bother?' is the use of Kubernetes Federation.
Hva er dette? Det er, la oss si, en stor meta-klynge. Hvis vi forestiller oss arkitekturen av Kubernetes â der vi har en master og flere noder â sĂ„ har vi, nĂ„r det gjelder federasjon, ogsĂ„ en master og flere noder, men hver node er en egen klynge. Det betyr at vi jobber med de samme enhetene, de samme primitivene, som med en enkelt Kubernetes, bare at vi roterer ikke med vĂ„re fysiske maskiner, men med hele klynger. I forbundsrammen skjer det full synkronisering av fĂžderale ressurser fra foreldre til avkom. For eksempel, hvis vi har initiert en distribusjon gjennom federasjonen â vil den bli distribuert til hver av vĂ„re underklynger. Hvis vi tar en hvilken som helst configmap, hemmelighet, og distribuerer den gjennom federasjonen â vil den spre seg til alle vĂ„re underklynger; samtidig tillater federasjonen Ă„ tilpasse vĂ„re ressurser pĂ„ barna. Det vil si at vi tok en hvilken som helst configmap, distribuerte den gjennom federasjonen, og deretter, hvis vi trenger Ă„ justere noe pĂ„ spesifikke klynger, gĂ„r vi for Ă„ redigere pĂ„ den spesifikke klyngen, og denne endringen vil ikke bli synkronisert noe sted.
Kubernetes Federation â et verktĂžy som ikke har eksistert sĂ„ lenge, og som ikke stĂžtter hele spekteret av ressurser som K8s tilbyr: i en av de fĂžrste dokumentasjonsversjonene, ble det nevnt stĂžtte kun for config maps, deployering av en replica-set og ingress. Hemmeligheter ble ikke stĂžttet, og arbeid med volume ble heller ikke stĂžttet. Et altfor begrenset sett av verktĂžy. Spesielt hvis vi liker Ă„ eksperimentere â for eksempel Ă„ sende vĂ„re egne ressurser til Kubernetes gjennom custom resource definition â kan vi ikke fylle dem inn i federasjonen. SĂ„ det er pĂ„ en mĂ„te⊠en lĂžsning som ligner pĂ„ sannheten, men som fĂ„r oss til Ă„ skyte oss selv i foten periodisk. PĂ„ den annen side lar federasjonen oss administrere vĂ„r replicaset fleksibelt. For eksempel, hvis vi Ăžnsker at 10 kopier av applikasjonen vĂ„r skal kjĂžre, vil federasjonen som standard dele dette tallet proporsjonalt mellom antallet klynger. Og dette kan faktisk konfigureres! Vi kan spesifisere at det aktive klyngen skal ha 6 kopier av applikasjonen vĂ„r, mens i den reserveklyngen, for Ă„ spare ressurser eller for egne eksperimenter â bare 4 kopier av applikasjonen vĂ„r. Det er ogsĂ„ ganske praktisk. Men med federasjonen mĂ„ vi bruke noen nye lĂžsninger, deploye noe underveis og tvinge oss selv til Ă„ tenke litt mer...
Er det mulig Ä nÊrme seg prosessen med Ä reservere kubernetes pÄ en enklere mÄte? Hvilke verktÞy har vi tilgjengelig?
For det fÞrste har vi alltid et slags ci/cd-system, det vil si vi gÄr ikke manuelt inn og skriver create/apply pÄ servere. Systemet genererer yaml-filer for containerne vÄre.
For det andre finnes det flere klynger, vi har enten en eller flere (hvis vi er smarte) registre, som vi ogsÄ har reservert. Og vi har det fantastiske verktÞyet kubectl, som kan jobbe med flere klynger samtidig.
SÄnn sett mener jeg at den enkleste og mest korrekte lÞsningen for Ä bygge et sikkerhetskluster, er en primitiv parallell distribusjon. Det finnes et eller annet pipeline i CI/CD-systemet; fÞrst bygger vi containerne vÄre, tester dem og ruller ut applikasjonene via kubectl pÄ flere uavhengige klynger. Vi kan lage samtidige utrullinger pÄ flere klynger. FÞlgelig lÞser vi ogsÄ leveringen av konfigurasjoner pÄ dette trinnet. Vi kan pÄ forhÄnd definere et sett med konfigurasjoner for vÄr produksjonsklynge og et sett med konfigurasjoner for sikkerhetsklyngen, og pÄ CI/CD-nivÄ rulle ut produksjonsmiljÞet i produksjonsklyngen og sikkerhetsmiljÞet i sikkerhetsklyngen. Sammenlignet med en fÞderasjon trenger vi ikke Ä gÄ til hver underklynge etter Ä ha definert den fÞdererte ressursen for Ä overstyrke noe. Vi har gjort dette pÄ forhÄnd. For et bra stykke arbeid.
Men... det er... jeg skulle ha skrevet at det finnes "roten til alt ondt", men det er faktisk to. For det fÞrste, filsystemet. Det finnes en eller annen PV, eller vi bruker ekstern lagring. Hvis vi lagrer filer inne i klyngen, mÄ vi fÞlge de gamle praksisene fra tidene med maskinvareinfrastruktur: for eksempel synkronisere med lsync. Eller med en annen personlig foretrukket kronglete lÞsning. Vi ruller ut alt til andre maskiner og lever videre.
For det andre, og faktisk et enda mer viktig hinder, er databasen. Hvis vi er smarte mennesker og ikke holder databasen i Kubernetes, sĂ„ er prosessen med Ă„ sikre data pĂ„ den gamle mĂ„ten â master-slave replikasjon, sĂ„ bytter vi, og vi skal fĂ„ replikatet oppdatert og leve godt. Men hvis vi holder databasen vĂ„r inne i klyngen, finnes det i prinsippet mange klare lĂžsninger for Ă„ organisere samme master-slave replikasjon, mange lĂžsninger for Ă„ sette opp databasen inne i Kubernetes.
Det er allerede skrevet milliarder av foredrag og artikler om databaseregistrering; det er egentlig ikke noe nytt her. Generelt, fĂžlg drĂžmmene deres, lev som dere vil, oppfinn deres egne kompliserte lĂžsninger, men tenk nĂžye gjennom hvordan dere vil gjĂžre sikkerhetskopieringen.
NĂ„, la oss nĂ„ se pĂ„ hvordan prosessen med Ă„ bytte til en reservelĂžsning vil foregĂ„ i tilfelle brann. FĂžrst og fremst distribuerer vi stateless-applikasjoner parallelt. De pĂ„virker ikke forretningslogikken i applikasjonene vĂ„re, prosjektet vĂ„rt. Vi kan alltid ha to sett med kjĂžrende applikasjoner, og de kan begynne Ă„ motta trafikk. Det er veldig viktig under overgangen til reservelĂžsningen Ă„ sjekke om konfigurasjonene mĂ„ overstyres. For eksempel har vi en produksjonsklynge i Kubernetes, en reservklynge i Kubernetes, en ekstern masterdatabase og en reservmasterdatabase. Vi har fire alternativer for hvordan disse applikasjonene i produksjonen kan begynne Ă„ samhandle. Vi kan fĂ„ en database til Ă„ svikte, og da mĂ„ vi omdirigere trafikken i produksjonsklyngen til den nye databasen, eller vi kan ha en klynge som svikter â og vi har gĂ„tt over til reservelĂžsningen, men fortsetter Ă„ jobbe med produksjonsdatabasen. Det tredje alternativet er nĂ„r begge systemene svikter, og vi mĂ„ omdirigere begge applikasjonene og overstyre konfigurasjonen vĂ„r slik at de nye applikasjonene jobber med den nye databasen.
SĂ„, hva kan vi konkludere fra alt dette?
FĂžrste konklusjon: det er bra Ă„ ha reservelĂžsning. Men det er dyrt. Ideelt sett bĂžr man ikke ha bare Ă©n reservelĂžsning. Man bĂžr i realiteten ha flere reservelĂžsninger. For det fĂžrste, reservelĂžsningen bĂžr vĂŠre minst i to forskjellige datasentre, og for det andre, helst hos en annen leverandĂžr. Dette har ofte skjedd â og i min erfaring har det vĂŠrt tilfeller. Jeg kan dessverre ikke navngi prosjekter, spesielt da det brant i et datasenter... Jeg tenkte: nĂ„ bytter vi til reservelĂžsning! Men de reserverte serverne sto i samme rack...
Eller tenk deg at Amazon blir sensurert i Russland (og det har skjedd). Og alt er Ăždelagt: hva nyttig er det at reserven vĂ„r ligger et annet sted hos Amazon? Det er ikke tilgjengelig heller. SĂ„ la meg gjenta: hold reserve, minst i et annet datasenter, og helst â hos en annen leverandĂžr.
Den andre anbefalingen: hvis du har en applikasjon i Kubernetes som kommuniserer med eksterne kilder (det kan vÊre bÄde en database og et eksternt API), bÞr du absolutt definere det som en tjeneste med en ekstern endpoint, slik at du ikke mÄ omdeploere 15 applikasjoner som kontakter den samme databasen nÄr du gjÞr en endring. Definer databasen som en egen tjeneste, og kommuniser med den som om den var internt i klyngen: hvis databasen feiler, kan du endre IP-adressen ett sted og fortsette Ä fungere som fÞr.
Og til slutt: jeg elsker 'kubikk', akkurat som jeg elsker eksperimenter med det. Jeg elsker ogsÄ Ä dele resultatene av disse eksperimentene og min personlige erfaring. Derfor har jeg laget en serie webinarer om K8s, velkommen til for mer informasjon.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish