Framtiden för Kubernetes – lärdomar från fireside chat på DEVOPS Conference

Från containerorkestrering till en kontrollplan

Många av oss ser Kubernetes som en plattform för containerorkestrering. Du säger att du behöver tre kopior, så här mycket minne och viss CPU-kapacitet. Sedan är du i gång med några nya, glänsande containrar.

Men Kubernetes har utvecklats tillsammans med webben och blivit något mycket mer. Tänk på hur webben har förändrats: alla som kör en webbserver behöver inte en webbplats. Men vi kan ändå använda det underliggande HTTP-protokollet för att överföra information, till exempel via ett REST API.

Om man tänker efter är det konceptet tillståndshantering som skiljer Kubernetes från tidigare verktyg som Puppet, Chef och Ansible. Det bygger på promise theory: du uttrycker vad du vill ska hända och publicerar det som data. Det skiljer sig från skriptning, där du skriver något i Ruby, Python eller Bash och kör det på maskinen.

Du beskriver alltså en databas och skickar den till API-servern. Dess uppgift är att starta en controller som övervakar och förstår datan och ger dig en databas. Kontrollslingan och kontrollplanen, som tidigare användes för att kontrollera tillståndet och jämföra det som var avgörande för containerorkestrering, används nu mycket bredare. Det har blivit Kubernetes superkraft.

Det här breddar användningsområdena för Kubernetes till en mängd nya och spännande saker. Verktyg och lösningar som Crossplane använder kontrollplanens funktionalitet fullt ut. Containrar blir då nästan en eftertanke.

Tecken på mognad: distrofeber

I takt med den här transformationen mognar Kubernetes, precis som Linux gjorde förr i tiden.

Om du installerar Kubernetes från grunden på samma sätt som du brukade skapa egna OS-distributioner har vi en nyhet: det finns ett bättre sätt. Precis som det finns många färdigpaketerade Linux-varianter, som Red Hat, CentOS, Debian och SUSE, finns det nu färdigpaketerade Kubernetes-varianter som GKE från Google Cloud, EKS från AWS och AKS från Azure. Eller OpenShift, om du vill behålla lite mer oberoende.

Du behöver inte längre lägga tid och kraft på att bygga din distribution från grunden. Med färdiga ”distributioner” kan du fokusera på verksamheten och utveckla din plattform mycket snabbare.

Bryt silos med ett API

Låt oss vara ärliga: världen har alltid varit uppdelad i silos. Det har alltid handlat om: ”Ge oss din kod, så kör vi en massa skript och logik, och på något sätt hamnar den i produktion.” Och om något gick sönder samlades ni för att felsöka det, om och om igen under lång tid.

Du behöver bryta silos, eller hur? Ja, men silos är egentligen bara dåliga när det inte finns något sätt för dem att kommunicera med varandra. Det känns inte lika isolerat när det finns ett API, även om du befinner dig i en silo.

Mycket fungerar fortfarande på samma sätt som för 15 år sedan. Du skriver kod, kör tester, skapar artefakter och låter sedan människor beskriva vilka zoner de behöver. Det Kubernetes verkligen förändrar är den sista biten. Det innebär att du inte behöver lära alla dina utvecklare Docker, Vagrant, Puppet eller Ansible. De verktygen är bara ett sätt att nå målet.

Tanken är att låta någon deklarera vad de behöver av dig, ta den informationen och få den att överensstämma i bakgrunden. Kubernetes gör det enkelt. På så sätt spelar silos inte alls lika stor roll.

Det är som att ha ett avtal för att begära tjänster eller system, som implicit definierar hur man interagerar och vad man kan förvänta sig. Med en sådan definition känns det som att det finns ett löfte eller avtal med ett SLA, och vardagen blir mycket mer hanterbar.

Det kan vara lättare att förstå genom att jämföra med något som Terraform. Med Terraform (vi förenklar lite, det vet vi) skriver du Terraform-kod i en fil på din laptop, och den körs bara när du startar den. När din laptop eller den centrala server där du körde Terraform stängs av händer ingenting. Terraform kan inte göra något förrän det körs igen.

Kubernetes har ett annat angreppssätt. Det finns alltid en controller som, dygnet runt, granskar ditt önskade tillstånd och försöker få det att stämma överens med verkligheten. Systemet känns självläkande eftersom det förstår att det aldrig finns en tidpunkt då du inte vill att det deklarerade tillståndet ska gälla.

Kubernetes gillar pipelines (och tvärtom)

En av de stora fördelarna med Kubernetes är att du kan gå från Infrastructure as Code (IaC) till Infrastructure as Data (IaD).

Skillnaden kanske inte låter så stor, men den ger viktiga fördelar, som möjligheten att bygga en pipeline.

Med kod är det svårt att bygga pipelines eftersom ett verktyg inte kan förstå syntaxen och skriptspråket som du använde tidigare. Men när du gör infrastrukturen till data kan du göra riktigt bra saker, som att lägga till policyer. Det är en stor förbättring för att hantera resurser effektivt och säkert.

Stateful eller stateless – är det frågan?

Vissa vill samla allt i Kubernetes. Och visst, även stateful-tjänster kan köras i Kubernetes, men Kubernetes kan bara hjälpa dig halvvägs.

De flesta SQL-databaser, som Postgres och MySQL, gillar stabilitet. De är inte utformade för att hantera skiftande IP-adresser och slumpmässiga maskinfel. Om du vill köra den typen av databaser i Kubernetes behöver du hjälp från en operator som Vitess, ett system för databasklustring och horisontell skalning av MySQL.

Det andra alternativet (när det är tillgängligt) är att använda managed services för databaser och konfigurera dina applikationer som körs i Kubernetes att använda dem. Att använda databaser som en managed service kan också minska overheaden med att ha flera databaser, vilket gör det enklare att hålla din blast radius liten och begränsa konsekvenserna om något går fel.

Kom ihåg: Kubernetes är bara så bra som infrastrukturen det körs på

En fråga vi ibland får är om Kubernetes kan köras on-prem. Svaret är ja, ungefär. Den verkliga frågan är: bör du göra det?

Det beror helt på dina behov och din infrastruktur. Kubernetes är bara så bra som infrastrukturen det körs på. Kubernetes on-prem kan bara bli så bra som den underliggande compute-plattform det installeras på. Om du vill köra Kubernetes on-prem bör du fråga dig om du kan leverera tjänster på samma nivå som molnleverantörer. Kubernetes förutsätter ett IaaS-lager under sig som tillhandahåller maskinautomatisering, inklusive åtkomst till lagring och nätverk. Glöm alltså inte bort det grundläggande.

Att bygga vidare på Kubernetes

Många vill se tillägg och förbättringar i Kubernetes – lite som att både ha kakan och äta den.

Ett vanligt önskemål är en mer flexibel nätverksstack. Kubernetes har tydliga åsikter i den här frågan och vill till exempel ha en dedikerad IP-adress per pod. Det är först nyligen som det blev möjligt att ha dubbla IP-stackar för IPv4 och IPv6.

Kubernetes är inte heller tänkt att vara en plattform, utan ett sätt att bygga plattformar. Pods och RBAC är grundläggande koncept som är stabila och mogna. De kompletterande delarna, som admission controllers, avancerade nätverkskontroller och liknande, utvecklas fortfarande i takt med att vi lär oss mer.

Den otroliga buffémenyn i CNCF-landskapet

När vi ändå talar om att bygga vidare på Kubernetes bör du inte glömma CNCF:s (Cloud Native Computing Foundation) landskap. Det är en mycket omfattande resurs – vilket kanske är årets underdrift – och där finns mycket bra.

Men kom ihåg att det bara är en enorm buffémeny, inte en lista över rekommenderade saker eller sådant som ”bör ingå”. Kubernetes är en uppsättning beslut om hur saker ska göras. CNCF erbjuder flera alternativ för liknande behov, och många av dem utvecklas fortfarande och mognar.

Med Kubernetes kan man definiera nya typer av workloads, till exempel Redis-kluster med hög tillgänglighet, med hjälp av operators. Tyvärr tenderar människor att bygga operators med ett hårt beroende av Kubernetes. I stället bör operators utformas oberoende av Kubernetes: logiken för att till exempel skapa ett Redis-kluster bör vara portabel och tillgänglig via ett API, som sedan kan integreras med Kubernetes genom CRD:er. På så sätt förblir lösningarna mer flexibla.

Så, vad är grymt inom CNCF?

I slutet av samtalet ville vi sätta Kelseys ”memifierade” dope-betygssystem med dope, pretty dope, extra dope och super dope på prov och bad Kelsey betygsätta några intressanta CNCF-projekt. Här är några av hans val (för mer bra dope, se videon …):

Vault (hantering av hemligheter): super dope

ArgoCD (deklarativ GitOps): super dope

Keda (händelsedriven autoskalning med en mängd plugins): extra dope

Det allra mest super-dope projektet av dem alla (utöver Kubernetes självt) är Open Policy Agent (OPA). Det får inte tillräckligt mycket erkännande för vad det gör. Tillsammans med Infrastructure as Data gör OPA det möjligt att tillämpa policyer innan saker checkas in och tillämpas.

Kort sammanfattning

Under fireside chat-samtalet diskuterade vi många ämnen kring Kubernetes och var det befann sig 2022. Om vi skulle sammanfatta allt i tre huvudpunkter skulle de kunna se ut så här:

1. Se inte längre Kubernetes som bara en plattform för containerorkestrering. Det har utvecklats till ett control plane som du kan använda på ett mycket bredare sätt – och det har blivit Kubernetes superkraft.

2. Kubernetes hjälper dig att gå från Infrastructure as Code till Infrastructure as Data och verkligen frigöra kraften i pipelines.

3. Även om du kan köra stateful services i Kubernetes bör du tänka efter en extra gång om det är klokt. Managed services kan minska overheaden och hjälpa dig att hålla saker enkla.

Vi är överlag väldigt entusiastiska över hur långt Kubernetes har kommit sedan starten 2014. Och vi ser fram emot att se hur långt det kan nå under de kommande åren!