<?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 7nolikov | Dmitrii Novikov</title><link>https://7nolikov.dev/categories/kubernetes/</link><description>Recent content in Kubernetes on 7nolikov | Dmitrii Novikov</description><generator>Hugo</generator><language>en-US</language><managingEditor>7nolikov@gmail.com (Dmitrii Novikov)</managingEditor><webMaster>7nolikov@gmail.com (Dmitrii Novikov)</webMaster><copyright>Dmitrii Novikov</copyright><lastBuildDate>Mon, 01 Jan 0001 00:00:00 +0000</lastBuildDate><atom:link href="https://7nolikov.dev/categories/kubernetes/index.xml" rel="self" type="application/rss+xml"/><item><title>Kubernetes Failure Stories</title><link>https://7nolikov.dev/notes/kubernetes-failure-stories/</link><pubDate>Fri, 21 Aug 2026 00:00:00 +0000</pubDate><author>7nolikov@gmail.com (Dmitrii Novikov)</author><guid>https://7nolikov.dev/notes/kubernetes-failure-stories/</guid><description>&lt;p&gt;A collected list of public post-mortems from companies running Kubernetes in production. Real outages, written up by the people who were on call.&lt;/p&gt;
&lt;p&gt;It is the best argument I know against learning a platform only from its documentation. The docs tell you what the system does. These tell you what it does at 3am when a node&amp;rsquo;s disk fills up, a CNI plugin misbehaves, or a &lt;code&gt;livenessProbe&lt;/code&gt; restarts a healthy pod into an outage.&lt;/p&gt;</description></item></channel></rss>