<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>High Availability on Tom Meurs</title>
    <link>https://tommeurs.nl/en/tags/high-availability/</link>
    <description>Recent content in High Availability on Tom Meurs</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>© Tom Meurs</copyright>
    <lastBuildDate>Tue, 04 Mar 2025 20:47:00 +0100</lastBuildDate>
    <atom:link href="https://tommeurs.nl/en/tags/high-availability/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Running Kubernetes Offline: Edge Computing Without Internet</title>
      <link>https://tommeurs.nl/en/posts/kubernetes-offline-edge/</link>
      <pubDate>Tue, 04 Mar 2025 20:47:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/kubernetes-offline-edge/</guid>
      <description>&lt;p&gt;What happens when your Kubernetes cluster can&amp;rsquo;t reach the internet? I don&amp;rsquo;t mean a slow connection. I mean no connection at all. Ships at sea. Remote mining sites. Factory floors with air-gapped networks. Military deployments.&lt;/p&gt;&#xA;&lt;p&gt;For a lot of people that sounds exotic, like a problem someone else has. I treat it as a baseline design requirement, and I&amp;rsquo;ll explain why it makes my homelab better even though I almost never actually pull the cable.&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>
    <item>
      <title>Kubernetes High Availability: Stacked vs External etcd Explained</title>
      <link>https://tommeurs.nl/en/posts/kubernetes-high-availability-etcd/</link>
      <pubDate>Wed, 15 Jan 2025 20:23:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/kubernetes-high-availability-etcd/</guid>
      <description>&lt;p&gt;The first &amp;ldquo;production&amp;rdquo; Kubernetes cluster I ran had a single control plane node. It hummed along happily for weeks, right up until a disk failed and took the whole thing with it. Every pod, every service, gone. That outage taught me what &amp;ldquo;single point of failure&amp;rdquo; actually feels like, and it pushed me toward a question that I keep seeing trip people up: when you build a cluster that survives node loss, do you run etcd on your control plane nodes, or on dedicated nodes of its own?&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
