Hej, jag heter Dmitry Krasnov. I mer än fem år har jag administrerat Kubernetes-kluster och byggt komplexa mikrotjänstarkitekturer. I början av detta år lanserade vi en tjänst för att hantera Kubernetes-kluster baserad på Containerum. Med detta tillfälle kommer jag att berätta vad Kubernetes är och hur integration med en leverantör skiljer sig från öppen källkod.
Till att börja med, vad är . Detta är ett system för att hantera containrar på ett stort antal värdar. Från grekiska, förresten, översätts det som "pilot" eller "rorsman". Ursprungligen utvecklad av Google och sedan donerad som ett teknikbidrag till Cloud Native Computing Foundation, en internationell ideell organisation som samlar världens ledande utvecklare, slutanvändare och leverantörer av containerteknik.
Hantera ett stort antal containrar
Låt oss nu ta reda på vilken typ av behållare det här är. Detta är en applikation med hela sin miljö - främst de bibliotek som programmet är beroende av. Allt detta paketeras i arkiv och presenteras i form av en bild som kan köras oavsett operativsystem, testas med mera. Men det finns ett problem - att hantera containrar på ett stort antal värdar är mycket svårt. Det är därför Kubernetes skapades.
En behållarbild representerar ett program plus dess beroenden. Applikationen, dess beroenden och OS-filsystembilden finns i olika delar av bilden, så kallade lager. Skikten kan återanvändas för olika behållare. Till exempel kan alla applikationer i ett företag använda Ubuntu-basskiktet. När du kör behållare finns det inget behov av att lagra flera kopior av ett enda baslager på värden. Detta gör att du kan optimera bildlagring och leverans.
När vi vill köra en applikation från en behållare överlagras de nödvändiga lagren på varandra och ett överläggsfilsystem bildas. Ett inspelningsskikt placeras ovanpå, som tas bort när behållaren stannar. Detta säkerställer att när behållaren körs kommer applikationen alltid att ha samma miljö, som inte kan ändras. Detta garanterar reproducerbarhet av miljön på olika värdoperativsystem. Oavsett om det är Ubuntu eller CentOS kommer miljön alltid att vara densamma. Dessutom är behållaren isolerad från värden med hjälp av mekanismer inbyggda i Linux-kärnan. Applikationer i en behållare ser inte filer, processer för värden och närliggande behållare. Denna isolering av applikationer från värdoperativsystemet ger ett extra lager av säkerhet.
Det finns många tillgängliga verktyg för att hantera behållare på en värd. Den mest populära av dem är Docker. Det låter dig tillhandahålla behållarnas hela livscykel. Det fungerar dock bara på en värd. Om du behöver hantera containrar över flera värdar kan Docker göra livet till ett helvete för ingenjörer. Det är därför Kubernetes skapades.
Efterfrågan på Kubernetes beror just på möjligheten att hantera grupper av behållare på flera värdar som någon form av enstaka enhet. Systemets popularitet ger möjlighet att bygga DevOps eller Development Operations, där Kubernetes används för att köra processerna för just denna DevOps.
Figur 1. Schematisk representation av hur Kubernetes fungerar
Full automatisering
DevOps är i grunden automatiseringen av utvecklingsprocessen. Grovt sett skriver utvecklare kod som laddas upp till förvaret. Sedan kan denna kod automatiskt samlas in omedelbart i en container med alla bibliotek, testas och "rullas ut" till nästa steg - Staging, och sedan direkt till produktion.
Tillsammans med Kubernetes låter DevOps dig automatisera denna process så att den sker med praktiskt taget inget deltagande från utvecklarna själva. På grund av detta är bygget betydligt snabbare, eftersom utvecklaren inte behöver göra detta på sin dator - han skriver helt enkelt en bit kod, skjuter koden till förvaret, varefter pipelinen startas, vilket kan inkludera processen att bygga, testa och rulla ut. Och detta händer med varje commit, så testning sker kontinuerligt.
Samtidigt kan du genom att använda en behållare vara säker på att hela miljön för detta program kommer att släppas i produktion exakt i den form som den testades. Det vill säga, det kommer inte att finnas några problem som "det fanns vissa versioner i testet, andra i produktion, men när vi installerade dem föll allt." Och eftersom vi idag har en trend mot mikrotjänstarkitektur, när det istället för en enorm applikation finns hundratals små, för att kunna administrera dem manuellt, kommer det att krävas en enorm personalstyrka. Det är därför vi använder Kubernetes.
Proffs, proffs, proffs
Om vi pratar om fördelarna med Kubernetes som plattform, så har det betydande fördelar ur synvinkeln att hantera en mikrotjänstarkitektur.
- Hantera flera repliker. Det viktigaste är att hantera containrar över flera värdar. Ännu viktigare, hantera flera applikationsrepliker i behållare som en enda enhet. Tack vare detta behöver ingenjörerna oroa sig för varje enskild container. Om en av behållarna kraschar kommer Kubernetes att se detta och starta om det igen.
- Klusternätverk. Kubernetes har även ett så kallat klusternätverk med eget adressutrymme. Tack vare detta har varje pod sin egen adress. En subpod förstås som den minsta strukturella enheten i ett kluster i vilket containrar sjösätts direkt. Dessutom har Kubernetes funktionalitet som kombinerar en lastbalanserare och Service Discovery. Detta gör att du kan bli av med manuell IP-adresshantering och delegera denna uppgift till Kubernetes. Och automatiska hälsokontroller hjälper till att upptäcka problem och omdirigera trafik till fungerande pods.
- Konfigurationshantering. När du hanterar ett stort antal applikationer blir det svårt att hantera applikationskonfigurationen. För detta ändamål har Kubernetes speciella ConfigMap-resurser. De låter dig lagra konfigurationer centralt och exponera dem för pods när du kör applikationer. Denna mekanism tillåter oss att garantera konsistensen av konfigurationen i minst tio eller hundra applikationsrepliker.
- Beständiga volymer. Behållare är i sig oföränderliga och när behållaren stoppas kommer all data som skrivs till filsystemet att förstöras. Men vissa applikationer lagrar data direkt på disken. För att lösa detta problem har Kubernetes en disklagringshanteringsfunktion - Persistent Volumes. Denna mekanism använder extern lagring för data och kan överföra beständig lagring, block eller fil, till behållare. Denna lösning låter dig lagra data separat från arbetare, vilket sparar dem om samma arbetare går sönder.
- Lastbalanserare. Även om vi i Kubernetes hanterar abstrakta enheter som Deployment, StatefulSet, etc., körs i slutändan behållare på vanliga virtuella maskiner eller hårdvaruservrar. De är inte perfekta och kan falla när som helst. Kubernetes kommer att se detta och omdirigera intern trafik till andra repliker. Men vad ska man göra med trafik som kommer utifrån? Om du helt enkelt dirigerar trafik till en av arbetarna, om den kraschar, blir tjänsten otillgänglig. För att lösa detta problem har Kubernetes tjänster som Load Balancer. De är utformade för att automatiskt konfigurera en extern molnbalanserare för alla arbetare i klustret. Denna externa balanserare dirigerar extern trafik till arbetare och övervakar själv deras status. Om en eller flera arbetare blir otillgängliga omdirigeras trafiken till andra. Detta gör att du kan skapa högt tillgängliga tjänster med Kubernetes.
Kubernetes fungerar bäst när du kör mikrotjänstarkitekturer. Det är möjligt att implementera systemet i klassisk arkitektur, men det är meningslöst. Om ett program inte kan köras på flera repliker, vad gör det då för skillnad - i Kubernetes eller inte?
Kubernetes med öppen källkod
Kubernetes med öppen källkod är en fantastisk sak: jag installerade det och det fungerar. Du kan distribuera det på dina egna hårdvaruservrar, på din egen infrastruktur, installera masters och arbetare som alla applikationer kommer att köras på. Och viktigast av allt, allt detta är gratis. Det finns dock nyanser.
- Det första är kravet på kunskap och erfarenhet från administratörer och ingenjörer som kommer att distribuera och stödja allt detta. Eftersom klienten får fullständig handlingsfrihet i klustret ansvarar han själv för klustrets prestation. Och det är väldigt lätt att bryta allt här.
- Det andra är bristen på integrationer. Om du kör Kubernetes utan en populär virtualiseringsplattform får du inte alla fördelar med programmet. Såsom att använda tjänsterna Persistent Volumes och Load balancer.
Figur 2. k8s arkitektur
Kubernetes från leverantören
Integration med en molnleverantör ger två alternativ:
- För det första kan en person helt enkelt klicka på knappen "skapa kluster" och få ett kluster redan konfigurerat och klart för användning.
- För det andra installerar leverantören själv klustret och sätter upp integration med molnet.
Hur det går till här. Ingenjören som startar klustret anger hur många arbetare han behöver och med vilka parametrar (till exempel 5 arbetare, var och en med 10 processorer, 16 GB RAM och säg 100 GB disk). Därefter får den tillgång till det redan bildade klustret. I det här fallet överförs arbetarna på vilka lasten startas helt till kunden, men hela förvaltningsplanet förblir under leverantörens ansvar (om tjänsten tillhandahålls enligt den hanterade tjänstemodellen).
Detta system har dock sina nackdelar. På grund av att hanteringsplanet förblir hos leverantören ger leverantören inte full åtkomst till klienten, och detta minskar flexibiliteten i arbetet med Kubernetes. Ibland händer det att en klient vill lägga till någon specifik funktionalitet till Kubernetes, till exempel autentisering via LDAP, men konfigurationen av hanteringsplanet tillåter inte detta.
Figur 3. Exempel på ett Kubernetes-kluster från en molnleverantör
Vad du ska välja: öppen källkod eller leverantör
Så, är Kubernetes öppen källkod eller leverantörsspecifik? Om vi tar öppen källkod Kubernetes, då gör användaren vad han vill med den. Men det finns en stor chans att skjuta sig själv i foten. Med leverantören är det svårare, eftersom allt är genomtänkt och konfigurerat för företaget. Den största nackdelen med öppen källkod Kubernetes är kravet på specialister. Med ett säljaralternativ är företaget befriat från denna huvudvärk, men det måste besluta om det ska betala sina specialister eller säljaren.
Jo, fördelarna är uppenbara, nackdelarna är också kända. En sak är konstant: Kubernetes löser många problem genom att automatisera hanteringen av många containrar. Och vilken man ska välja, öppen källkod eller leverantör - alla fattar sitt eget beslut.
Artikeln utarbetades av Dmitry Krasnov, ledande arkitekt för Containerum-tjänsten för #CloudMTS-leverantören
Källa: will.com