<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Resilience on Tom Meurs</title>
    <link>https://tommeurs.nl/en/tags/resilience/</link>
    <description>Recent content in Resilience on Tom Meurs</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>© Tom Meurs</copyright>
    <lastBuildDate>Mon, 18 May 2026 19:30:00 +0100</lastBuildDate>
    <atom:link href="https://tommeurs.nl/en/tags/resilience/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Backup Strategy for Your Homelab: The 3-2-1 Rule in Practice</title>
      <link>https://tommeurs.nl/en/posts/homelab-backup-strategy/</link>
      <pubDate>Mon, 18 May 2026 19:30:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/homelab-backup-strategy/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; Three copies, two kinds of media, one of them offsite. Restic for files, Velero for the cluster, a Backblaze bucket for the offsite copy, and a restore test on a schedule. Mine costs about €5 a month, and the restore test is the part I still have to make myself do.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;Picture the disk in your &lt;a href=&#34;https://tommeurs.nl/en/posts/k3s-cluster-setup/&#34;&gt;homelab&lt;/a&gt; dying tonight. Not corrupting, not throwing SMART warnings for a week first, just gone. The git server with every repo you care about, the password vault, fifteen years of family photos, the home automation that runs the house. All of it on a drive that&amp;rsquo;s decided it&amp;rsquo;s done.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Chaos Engineering: Breaking Your Cluster to Make It Stronger</title>
      <link>https://tommeurs.nl/en/posts/chaos-engineering-kubernetes/</link>
      <pubDate>Tue, 28 Apr 2026 19:45:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/chaos-engineering-kubernetes/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; Chaos engineering is breaking your own cluster on purpose, with the hypothesis written down first and a rollback ready. I run it on the homelab with Litmus: a weekly pod-delete, a monthly node drain, a game day every quarter. So far it has found four things the dashboard would never have shown me.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;My dashboard is a wall of green. Pods running, replicas matched, CPU comfortable, no alerts firing. I look at it and get that small hit of &amp;ldquo;everything&amp;rsquo;s fine.&amp;rdquo; And mostly it is. The cluster&amp;rsquo;s been up for weeks and nothing has fallen over.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Alerting That Works: From Alert Fatigue to Actionable Notifications</title>
      <link>https://tommeurs.nl/en/posts/alerting-that-works/</link>
      <pubDate>Thu, 16 Apr 2026 20:15:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/alerting-that-works/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; Most default alert rules page on a number with no user behind it, and after a week of that you stop reading pages. I alert on error rate, P99 latency, a disk that fills within 24 hours and a certificate under seven days, about ten rules in total, each with a runbook. Alertmanager sends critical to the pager, warning to Slack during office hours, info nowhere. Everything that doesn&amp;rsquo;t need a human gets deleted.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Thanos Remote Write: Push-Based Metrics for Edge and Multi-Cluster</title>
      <link>https://tommeurs.nl/en/posts/thanos-remote-write-push-architecture/</link>
      <pubDate>Fri, 27 Mar 2026 20:38:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/thanos-remote-write-push-architecture/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; Thanos Receive turns the metrics flow around. Each edge Prometheus pushes samples over &lt;code&gt;remote_write&lt;/code&gt; to one central endpoint, buffers in its WAL when the link drops, and never sees an object storage credential. Below is the Receive StatefulSet, the hashring, the edge config, two ways to lock the endpoint down, and the hybrid I run with sidecars on the core clusters.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;In my &lt;a href=&#34;https://tommeurs.nl/en/posts/prometheus-thanos-metrics/&#34;&gt;previous post on Prometheus and Thanos&lt;/a&gt;, I set up the sidecar architecture. &lt;span class=&#34;def&#34; tabindex=&#34;0&#34; data-def=&#34;Gives Prometheus long-term storage in object storage and one query view across several Prometheus servers, without changing how Prometheus scrapes.&#34;&gt;Thanos&lt;/span&gt;&#xA; Sidecar runs next to Prometheus, uploads TSDB blocks to object storage, and exposes the data to the Querier over gRPC. For clusters in the same datacenter with a fat, stable link to the central infrastructure, I&amp;rsquo;ve got no complaints. Everything pulls, and everything can reach everything else.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Unbreakable - My Fascination.</title>
      <link>https://tommeurs.nl/en/posts/unbreakable/</link>
      <pubDate>Tue, 23 Dec 2025 20:00:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/unbreakable/</guid>
      <description>&lt;p&gt;As a kid I called the things that fascinated me &lt;strong&gt;unbreakable&lt;/strong&gt;. Indestructible never fit, because indestructible means it never breaks. Unbreakable means it keeps working &lt;em&gt;after&lt;/em&gt; it breaks.&lt;/p&gt;&#xA;&lt;p&gt;I know exactly when it started. A photo of an A-10 Thunderbolt II back from a mission with half a wing gone, the tail in tatters and the fuselage full of holes. It still brought its pilot home.&lt;/p&gt;&#xA;&lt;p&gt;Luck had nothing to do with it. Somebody sat at a drawing board years before that mission and decided the plane had to come home looking like that.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Kubernetes RBAC: Least Privilege in Practice</title>
      <link>https://tommeurs.nl/en/posts/kubernetes-rbac-least-privilege/</link>
      <pubDate>Tue, 19 Aug 2025 10:00:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/kubernetes-rbac-least-privilege/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; Kubernetes ships with a permission model that hands every pod a token and lets the default service account collect rights nobody remembers granting. Least privilege means a service account per workload, no token unless the app talks to the API, and roles that name the namespace, the resource and the verb. Below are the four RBAC resources, the five settings that cap the blast radius, the bindings I copy most often, and how I check and enforce all of it.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Progressive Delivery with Argo Rollouts: Canary and Blue-Green Deployments</title>
      <link>https://tommeurs.nl/en/posts/argo-rollouts-progressive-delivery/</link>
      <pubDate>Fri, 20 Jun 2025 10:00:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/argo-rollouts-progressive-delivery/</guid>
      <description>&lt;p&gt;A standard Kubernetes Deployment had served me well for a long time. Push a new image tag, watch the pods roll, done. It was simple, it was declarative, and most of the time nothing went wrong. The rolling update even gave me a warm feeling of safety: old pods only get torn down once new ones are ready.&lt;/p&gt;&#xA;&lt;p&gt;That feeling is a lie. A rolling update protects you from pods that fail to start. It does nothing to protect you from pods that start perfectly and then serve broken responses. The container is healthy, the readiness probe is green, and your new code is quietly returning 500s to every single user. Within seconds, 100% of your traffic is hitting code that nobody validated under real load.&lt;/p&gt;</description>
    </item>
    <item>
      <title>GitOps Disaster Recovery: Rebuilding Your Cluster from Git</title>
      <link>https://tommeurs.nl/en/posts/gitops-disaster-recovery/</link>
      <pubDate>Wed, 09 Apr 2025 19:52:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/gitops-disaster-recovery/</guid>
      <description>&lt;p&gt;For a couple of years my homelab cluster ran without much drama. Nodes came and went, workloads shifted around, and the worst I ever had to deal with was the occasional pod stuck in &lt;code&gt;CrashLoopBackOff&lt;/code&gt;. The kind of stable where you stop thinking about what happens if it all goes away.&lt;/p&gt;&#xA;&lt;p&gt;Then one evening I ran a &lt;code&gt;terraform destroy&lt;/code&gt; against the wrong workspace. By the time I noticed, the control plane was gone. Not degraded. Gone.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Graceful Degradation in Kubernetes: What Happens When Components Fail</title>
      <link>https://tommeurs.nl/en/posts/kubernetes-graceful-degradation/</link>
      <pubDate>Thu, 20 Feb 2025 14:22:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/kubernetes-graceful-degradation/</guid>
      <description>&lt;p&gt;Everyone repeats the line that Kubernetes is self-healing. Pods die, they come back. Nodes drop, workloads reschedule. The system reconciles itself toward the state you declared, and most days you never have to think about it.&lt;/p&gt;&#xA;&lt;p&gt;Then one day the thing doing the healing is the thing that broke. The API server is down. etcd won&amp;rsquo;t respond. The scheduler is wedged. Now what?&lt;/p&gt;&#xA;&lt;p&gt;This is the question I actually care about, because &amp;ldquo;self-healing&amp;rdquo; is only useful if I understand its edges. I want to know what degrades gracefully and what takes the whole cluster with it. So I&amp;rsquo;ve run my clusters through a lot of failures on purpose: planned, unplanned, and a few &amp;ldquo;hold my beer&amp;rdquo; experiments on hardware I didn&amp;rsquo;t mind losing. Here is what actually happens when each piece breaks, and why most of it matters less than people fear.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
