Bygg en DevOps-plattform med Terraform och Kubernetes

De flesta svenska team vi möter har inte ett verktygsproblem — de har ett strukturproblem. Terraform-koden ligger huller om buller i ett repo, klustret är handpåtvingat konfigurerat via kubectl apply från en utvecklares laptop, och ingen minns riktigt varför en viss namespace har de rättigheter den har. 2026 är verktygen mogna: Terraform, Kubernetes, ArgoCD och Crossplane löser de tekniska problemen bra. Det som fortfarande går fel är arkitekturen runt dem — hur du strukturerar state, hur många kluster ni faktiskt behöver, och var gränsen går mellan infrastruktur som kod och applikationsdeploy.

I den här guiden går vi igenom hur vi bygger DevOps-plattformar åt kunder: Terraform-modulstruktur som skalar från en till tjugo miljöer, state-hantering utan låsta filer och race conditions, Kubernetes-clusterarkitektur (ett stort kontra flera små), och GitOps som deploymodell med ArgoCD eller Flux.

Terraform-modulstruktur som faktiskt skalar

Det vanligaste misstaget vi ser är ett enda monolitiskt Terraform-repo där main.tf är 3 000 rader långt och innehåller allt från VPC till IAM-roller till databasinstanser. Det fungerar i sex månader — sedan blir varje terraform plan en femminuterslång operation som ingen vågar köra utan att fråga en kollega. Lösningen är att dela upp infrastrukturen i lager: grundläggande nätverk och identitet i ett lager, delade plattformstjänster (kluster, databaser, meddelandeköer) i ett andra, och applikationsspecifik infrastruktur i ett tredje.

Vi rekommenderar en modulstruktur med tydliga gränssnitt: varje modul exponerar ett litet antal input-variabler och output-värden, och interna implementationsdetaljer hålls privata. Använd Terraform-workspaces sparsamt — de är bra för att separera dev/stage/prod inom samma modul, men blir snabbt förvirrande om ni har fler än tre miljöer. För svenska team som växer mot 5-10 miljöer (flera kunder, flera regioner) fungerar bättre att separera miljöer i egna statefiler med en gemensam modulkatalog som versioneras separat.

State-hantering — din enda källa till sanning

Terraform state är den mest underskattade riskfaktorn i en DevOps-plattform. Vi har sett team som kör state lokalt på en bärbar dator (ett recept för dataförlust och krockande ändringar), och team som delar en enda statefil för hela organisationens infrastruktur (ett recept för att en liten ändring i ett team råkar radera en annan avdelnings databas). Använd alltid fjärrlagrad state med låsning — S3 + DynamoDB, Azure Storage + lease-lås, eller Terraform Cloud/HCP för team som vill slippa hantera det själva.

Dela upp statefiler efter blast radius, inte efter bekvämlighet. Nätverk och IAM i en statefil, varje Kubernetes-kluster i sin egen, varje applikationsteams namespace-resurser i ytterligare en. Det gör att en trasig terraform apply i ett teams del av infrastrukturen aldrig kan påverka en annan del. För team som redan sitter med ett stort monolitiskt state rekommenderar vi terraform state mv och gradvis uppdelning snarare än en big-bang-migrering — vi har gjort det åt kunder över 3-4 veckor utan driftstopp.

Ett stort kluster eller flera små?

Den vanligaste frågan vi får är om man ska köra ett stort delat Kubernetes-kluster eller flera mindre per miljö eller team. Svaret beror på organisationens mognad och regelkrav. Ett delat kluster med namespace-isolering, ResourceQuotas och NetworkPolicies är billigare att drifta och enklare att övervaka — men kräver disciplin kring RBAC och nätverkssegmentering för att undvika att ett teams brustna deploy stjäl resurser från alla andra.

För svenska kunder inom finans eller vård, där regulatoriska krav (NIS2, DORA) eller kunddataisolering väger tungt, rekommenderar vi separata kluster per säkerhetszon snarare än enbart namespace-isolering — det är enklare att bevisa för en revisor att data aldrig delar kontrollplan. För SaaS-produkter med multipel tenant utan hårda regulatoriska krav räcker oftast ett väl konfigurerat delat kluster med tydlig NetworkPolicy-strategi och Pod Security Standards satta till restricted. Läs mer om hur vi resonerar kring detta i vår genomgång av cybersäkerhet för molnmiljöer.

GitOps — låt Git vara sanningen, inte din terminal

När infrastrukturen är på plats är nästa steg att sluta köra kubectl apply manuellt. GitOps med ArgoCD eller Flux innebär att klustrets önskade tillstånd alltid speglar vad som ligger i ett Git-repo — ingen deployar direkt till klustret, all förändring går via en pull request som mergas och sedan synkas automatiskt. Det ger dig ett fullständigt granskningsspår (vem ändrade vad, när och varför) och gör rollback trivialt: git revert och synken sköter resten.

Vi föredrar ArgoCD för team som vill ha ett tydligt UI och stöd för multi-cluster-deploy från en central instans, och Flux för team som redan investerat tungt i en ren CLI/GitOps-arbetsflöde utan extra kontrollplan. Kombinera med Sealed Secrets eller extern secrets-hantering (Infisical, HashiCorp Vault, eller molnleverantörens Key Vault) — lägg aldrig okrypterade hemligheter i Git, även privata repon.

Observability och kostnadskontroll från dag ett

En plattform som inte är instrumenterad från start blir aldrig instrumenterad senare — den blir brandsläckning. Sätt upp Prometheus + Grafana eller en hanterad motsvarighet (Grafana Cloud, Datadog) samtidigt som klustret provisioneras, inte som ett eftertänkt projekt när något redan gått sönder. Vi går igenom hela observability-stacken, inklusive loggar och distribuerad spårning, i vår artikel om observability i praktiken.

Kostnadskontroll är den andra delen som ofta glöms bort. Kubernetes gör det förvånansvärt lätt att över-provisionera — utan requests/limits satta korrekt äter en handfull pods hela klustrets kapacitet. Sätt ResourceQuota per namespace från start, använd verktyg som Kubecost eller OpenCost för att se kostnad per team och tjänst, och granska node-poolernas storlek månadsvis. Vi har sett kunder halvera sin molnkostnad enbart genom att rätta requests/limits och aktivera cluster-autoscaling korrekt.

Vår rekommendation för olika mognadsnivåer

För team som börjar från noll rekommenderar vi att inte bygga en egen plattform från grunden — börja med en hanterad Kubernetes-tjänst (AKS, EKS, GKE eller motsvarande europeisk leverantör), Terraform för allt utanför klustret, och ArgoCD för allt innanför. Bygg inte en intern platform-as-a-service innan ni har minst 4-5 team som delar infrastrukturen — innan dess är overheaden inte värd det. För team som redan skalat och känner smärtan av manuell drift är nästa steg att formalisera modulstrukturen, dela upp state efter blast radius, och införa GitOps som obligatorisk deploy-väg — inte en valfri bekvämlighet.

Vi hjälper svenska team bygga och migrera till kodstyrda DevOps-plattformar, från Terraform-arkitektur till Kubernetes-clusterdesign och GitOps-implementation — läs mer om våra tjänster eller boka ett samtal.