🥇Kubernetes: open source mot leverantörsspecifik

Hej, jag heter Dmitrij Krasnov. Jag har arbetat med administration av Kubernetes-kluster och byggande av komplexa mikrotjänstarkitekturer i mer än fem år. I början av det här året lanserade vi en tjänst för hantering av Kubernetes-kluster baserad på Containerum. Passa på att berätta vad Kubernetes faktiskt är och hur integrationen med en leverantör skiljer sig från open source.

För det första, vad är Kubernetes. Det är ett system för administration av containrar på ett stort antal värdar. På grekiska översätts det för övrigt som "pilot" eller "styrman". Det utvecklades ursprungligen av Google och överlämnades sedan som en teknologisk bidrag till Cloud Native Computing Foundation, en internationell ideell organisation som förenar ledande globala utvecklare, slutanvändare och leverantörer av containertj teknologi.

Att styra ett stort antal containrar

Nu ska vi reda ut vad dessa containrar är. Det är en applikation med hela dess miljö – i huvudsak bibliotek som applikationen är beroende av för att fungera. Allt detta packas i arkiv och presenteras som en bild som kan köras oavsett operativsystem, testas och mer. Men det finns ett problem — att hantera containrar på ett stort antal värdar är mycket svårt. Därför skapades Kubernetes.

En containerbild representerar en applikation plus dess beroenden. Applikationen, dess beroenden och bildens filsystem ligger i olika delar av bilden, så kallade lager. Lager kan återanvändas för olika containrar. Till exempel kan alla applikationer i företaget använda det grundläggande lagret Ubuntu. Vid körning av containrar behöver man inte lagra många kopior av ett och samma grundläggande lager på värden. Detta möjliggör optimering av lagring och distribution av bilder.

När vi vill starta en applikation från en container, läggs de nödvändiga lagren ovanpå varandra och en overlay-filsystem bildas. Ovanpå detta läggs ett skrivlager, som tas bort när containern stoppas. Detta säkerställer att applikationen alltid har en konsekvent miljö vid start av containern, vilket inte kan ändras. Det garanterar reproducerbarhet av miljön på olika värddatorers operativsystem. Oavsett om det är Ubuntu eller CentOS kommer miljön alltid att vara densamma. Dessutom är containern isolerad från värden med hjälp av inbyggda mekanismer i Linux-kärnan. Applikationer i containern ser inte värdens filer, processer eller andra containrar. Denna isolering av applikationer från värdoperativsystemet ger ett extra lager av säkerhet.

Det finns många verktyg för att hantera containrar på värden. Det mest populära av dessa är Docker. Det möjliggör en fullständig livscykelhantering av containrar. Men det fungerar endast på en enda värd. När det behövs hantering av containrar på flera värdar kan Docker göra livet svårt för ingenjörerna. Därför skapades Kubernetes.

Efterfrågan på Kubernetes beror just på möjligheten att styra grupper av containrar på flera värdar som en enda enhet. Systemets popularitet ger möjligheten att bygga DevOps, där Kubernetes används för att driva processerna i DevOps.

Figur 1. Schematisk bild av hur Kubernetes fungerar

Full automatisering

DevOps, i grunden, representerar automatisering av utvecklingsprocessen. Valt grovt, skriver utvecklarna kod som laddas upp till ett arkiv. Denna kod kan sedan automatiskt byggas direkt i en container med alla bibliotek, testas och "släppas" till nästa steg - Staging, och sedan omedelbart till Production.

Tillsammans med Kubernetes gör DevOps det möjligt att automatisera denna process så att den nästan går utan utvecklarnas deltagande. Detta påskyndar avsevärt byggprocessen, eftersom utvecklaren inte behöver hantera detta på sin dator — han skriver helt enkelt en bit kod, pushar koden till ett repository, varefter en pipeline startas, som kan inkludera processen för byggande, testning och implementering. Så här sker det med varje commit, så testningen sker kontinuerligt.

Genom att använda en container kan man vara säker på att hela miljön för detta program går till produktion i exakt det skick som testades. Det innebär att det inte kommer att uppstå problem av typen "i testet var det en version, i produktion – en annan, och när det installerades – allt kraschade". Eftersom vi idag har en trend mot mikroservicearkitektur, där istället för en stor applikation finns det hundratals små, krävs det en stor personalstyrka för att administrera dem manuellt. Därför använder vi Kubernetes.

Fördelar, fördelar, fördelar

När det gäller fördelarna med Kubernetes som plattform har det betydande fördelar ur ett administrationsperspektiv för mikroservicearkitektur.

Hantering av många repliker. Det viktigaste är att hantera containers på många värdar. Och vad som är ännu viktigare är att hantera många repliker av applikationer i containers som en enhet. Tack vare detta behöver ingenjörer inte oroa sig för varje enskild container. Om en av containrarna kraschar kommer Kubernetes att upptäcka detta och starta om den.
Klusternätverk. Kubernetes har också ett så kallat klusternätverk med sitt eget adressutrymme. Detta gör att varje pod har sin egen adress. En pod är den minimi strukturella enheten i klustret där containrar startas direkt. Dessutom har Kubernetes funktionalitet som kombinerar en lastbalanserare och service discovery. Det här gör att man kan undvika manuell hantering av IP-adresser och överlåta denna uppgift till Kubernetes. Automatiska hälsokontroller hjälper till att upptäcka problem och omdirigera trafik till fungerande pods.
Konfigurationshantering. När man hanterar ett stort antal applikationer blir det svårt att administrera applikationskonfigurationer. För detta ändamål har Kubernetes speciella resurser som ConfigMap. De tillåter centralt lagring av konfigurationer och att dessa kan sättas in i pods vid applikationsstart. Denna mekanism garanterar att konfigurationen är konsekvent, oavsett om det handlar om tio eller hundra repliker av applikationer.
Beständiga volymer. Containrar är i grunden immutabla, och när en container stoppas kommer alla data som skrivits till filsystemet att försvinna. Men vissa applikationer sparar data direkt på disken. För att lösa detta problem har Kubernetes funktionalitet för att hantera disklagring – beständiga volymer. Denna mekanism använder extern lagring för data och kan koppla till containrar permanent lagring, antingen block- eller filbaserad. Sådana lösningar gör att data kan lagras separat från arbetarna, vilket räddar dem vid ett eventuellt fel hos dessa arbetare.
Lastbalanserare. Trots att vi hanterar abstrakta entiteter som Deployment, StatefulSet och så vidare i Kubernetes, så körs containrar i slutändan på vanliga virtuella maskiner eller fysiska servrar. De är inte perfekta och kan krascha när som helst. Kubernetes kommer att se detta och omdirigera intern trafik till andra repliker. Men vad gör vi med trafiken som kommer utifrån? Om vi helt enkelt dirigerar trafiken till en av arbetarna, vad händer om den kraschar? Tjänsten blir otillgänglig. För att lösa detta problem finns det tjänster i Kubernetes av typen lastbalanserare. De är avsedda för automatisk konfiguration av en extern molnbalanschef för alla arbetare i klustret. Denna externa balanschef dirigerar extern trafik till arbetarna och övervakar deras status. Om en eller flera arbetare blir otillgängliga omdirigeras trafiken till andra. Detta möjliggör skapandet av hög tillgängliga tjänster med hjälp av Kubernetes.

Kubernetes visar sig bäst när man startar mikrotjänstarkitekturer. Att implementera systemet i en klassisk arkitektur går, men är meningslöst. Om en applikation inte kan fungera i flera repliker, vad spelar det då för roll – om det är i Kubernetes eller inte?

Öppen källkod Kubernetes

Öppen källkod Kubernetes – en fantastisk sak: installerad och fungerar. Det kan köras på dina egna servrar, på din infrastruktur, du kan ställa in en master och arbetare där alla applikationer kommer att köras. Och viktigast av allt – allt detta är gratis. Men det finns nyanser.

Det första – kraven på kunskaper och erfarenheter hos administratörer och ingenjörer som ska sätta upp och underhålla detta. Eftersom kunden får full frihet i klustret, bär de själv ansvaret för klustrets funktionalitet. Och det är ganska enkelt att förstöra allt här.
Det andra – bristen på integrationer. Om man kör Kubernetes utan någon populär virtualiseringsplattform, får man inte alla fördelar med programmet. Såsom användning av Persistent Volumes och Load balancer-tjänster.

Figur 2. Arkitektur k8s

Kubernetes från leverantören

Integration med en molnleverantör ger två möjligheter:

För det första kan man bara trycka på knappen "skapa kluster" och få ett redan konfigurerat och klart kluster.
För det andra installerar leverantören själv klustret och konfigurerar integrationen med molnet.

Så här går det till hos oss. Ingenjören som sätter igång klustret anger hur många arbetare han behöver och med vilka specifikationer (till exempel 5 arbetare, var och en med 10 CPU, 16 GB RAM och, säg, 100 GB disk). Därefter får han tillgång till det redan etablerade klustret. Arbetarna som kör belastningen tilldelas helt kunden, men hela managementplanet förblir under leverantörens ansvar (om tjänsten tillhandahålls enligt modellen managed service).

Men denna modell har sina nackdelar. Eftersom managementplanet förblir hos leverantören ger de inte fullständig tillgång till kunden, vilket minskar flexibiliteten i arbetet med Kubernetes. Ibland vill kunden lägga till en specifik funktionalitet till Kubernetes, till exempel autentisering via LDAP, men konfigurationen av managementplanet tillåter inte detta.

Figur 3. Exempel på ett Kubernetes-kluster från en molnleverantör

Vad ska man välja: öppen källkod eller leverantörsbaserat

Så, open source Kubernetes eller leverantörs-specifik? Om man väljer open source Kubernetes kan användaren göra vad som helst med den. Men risken att man skjuter sig själv i foten är stor. Med en leverantör är det svårare, eftersom allt är genomtänkt och konfigurerat av företaget. Den största nackdelen med open source Kubernetes är kravet på specialister. Med en leverantör slipper företaget denna huvudvärk, men de måste ändå besluta: ska de betala sina specialister eller leverantören?

Nåväl, fördelarna är uppenbara, och nackdelarna är också kända. En sak är oförändrad: Kubernetes löser en mängd problem genom att automatisera hanteringen av flera containrar. Och vilken man ska välja, open source eller leverantörsspecifik, är upp till var och en att avgöra.