Fem vanliga misstag i Kubernetes-kluster

Kubernetes är kraftfullt men förlåter inte slarv. Efter att ha granskat dussintals kluster ser vi samma misstag om och om igen.

Vanligast är saknade resursgränser, som låter en enda pod svälta ut hela noden. Tätt därefter kommer överdrivna RBAC-rättigheter och hemligheter i klartext i konfigurationsfiler.

Vårt råd: inför policykontroller med OPA eller Kyverno tidigt, och behandla klusterkonfigurationen som kod med samma granskningskrav som applikationskoden.

Det tredje misstaget på vår lista är bristfälliga hälsokontroller. Liveness-prober som pekar på fel endpoint eller saknar rimliga tidsgränser skapar omstartsloopar som förvärrar incidenter i stället för att lösa dem. Tumregeln: liveness ska bara svara på frågan “är processen låst?”, readiness på “kan jag ta trafik just nu?” – att blanda ihop dem är en klassiker.

Fyra: övervakning som stannar vid infrastrukturen. CPU och minne i all ära, men det är applikationsmetriken – köer, felfrekvenser, latenspercentiler – som avslöjar problem innan användarna gör det. Utan den flyger ni i mörker med fungerande instrumentpanel.

Femte och sista misstaget är att skjuta upp uppgraderingarna. Kubernetes släpper tre versioner per år och stödfönstret är begränsat; den som halkar tre versioner efter står inför en riskabel maratonuppgradering i stället för rutinmässiga små steg. Boka in uppgraderingsfönster i förväg, precis som ni gör med beroendeuppdateringar.

Den gemensamma nämnaren för alla fem? De är billiga att åtgärda tidigt och dyra att åtgärda sent. En dags arbete med policyer och prober när klustret är ungt sparar veckor av incidenthantering längre fram.