Hoppa till innehåll
DevOps & PlattformKubernetesMognadsanalysDevOps12 min läsning

Kubernetes för 5-personers team: När det är värt komplexiteten

Alla pratar om Kubernetes, men få frågar om ett team på fem personer verkligen ska driva ett kluster. Här är min ärliga avvägning.

00
Kubernetes för 5-personers team: När det är värt komplexiteten
Ett kluster löser verkliga problem, men det skapar också nya som någon måste äga.Photo: Unsplash

Ska ditt team använda Kubernetes? Ärlig genomgång av när K8s tillför värde.

Jag möter ofta team som har bestämt sig för Kubernetes innan de har formulerat vilket problem de försöker lösa. Det är förståeligt. Kubernetes är standarden, det ser bra ut i en arkitekturskiss och det känns framtidssäkert. Men för ett team på fem personer är frågan inte om Kubernetes är kraftfullt, det är det, utan om kraften är värd den löpande kostnaden i tid och uppmärksamhet. Den här texten är mitt försök att svara ärligt.

Vad du faktiskt köper med Kubernetes

Kubernetes ger dig en deklarativ modell för att köra containrar. Du beskriver önskat tillstånd, och klustret arbetar för att hålla verkligheten i linje med beskrivningen. Du får self-healing när en process dör, horisontell skalning, rullande uppdateringar, tjänsteupptäckt och en gemensam vokabulär som tusentals verktyg pratar. Det är ett genuint kraftfullt fundament.

Problemet är att den deklarativa modellen kommer med en inlärningskurva som inte tar slut efter den första veckan. Nätverk, ingress, lagring, RBAC, resursgränser och uppgraderingar är var och en ett litet ämne. Och även om du använder en hanterad tjänst som tar bort control plane-driften, äger du fortfarande allt ovanför.

Tre frågor jag ställer först

Innan jag rekommenderar Kubernetes till ett litet team ställer jag tre konkreta frågor.

  • Hur många tjänster kör ni? En eller två tjänster behöver sällan ett kluster. Tio eller femton tjänster som ska prata med varandra är ett annat läge.
  • Hur ser er trafik ut? Jämn och förutsägbar trafik passar enklare plattformar. Stora svängningar där autoskalning sparar verkliga pengar talar för Kubernetes.
  • Vem äger driften om sex månader? Om svaret är samma två personer som redan är fullbokade är det en varningssignal.

De ärliga alternativen

Det finns ett helt spektrum mellan en enda server och ett fullt kluster, och de mellanlägena är ofta rätt för ett team på fem personer.

  • Plattform som tjänst: tjänster där du pushar kod och får en körande app sköter skalning och drift åt dig. Du betalar mer per enhet men slipper äga plattformen.
  • Container-tjänster utan kluster: molnens serverless-container-erbjudanden kör dina images utan att du hanterar noder alls.
  • En eller två servrar med Docker Compose: förvånansvärt långt bär detta för ett internt verktyg eller en tidig produkt.

Poängen är inte att undvika Kubernetes av princip, utan att välja den lägsta komplexitet som löser ditt problem i dag och som du kan klättra uppåt från senare.

Om du ändå väljer Kubernetes

När Kubernetes är rätt, och det är det förvånansvärt ofta även för mindre team med rätt stöd, finns det val som gör livet enklare. Använd en hanterad tjänst så att du slipper control plane. Håll dig till en distribution och en region tills du verkligen behöver fler. Definiera resurskrav och gränser på allt från start, för utan dem blir klustret oförutsägbart. Och automatisera uppgraderingar tidigt, eftersom ett kluster som ligger flera versioner efter är ett kluster ingen vågar röra.

Mitt vanligaste upplägg för ett litet team är ett hanterat kluster med GitOps-baserad deploy, så att ingen behöver ha credentials rakt in i klustret och varje ändring är spårbar i git. Hur jag tänker kring hela den plattformen beskriver jag i min tjänst för DevOps-plattform.

Den verkliga kostnaden är uppmärksamhet

Det som sällan står i jämförelserna är att ett kluster kräver löpande uppmärksamhet. Säkerhetsuppdateringar, certifikatförnyelser, versionshopp och kapacitetsplanering är arbete som aldrig tar slut. För ett stort team fördelas det på många axlar. För ett team på fem personer landar det på en eller två, och varje timme där är en timme de inte bygger produkt. Det är den avvägningen som avgör om Kubernetes lönar sig, inte den tekniska elegansen.

Relaterat

Vill du se hur valet fallit ut i konkreta uppdrag finns flera exempel i min casebook.

Vill du ta det vidare?

Är du osäker på om Kubernetes är rätt för er går jag gärna igenom era förutsättningar utan att sälja in något ni inte behöver. Du kan också testa min mognadsanalys först, eller höra av dig via kontaktsidan.

Frågan är inte om Kubernetes är kraftfullt, utan om kraften är värd den löpande kostnaden.

- Simon Axelsson

Vanliga frågor

Är hanterad Kubernetes tillräckligt för att slippa drift?
Nej. Det tar bort control plane-driften, men du äger fortfarande noder, nätverk, säkerhet och uppgraderingar av allt du kör. Det är en stor lättnad, men inte hela jobbet.
När är Kubernetes definitivt overkill?
När du kör en eller två tjänster med jämn trafik och inget team som kan ta löpande driftansvar. Då vinner en enklare plattform nästan alltid på totalen.
Kan vi börja enkelt och flytta till Kubernetes senare?
Ja, och det är ofta klokt. Om du containeriserar dina tjänster från start är steget till Kubernetes senare mindre, eftersom själva applikationen redan är portabel.
Simon Axelsson
Simon AxelssonIT-konsult & teknisk rådgivare

Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.

Fler artiklar