Jag heter Sergey, jag kommer frÄn företaget ITSumma och jag vill berÀtta för er hur vi nÀrmar oss reservkopiering i Kubernetes. PÄ senare tid har jag arbetat mycket med konsultation kring implementering av olika devops-lösningar för olika team, specifikt inom projekt som anvÀnder K8s. PÄ konferensen Uptime day 4, som handlade om reservkopiering inom komplexa arkitekturer, höll jag en presentation om reservkopiering av "kubik", och hÀr Àr en fri sammanfattning. Jag varnar dock i förvÀg att detta inte Àr en direkt handbok, utan snarare en sammanstÀllning av tankar kring Àmnet.
I princip Àr övervakning och reservkopiering tvÄ grundlÀggande verktyg för att öka driftsÀkerheten i varje projekt. Men i Kubernetes balanseras allt automatiskt, sÀger ni, allt skalas automatiskt, och om nÄgot hÀnder kommer det automatiskt att ÄterstÀllas... Vid en första ytlig undersökning av Àmnet svarade internet pÄ frÄgan om hur olika tillvÀgagÄngssÀtt för reservkopiering i K8s hanteras med "varför?" MÄnga tror att Kubernetes Àr en magisk lösning som befriar en frÄn alla infrastrukturella problem och ser till att projektet aldrig faller. Men ... vÀrlden Àr inte vad den ser ut att vara.
Hur nÀrmade vi oss reservkopieringsprocessen tidigare? Vi hade identiska plattformar för hosting - antingen virtuella maskiner eller fysiska servrar, servrar, som vi tillÀmpade tre grundlÀggande metoder pÄ:
- kod- och statiksynkronisering
- konfigurationssynkronisering
- databasÄtervinning
Och voilà : nÀr som helst kan vi byta över till en reservplattform, alla Àr glada, vi reser oss och gÄr.
Vad erbjuder vi för att öka den permanenta tillgĂ„ngen till vĂ„r Kubernetes-applikation? Det första som den inofficiella dokumentationen nĂ€mner Ă€r att installera mĂ„nga maskiner, göra mĂ„nga master-noder â antalet mĂ„ste uppfylla kraven för att uppnĂ„ quorum inom klustret, och att varje master-nod ska köra etcd, API, MC, schemalĂ€ggare... Och allt verkar fantastiskt: om flera arbetande noder eller master-noder gĂ„r sönder, kommer vĂ„rt kluster att ombalanseras och applikationen kommer att fortsĂ€tta att fungera. Det ser Ă„terigen ut som magi! Men ofta befinner sig vĂ„rt kluster inom en enda datacenter och detta kan orsaka vissa frĂ„gor. Vad hĂ€nder om en grĂ€vmaskin grĂ€ver upp en kabel, blixten slĂ„r ner, eller en universell översvĂ€mning intrĂ€ffar? Allt Ă€r förstört, vĂ„rt kluster finns inte lĂ€ngre. Hur ska vi hantera redundans med tanke pĂ„ denna sida av problemet?
Först och frÀmst mÄste ni ha ett annat kluster som Àr i varm reserv, det vill sÀga ett kluster som ni kan vÀxla över till nÀr som helst. Ur Kubernetes-perspektiv mÄste infrastrukturen vara helt identisk. Om det finns nÄgra icke-standardiserade plugins för filsystemet, anpassade lösningar för ingress, mÄste de vara helt identiska pÄ era tvÄ (eller tre, eller tio, beroende pÄ hur mycket pengar och administratörernas tid ni har) kluster. Det Àr nödvÀndigt att tydligt definiera tvÄ uppsÀttningar applikationer (deployment, statefulsets, daemonsets, cronjobs etc.): vilka av dem kan vara aktiva i reservkontot hela tiden och vilka Àr bÀttre att inte starta förrÀn vid omkopplingen.
SÄ, ska vÄrt reservkluster vara helt identiskt med vÄrt produktionskluster? Nej. Tidigare, nÀr vi arbetade med monolitiska projekt och hÄrdvaruinfrastruktur, höll vi nÀstan helt identiska miljöer, men inom Kubernetes, anser jag, ska detta inte vara fallet. LÄt oss titta pÄ varför.
Till exempel, lĂ„t oss börja med de grundlĂ€ggande enheterna i Kubernetes â deployments â de mĂ„ste vara identiska. Applikationer mĂ„ste vara aktiva och kunna hantera trafikflödet nĂ€r som helst, sĂ„ att vĂ„rt projekt fortsĂ€tter att fungera. Om vi pratar om konfigurationsfiler, mĂ„ste vi avgöra om de bör vara identiska eller inte. Det vill sĂ€ga, om vi, kloka mĂ€nniskor, inte anvĂ€nder nĂ„gra olagliga substanser och inte har databasen i K8s, ska vi i configmaps ha Ă„tkomstinstĂ€llningar till den produktiva databasen (processen för att sĂ€kerhetskopiera den Ă€r byggd separat). DĂ€rför, för att sĂ€kerstĂ€lla Ă„tkomst till den reservdatabasen, mĂ„ste vi ha en separat konfigurationsfil (configmap). Precis pĂ„ samma sĂ€tt arbetar vi med secrets: lösenord för databasinloggning, API-nycklar; vid varje tidpunkt kan vi antingen ha den aktiva secret eller den reserv. SĂ„ledes har vi redan tvĂ„ Kubernetes-enheter vars reservversioner inte bör vara identiska med de aktiva. NĂ€sta enhet vi ska fokusera pĂ„ Ă€r cronjob. Cronjob pĂ„ reserven fĂ„r under inga omstĂ€ndigheter vara identiska med uppsĂ€ttningen av cronjob i produktionsklustret! Om vi startar reservklustret och aktiverar alla cronjob â kommer mĂ€nniskor till exempel att fĂ„ tvĂ„ e-postmeddelanden samtidigt istĂ€llet för ett. Eller sĂ„ kommer nĂ„gon datasintegrering med externa kĂ€llor att ske tvĂ„ gĂ„nger, vilket gör att vi börjar mĂ„ dĂ„ligt, grĂ„ta, skrika och klaga.
Och hur föreslĂ„r folk pĂ„ internet att organisera en reservkluster? Det nĂ€st mest populĂ€ra svaret efter "varför?" â anvĂ€ndning av Kubernetes Federation.
Vad Ă€r det hĂ€r? Det Ă€r, lĂ„t oss sĂ€ga, en stor meta-kluster. Om vi förestĂ€ller oss Kubernetes-arkitekturen â dĂ€r vi har en master och flera noder â sĂ„ har vi ur federationssynpunkt ocksĂ„ en master och flera noder, men varje nod Ă€r en separat kluster. Det betyder att vi arbetar med samma entiteter, med samma primitiva som med en enskild Kubernetes, men vi hanterar inte vĂ„ra fysiska maskiner utan hela kluster. Inom federationen sker det en fullstĂ€ndig synkronisering av federerade resurser frĂ„n förĂ€ldrar till avkommor. Till exempel, om vi har lanserat en deployment via federation â sĂ„ kommer den att deployeras pĂ„ varje av vĂ„ra underkluster. Om vi tar en configmap eller en hemlighet och distribuerar den via federation â sĂ„ kommer den att spridas över alla vĂ„ra underkluster; samtidigt tillĂ„ter federation oss att anpassa vĂ„ra resurser pĂ„ barnen. Det vill sĂ€ga, vi tog en configmap, deployerade den via federation och sedan, om vi behöver justera nĂ„got pĂ„ specifika kluster, gĂ„r vi och justerar pĂ„ det specifika klustret, och den Ă€ndringen kommer inte att synkroniseras nĂ„gonstans.
Kubernetes Federation Ă€r ett relativt nytt verktyg och det stöder inte hela uppsĂ€ttningen av resurser som K8s sjĂ€lv erbjuder: vid publiceringen av en av de första versionerna av dokumentationen nĂ€mndes endast stöd för config maps, deployment under replica set och ingress. Hemligheter stöddes inte, och arbete med volymer stöddes inte heller. Det Ă€r en för begrĂ€nsad uppsĂ€ttning. SĂ€rskilt om vi gillar att experimentera â till exempel genom att anvĂ€nda custom resource definition för att överföra egna resurser till Kubernetes â kan vi inte stoppa dem i federationen. SĂ„ det Ă€r som⊠en lösning som Ă€r ganska nĂ€ra sanningen, men som ibland fĂ„r oss att skjuta oss sjĂ€lva i foten. Ă andra sidan tillĂ„ter federation att vi flexibelt kan hantera vĂ„r replicaset. Till exempel vill vi ha 10 repliker av vĂ„r applikation igĂ„ng, och federation kommer automatiskt att fördela detta antal proportionellt mellan antalet kluster. Och allt detta gĂ„r att konfigurera! Vi kan ange att pĂ„ produktionsklustret behöver vi hĂ„lla 6 repliker av vĂ„r applikation, medan pĂ„ reservklustret, för att spara resurser, eller för egna nöjen â bara 4 repliker av vĂ„r applikation. Det Ă€r ocksĂ„ ganska praktiskt. Men med federation mĂ„ste vi anvĂ€nda nĂ„gon form av nya lösningar, deploya saker under loppet och fĂ„ oss sjĂ€lva att tĂ€nka lite merâŠ
Finns det ett enklare sÀtt att nÀrma sig kubernetes reservering? Vilka verktyg har vi överhuvudtaget?
För det första har vi alltid nÄgot slags ci/cd-system, det vill sÀga vi gÄr inte manuellt in och skriver create/apply pÄ servrarna. Systemet genererar yaml-filer för vÄra containrar.
För det andra har vi flera kluster, vi har antingen ett eller flera (om vi Àr kloka) registry som vi ocksÄ har tagit och reserverat. Och det finns ett fantastiskt verktyg, kubectl, som kan arbeta med flera kluster samtidigt.
SÄ hÀr Àr det: enligt min Äsikt Àr den enklaste och mest korrekta lösningen för att bygga en backupkluster en primitiv parallell distribution. Det finns nÄgon pipeline i ci/cd-systemet; först bygger vi vÄra containrar, testar och distribuerar applikationerna via kubectl till flera oberoende kluster. Vi kan göra samtidigt distributioner pÄ flera kluster. DÀrmed hanterar vi Àven leveransen av konfigurationer i detta steg. Vi kan i förvÀg definiera en uppsÀttning konfigurationer för vÄrt produktionskluster, en uppsÀttning konfigurationer för backupklustret och pÄ ci/cd-systemnivÄ distribuera produktionsmiljön till produktionsklustret, backupmiljön till backupklustret. JÀmfört med federationen behöver vi inte gÄ till varje underkluster efter att ha definierat den federativa resursen och Àndra nÄgot. Vi har gjort detta i förvÀg. Vad duktiga vi Àr.
Men⊠det finns⊠jag har skrivit att det finns "alla problemens rot", men det finns faktiskt tvÄ av dem. För det första, filsystemet. Det finns nÄgot PV, eller sÄ anvÀnder vi extern lagring. Om vi lagrar filer inom klustret mÄste vi agera enligt de gamla metoderna, som hÀrstammar frÄn hÄrdvaruinfrastrukturer: till exempel synkronisera med lsync. Antingen det eller nÄgon annan metod som du personligen föredrar. Vi distribuerar allt till andra maskiner och fortsÀtter.
För det andra, och faktiskt ett mer kritiskt bekymmer â databasen. Om vi Ă€r kloka mĂ€nniskor och inte har databasen i Kubernetes, sĂ„ Ă€r processen för datareservering enligt den gamla modellen â master-slave-replikering, sedan omstĂ€llning, vi kommer att hĂ€mta replikatet och leva gott. Men om vi hĂ„ller vĂ„r databas inom klustret finns det faktiskt mĂ„nga fĂ€rdiga lösningar för att organisera samma master-slave-replikation, mĂ„nga lösningar för att konfigurera en databas inom Kubernetes.
Om databassÀkring har det redan hÄllits miljarder presentationer, skrivits miljarder artiklar, det finns inget nytt hÀr, för att vara Àrlig. Sammanfattningsvis, följ dina drömmar, lev som du vill, uppfinna nÄgra komplexa lösningar för dig sjÀlv, men tÀnk definitivt pÄ hur du kommer att sÀkra allt detta.
Och nu om hur vi i princip kommer att genomföra processen för att vĂ€xla till en reservanlĂ€ggning i hĂ€ndelse av en brand. För det första distribuerar vi stateless-applikationer parallellt. De pĂ„verkar inte affĂ€rslogiken för vĂ„ra applikationer, vĂ„rt projekt. Vi kan hela tiden ha tvĂ„ uppsĂ€ttningar av körande applikationer, och de kan börja ta emot trafik. Det Ă€r mycket viktigt i processen att vĂ€xla till reservanlĂ€ggningen att alltid kolla â behöver vi omdefiniera konfigurationerna? Till exempel har vi en produktionskluster av Kubernetes, en reservkluster av Kubernetes, en extern masterdatabas och en reserv masterdatabas. Vi har fyra alternativ för hur dessa applikationer i produktion kan börja interagera med varandra. Vi kan vĂ€xla databasen, vilket innebĂ€r att vi behöver styra om trafiken i produktionsklustret till den nya databasen, eller sĂ„ kan klustret fallera â och vi har flyttat till reserv men fortsĂ€tter att arbeta med produktionsdatabasen. Den tredje varianten Ă€r nĂ€r vi har haft problem med det ena och det andra, och vi vĂ€xlar bĂ„da applikationerna, omdefinierar vĂ„r konfiguration sĂ„ att de nya applikationerna redan arbetar med den nya databasen.
Och vilka slutsatser kan vi dra av allt detta?
Första slutsats: Det Ă€r bra att ha en reserv. Men det Ă€r dyrt. Men i idealfallet bör man inte bara ha en reserv. Man bör i sjĂ€lva verket ha flera reserver. För det första bör reservet vara minst inte i en och samma datacenter, och för det andra, minst hos en annan hostingleverantör. Det har ofta hĂ€nt â och det har jag faktiskt varit med om. TyvĂ€rr kan jag inte nĂ€mna nĂ„gra projekt, sĂ€rskilt nĂ€r det intrĂ€ffade en brand i datacentret... Jag tĂ€nkte: vi vĂ€xlar till reserv! Och de reservservrarna stod i samma rack...
Eller tĂ€nk dig att Amazon blir förbjudet i Ryssland (och det har hĂ€nt). Och allt: vad hjĂ€lper det att vĂ„r reserv ligger hos en annan Amazon? Den Ă€r ocksĂ„ otillgĂ€nglig. SĂ„ jag upprepar: vi bör hĂ„lla reserv, minst i ett annat datacenter, och helst â hos en annan hostingleverantör.
Andra output: Om du har en app i Kubernetes som kommunicerar med externa kÀllor (det kan vara bÄde en databas eller en extern API), definiera den som en tjÀnst med en extern Endpoint, sÄ att ni inte behöver deploya 15 av era appar som ansluter till samma databas vid byte. Definiera databasen som en separat tjÀnst, anslut till den som om den vore inom klustret: om er databas krashar kan ni Àndra ip pÄ ett stÀlle och fortsÀtta att leva lyckligt.
Och till sist: Jag Àlskar "kubik", precis som jag Àlskar att experimentera med det. Jag gillar ocksÄ att dela resultaten av dessa experiment och min personliga erfarenhet. DÀrför har jag spelat in en serie webbinarier om K8s, vÀlkommen till för mer information.
KĂ€lla: habr.com
