<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kubernetes on IET Connect</title><link>/tags/kubernetes/</link><description>Recent content in Kubernetes on IET Connect</description><generator>Hugo</generator><language>sv-se</language><lastBuildDate>Tue, 20 Jan 2026 00:00:00 +0000</lastBuildDate><atom:link href="/tags/kubernetes/index.xml" rel="self" type="application/rss+xml"/><item><title>Fem vanliga misstag i Kubernetes-kluster</title><link>/post/post-06/</link><pubDate>Tue, 20 Jan 2026 00:00:00 +0000</pubDate><guid>/post/post-06/</guid><description>&lt;p&gt;Kubernetes är kraftfullt men förlåter inte slarv. Efter att ha granskat dussintals kluster ser vi samma misstag om och om igen.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Vårt råd: inför policykontroller med OPA eller Kyverno tidigt, och behandla klusterkonfigurationen som kod med samma granskningskrav som applikationskoden.&lt;/p&gt;
&lt;p&gt;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 &amp;ldquo;är processen låst?&amp;rdquo;, readiness på &amp;ldquo;kan jag ta trafik just nu?&amp;rdquo; – att blanda ihop dem är en klassiker.&lt;/p&gt;</description></item></channel></rss>