<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Reliability on Alhassan Ibrahim</title><link>https://blog.alhassan.link/tags/reliability/</link><description>Recent content in Reliability on Alhassan Ibrahim</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>me@alhassan.link (Alhassan Ibrahim)</managingEditor><webMaster>me@alhassan.link (Alhassan Ibrahim)</webMaster><copyright>© 2026 Alhassan Ibrahim</copyright><lastBuildDate>Mon, 10 Aug 2026 09:00:00 +0100</lastBuildDate><atom:link href="https://blog.alhassan.link/tags/reliability/index.xml" rel="self" type="application/rss+xml"/><item><title>Designing Resilient Kubernetes Deployments</title><link>https://blog.alhassan.link/posts/designing-resilient-kubernetes-deployments/</link><pubDate>Mon, 10 Aug 2026 09:00:00 +0100</pubDate><author>me@alhassan.link (Alhassan Ibrahim)</author><guid>https://blog.alhassan.link/posts/designing-resilient-kubernetes-deployments/</guid><description>&lt;p&gt;Most Kubernetes outages I&amp;rsquo;ve debugged in production weren&amp;rsquo;t caused by Kubernetes itself — they were caused by a deployment manifest that never told Kubernetes what &amp;ldquo;healthy&amp;rdquo; and &amp;ldquo;safe to disrupt&amp;rdquo; actually meant. A handful of fields close most of that gap.&lt;/p&gt;</description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://blog.alhassan.link/posts/designing-resilient-kubernetes-deployments/featured.jpg"/></item></channel></rss>