Kom igång på rätt sätt med Kubernetes

När du påbörjar din Cloud Native-resa behöver du fatta viktiga beslut om molnleverantörer, Continuous Deployment samt hur miljöer ska konfigureras och separeras. Den här guiden hjälper dig att fatta rätt beslut genom att dela lärdomar från att köra Cloud Native-appar i produktion.

Kubernetes har blivit de facto-plattformen för containerorkestrering. När vi hjälper kunder i olika storlekar och branscher att påbörja sina Cloud Native-resor med Kubernetes, stöttar vi dem i att fatta välgrundade beslut och göra rätt teknikval. Det finns ingen lösning som passar alla när du väljer molnleverantörer, CI-verktyg, pipelines för Continuous Deployment och så vidare. Därför är det viktigt att fatta rätt beslut från början. Annars kan det bli mycket kostsamt i form av förlorad tid och pengar.

I den här bloggen delar vi några viktiga aspekter att ta hänsyn till när du fattar beslut och gör teknikval för att komma igång med Kubernetes. Inlägget riktar sig till alla som påbörjar sin Cloud Native- och Kubernetes-resa, men även till dig som redan har kommit igång och vill verifiera dina val.

Välj rätt plattform

Kubernetes-kluster kan antingen hanteras på egen hand eller av en molnleverantör. Grundregeln är att använda en managed Kubernetes-tjänst, såvida du inte har starka tekniska eller juridiska skäl att använda ett självhanterat lokalt kluster. Självhanterade kluster kräver högspecialiserad kompetens i teamet samt löpande kostnader för infrastruktur och underhåll.

Om du väljer en managed Kubernetes-tjänst måste du också välja rätt leverantör. Det beror på flera faktorer, bland annat:

• Hur väl teamet känner till leverantörens tjänster.

• Mognadsgraden i leverantörens managed Kubernetes-erbjudande samt vilka funktioner och tekniska begränsningar det har. Till exempel om regional redundans eller automatisk skalning av kluster stöds. Andra exempel är om säkerhetspolicyer för poddar och nätverkspolicyer stöds.

• Om du behöver använda andra molntjänster från samma leverantör. Om din applikation till exempel kräver en DynamoDB-databas från AWS är det lämpligt att använda AWS EKS i samma region som DynamoDB-databasen för att minska fördröjningen vid dataåtkomst.

• Prissättning, SLA och supportpaket som leverantören erbjuder.

Generellt sett räcker någon av de tre stora molnleverantörerna – AWS, Google eller Azure – om du behöver ett enkelt Kubernetes-kluster. Enligt vår erfarenhet är dock Googles GKE enklast att komma igång med och det mest mogna managed Kubernetes-erbjudandet på marknaden.

Bestäm hur du ska dela upp dina miljöer

Oftast har du minst två miljöer: dev/test och prod. Hur ska de delas upp i Kubernetes? Du kan antingen ha ett kluster per miljö eller ett namespace per miljö. Att använda namespaces för att dela upp miljöer minskar kostnaderna eftersom samma infrastruktur delas, men det innebär också större risker på grund av mänskliga fel från utvecklare och operatörer. Det går att undvika sådana fel och åtkomstproblem, men det kräver hög kompetens i teamet för att implementera och övervaka lösningen. Det finns en avvägning mellan kostnaden för infrastrukturen och de personalresurser som krävs för åtkomstkontroll och säkerhet.

För små team rekommenderar vi ett kluster per miljö.

Du kan också placera klustren i separata virtuella eller fysiska nätverk och/eller i separata molnprojekt eller konton. Det ger en tydligare separation som gör det enkelt att upprätthålla strikt åtkomst till prod-miljöer, samtidigt som du kan experimentera med själva Kubernetes-konfigurationen i dev-klustret. Då kan du på ett säkert sätt aktivera vissa Kubernetes-funktioner eller testa nyare Kubernetes-versioner.

Standardisera din k8s-konfiguration

När du har valt en plattform för att driftsätta dina Kubernetes-kluster blir nästa fråga hur du ska driftsätta och underhålla dem. I de flesta fall behöver du hantera fler än ett kluster, och det är viktigt att undvika att konfigurationerna glider isär. Du kan till exempel ha dev- och prod-kluster och vill säkerställa att båda har samma konfigurationer och att deras noder har samma åtkomst- och autentiseringsbehörigheter till andra molntjänster. Det är viktigt eftersom du kommer att flytta applikationen från dev till prod och vill undvika obehagliga överraskningar.

För att göra detta rekommenderar vi en infrastructure-as-code-strategi, där du definierar klusterkonfigurationen som kod och hanterar konfigurationerna i ett versionshanteringssystem. När klusterkonfigurationen finns som kod kan du skapa ett nytt identiskt kluster för att testa något nytt utan att störa utvecklarnas arbetsflöde.

Vi rekommenderar också att du använder en pipeline för att driftsätta och underhålla dina kluster utifrån ändringar i dina versionshanterade konfigurationer. Detta kallas ofta GitOps.

Behandla verktyg som infrastruktur

Verktyg är tredjepartsverktyg eller -tjänster som du driftsätter i ditt kluster. Det kan vara övervakningsverktyg som Prometheus eller hanterare av SSL-certifikat som cert-manager. Dessa verktyg bör behandlas som en del av infrastrukturen, det vill säga att de driftsätts från kod när klustret skapas och underhålls via en pipeline, precis som själva klustret. Det kan till och med vara ett separat jobb i samma pipeline som skapar klustret. Fördelen är att du enkelt kan återskapa eller replikera klustret med alla dess tredjepartsverktyg. Vårt eget open source-verktyg Helmsman kan användas för att orkestrera driftsättning av tredjepartsappar för verktyg.

Använd namespaces på rätt sätt

Kubernetes namespaces är virtuella avgränsningar inom ett och samma kluster. De används ofta för att separera team och applikationer. Tänk på följande när du använder namespaces:

• I ett kluster med flera användargrupper ger du utvecklarna åtkomst endast till de namespaces de behöver genom att använda Kubernetes RBAC.

• Secrets är objekt med namespace och kan inte nås från ett annat namespace. Om flera applikationer som är driftsatta i olika namespaces behöver åtkomst till samma uppsättning secrets måste du antingen: a) driftsätta apparna i samma namespace, b) replikera secrets mellan namespaces och hålla dem synkroniserade manuellt eller, ännu bättre, c) använda ett verktyg för secrets-hantering som Vault.

• Du kan ange resurskvoter per namespace och därmed sätta gränser per team eller per uppsättning applikationer.

• Du kan använda network policies) för att tillåta eller blockera trafik mellan appar som är driftsatta i olika namespaces.

• Resursnamn i Kubernetes (t.ex. deployments, pods osv.) är unika inom ett namespace. Du behöver därför antingen driftsätta olika versioner av samma app i olika namespaces eller göra dina resursnamn dynamiska, vilket du kan göra när du paketerar appen med Helm.

Driftsättning med Helm

Helm är pakethanteraren för Kubernetes. Det är ett användbart verktyg för att paketera och dela dina konfigurerbara Kubernetes-mallar för driftsättning av applikationer. Vi rekommenderar att du använder Helm i stället för vanliga Kubernetes YAML-mallar för att driftsätta dina applikationer. Helm-paket – även kallade charts – gör det möjligt att återanvända mallar med konfigurationsparametrar. Det gör det enkelt att driftsätta flera instanser av din applikation i olika miljöer med olika konfigurationer, utan redundant kod eller redundanta mallar.

Helm 2.x kräver att en komponent på serversidan, kallad Tiller, driftsätts i klustret. Helm 3.0 tar bort Tiller, men är för närvarande en alphaversion. Eftersom du tills vidare använder Helm 2.x behöver du fundera på hur du ska driftsätta och säkra Tiller. Tänk på följande:

• Tiller har full åtkomst till klustret. Se därför till att följa de rekommenderade säkerhetskonfigurationerna när du driftsätter det.

• Vi rekommenderar att Tiller-driftsättningen ingår i din klusterpipeline. Det är användbart när du vill replikera klusterkonfigurationen eller för katastrofåterställning. Vårt open source-verktyg Helmsman kan användas för att driftsätta säkra Tiller-instanser.

• I ett kluster med flera tenants bör du driftsätta en Tiller per team i deras namespace och konfigurera RBAC så att Tillers omfång begränsas till endast det namespace:et.

Continuous Deployment (CD) av applikationer

Frekventa releaser av applikationer anses vara en god praxis eftersom det hänger samman med lägre risk för fel och kortare återhämtningstid vid incidenter (källa: The state of DevOps report 2019). När du använder Kubernetes och Helm bör du ha en automatiserad pipeline som kontinuerligt driftsätter dina ändringar i K8S.

Figur 1 visar en typisk CD-pipeline för Cloud Native-appar som driftsätts i K8S.

När du utformar din pipeline bör du fundera på hur du vill flytta din applikation från dev/test-miljön till prod-miljön. Det kan göras med manuella godkännanden i en enda pipeline, eller genom att dela upp dev- och prod-pipelines. Det finns ingen universallösning, men försök alltid använda den enklaste pipeline-konfigurationen tills du har goda skäl att göra den mer komplex. Tänk också på utvecklarnas bekvämlighet när du utformar arbetsflödet. Om en utvecklare till exempel måste göra ändringar i flera repos för att få ut en mindre buggrättning till prod är det sannolikt inte tillräckligt smidigt för att uppmuntra snabbare och tätare driftsättningar.

Helm charts och repos

Tänk på följande när du paketerar dina applikationer som Helm charts:

• Om flera applikationer eller tjänster har identiska eller mycket liknande Kubernetes-mallar för driftsättning (t.ex. en deployment, service och ingress) bör du skapa ett gemensamt chart som kan konfigureras för alla dessa applikationer. Då kan du fokusera på och härda ett enda chart i stället för flera liknande charts.

• Hur ska du hantera dina Helm charts? Och hur ska du dela dem internt eller externt vid behov?

En annan aspekt att ta hänsyn till är var du ska lagra dina Helm charts och hur du ska använda dem. Tre mönster används ofta:

1) Ha din Helm chart-katalog som en del av applikationens VCS-repo.

Fördelen med detta tillvägagångssätt är att du har allt på ett ställe. Nackdelarna är dock bland annat:

• komplex konfigurering i din pipeline för att versionshantera och publicera chartet separat från appen (om du inte väljer att släppa chartet och appen tillsammans varje gång, även när chartet inte faktiskt har ändrats).

• Om andra appar (i andra VCS-repos) driftsätts med samma chart får du redundant kod i dina repos.

• Du kan inte dela ditt chart utan att ge åtkomst till applikationens VCS-repo.

2) Ha ett separat VCS-repo för Helm charts och tillhandahåll dem från ett Helm-repo.

Fördelarna med detta tillvägagångssätt är:

• Versionshanterade charts som tillhandahålls från offentliga eller privata Helm-repon.

• Möjligheten att använda samma chart för flera appar där det passar, utan duplicerad kod.

Den största nackdelen med detta tillvägagångssätt är att om din applikation förändras på ett sätt som kräver en ändring i Helm-chartet, måste du först göra ändringen i Helm-chartet separat och sedan driftsätta ändringen i applikationskoden.

3) Eftersom ändringar i chartet kommer att vara vanliga i de tidiga faserna av applikationsutvecklingen kan du kombinera tillvägagångssätt 1 och 2 i olika faser av utvecklingen. Det första tillvägagångssättet kan användas i början, och när applikationen har stabiliserats kan du använda det andra.

Även om mönstren ovan fungerar i olika situationer bör ditt val baseras på ditt användningsfall och en avvägning mellan för- och nackdelarna med varje alternativ.

Hantering av klustrets tillstånd

Det är viktigt att planera för fel. Du bör också tänka på scenarier som: vad händer när applikationer tas bort? Eller vad händer om hela klustret tas bort? Vad händer om vi vill skapa en identisk kopia av klustret i en annan molnregion?

För att vara förberedd på alla dessa scenarier behöver du säkerhetskopiera och lagra klustrets tillstånd på en säker plats. Som tur är finns det verktyg som kan hjälpa dig med detta. Vi har framgångsrikt använt Velero från VMWare. Med Velero kan du konfigurera regelbunden säkerhetskopiering av klustrets tillstånd (deployments, volymer osv.) och lagra det i molnlagring. Klustersnapshots kan användas för att återställa klustrets tillstånd när som helst. Men vad händer om vi behöver återskapa själva klustret? Om du driftsätter klustret från kod, som vi diskuterade ovan, kan du återskapa det med samma versionshanterade kod som du använde för att skapa det från början och sedan återställa dess tillstånd med hjälp av en Velero-snapshot.

Avslutningsvis

Det är enkelt och lockande att ta genvägar när du är i början. Det är okej när du befinner dig i en fas där du lär dig och experimenterar. När du väl börjar konfigurera dina Kubernetes-miljöer bör du däremot se till att göra rätt från början, även om det kräver mer tid och arbete. Det kommer att löna sig i framtiden!