<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Understanding on Tom Meurs</title>
    <link>https://tommeurs.nl/en/tags/understanding/</link>
    <description>Recent content in Understanding on Tom Meurs</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>© Tom Meurs</copyright>
    <lastBuildDate>Sun, 20 Sep 2026 21:00:00 +0200</lastBuildDate>
    <atom:link href="https://tommeurs.nl/en/tags/understanding/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>NIS2 for Platform Teams: Which Control Satisfies Which Article</title>
      <link>https://tommeurs.nl/en/posts/nis2-for-platform-teams/</link>
      <pubDate>Sun, 20 Sep 2026 21:00:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/nis2-for-platform-teams/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; The Cyberbeveiligingswet has applied since 15 August 2026. Below, the ten measures of &lt;span class=&#34;def&#34; tabindex=&#34;0&#34; data-def=&#34;Cbw art. 21: the duty of care. Appropriate and proportionate measures, of which paragraph 3 names ten.&#34;&gt;article 21&lt;/span&gt;&#xA; mapped onto controls that actually run, a Kyverno policy that proves one of them, the reporting deadlines as three Prometheus alerting rules, and the four duties no YAML covers. The first run of that policy found seven pods in my own cluster I&amp;rsquo;d have sworn were mirrored.&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>Quantum-safe GPG identity with multiple aliases</title>
      <link>https://tommeurs.nl/en/posts/quantum-safe-gpg-identity/</link>
      <pubDate>Sat, 18 Apr 2026 10:47:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/quantum-safe-gpg-identity/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; One GPG masterkey that only certifies, kept offline. Three aliases bound to it, so anyone can check they&amp;rsquo;re the same person. Ed25519 subkeys for signing and SSH, an ML-KEM plus X448 subkey for encryption so recorded ciphertext stays closed after a quantum computer shows up, and three backups that each assume the other two are gone. Needs GnuPG 2.5.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;A cryptographic signature still means exactly what it says. If the key is yours and the signature verifies, the content came from you. No vendor handed you that identity, no CA can pull it, no platform can suspend it. It exists because you generated the key, and it&amp;rsquo;s yours for as long as you hold the private half. Most of what gets called &amp;ldquo;online identity&amp;rdquo; is borrowed. A handle someone can ban, an email address the domain owner can take back the day they feel like it. A GPG signature sits outside all of that.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Distributed Tracing with Tempo and OpenTelemetry</title>
      <link>https://tommeurs.nl/en/posts/tempo-distributed-tracing/</link>
      <pubDate>Sat, 04 Apr 2026 19:47:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/tempo-distributed-tracing/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; Tempo is where my traces go. The OpenTelemetry Collector receives spans from every service, tail sampling keeps every error and every slow request, and Tempo writes the rest to MinIO with three days of retention. From a span in Grafana I click through to the Loki lines with the same trace ID. My production values are at the bottom.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;Your &lt;a href=&#34;https://tommeurs.nl/en/posts/prometheus-thanos-metrics/&#34;&gt;metrics&lt;/a&gt; say something is slow. Your &lt;a href=&#34;https://tommeurs.nl/en/posts/loki-kubernetes-logging/&#34;&gt;logs&lt;/a&gt; say errors happened. Fine. Which request failed, where did the latency come from, and which service in the chain ate the timeout? Neither of them can tell you.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Simulation, Emulation, Virtualization, and Containers: The Restaurant Metaphor</title>
      <link>https://tommeurs.nl/en/posts/simulation-emulation-virtualization-containers/</link>
      <pubDate>Mon, 23 Feb 2026 20:18:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/simulation-emulation-virtualization-containers/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; Simulation models a thing without running it. Emulation runs it by rebuilding the hardware in software. Virtualization runs several complete operating systems on one machine. Containers run several apps on one kernel. Below, one restaurant per term, a table, and the four mix-ups I hear most.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;&amp;ldquo;So what&amp;rsquo;s the difference between a container and a virtual machine?&amp;rdquo;&lt;/p&gt;&#xA;&lt;p&gt;I get this question a lot, usually from someone smart who&amp;rsquo;s been nodding along in meetings and doesn&amp;rsquo;t quite want to admit they&amp;rsquo;re fuzzy on it. The honest answer is that most explanations make it worse. They open with &amp;ldquo;hypervisor&amp;rdquo;, &amp;ldquo;kernel sharing&amp;rdquo; and &amp;ldquo;hardware abstraction&amp;rdquo;, and now the person has four new terms to be confused about instead of one.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Zero Trust Explained: The Hotel Key Card Metaphor</title>
      <link>https://tommeurs.nl/en/posts/zero-trust-explained/</link>
      <pubDate>Thu, 19 Feb 2026 21:34:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/zero-trust-explained/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; The old model is a castle. Get past the wall and you&amp;rsquo;re trusted everywhere inside. Zero trust is a hotel. Your key card opens your room, the gym if you booked it, and nothing else, and every door checks the card every time. Below, the three principles, a day in that hotel, and what the key card turns into once the doors are software.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;&amp;ldquo;So what is this zero trust thing everyone keeps talking about?&amp;rdquo;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Prometheus and Thanos: Metrics at Scale</title>
      <link>https://tommeurs.nl/en/posts/prometheus-thanos-metrics/</link>
      <pubDate>Sun, 31 Aug 2025 10:00:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/prometheus-thanos-metrics/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; Prometheus on its own keeps a couple of weeks of metrics on local disk and can&amp;rsquo;t answer a question across clusters. Thanos puts a sidecar next to each Prometheus, ships the blocks to object storage, and puts a querier in front that reads all of it back through the same PromQL. Below is the install, the four components, the HA and multi-cluster wiring, and the numbers I run in production.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Runtime Security with Falco: Detect Suspicious Behavior in Your Cluster</title>
      <link>https://tommeurs.nl/en/posts/falco-runtime-security/</link>
      <pubDate>Thu, 07 Aug 2025 10:00:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/falco-runtime-security/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; Trivy and Kyverno check an image before it runs. Falco watches what the container does after that, syscall by syscall, and alerts when the behaviour doesn&amp;rsquo;t match a rule. This post goes from the one thing Falco does to the config I run, with the noise problem in between.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;I scanned my images with &lt;a href=&#34;https://tommeurs.nl/en/posts/trivy-container-scanning/&#34;&gt;Trivy&lt;/a&gt;. I enforced policies with &lt;a href=&#34;https://tommeurs.nl/en/posts/kyverno-policies-governance/&#34;&gt;Kyverno&lt;/a&gt;. My workloads got cryptographic identity through &lt;a href=&#34;https://tommeurs.nl/en/posts/spiffe-spire-zero-trust/&#34;&gt;SPIFFE&lt;/a&gt;. Three layers of prevention, all green, and for a while that felt like enough.&lt;/p&gt;</description>
    </item>
    <item>
      <title>SPIFFE and SPIRE: Zero Trust Service Identity</title>
      <link>https://tommeurs.nl/en/posts/spiffe-spire-zero-trust/</link>
      <pubDate>Sat, 26 Jul 2025 10:00:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/spiffe-spire-zero-trust/</guid>
      <description>&lt;p&gt;How does Service A know that Service B is actually Service B?&lt;/p&gt;&#xA;&lt;p&gt;I keep coming back to that question because the usual answer is uncomfortable. For years we trusted network location. Traffic from the right IP was legitimate, end of story. Zero trust took that assumption out back and shot it. Now every service has to prove who it is, every single request, no matter where it sits on the network.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How etcd Actually Works: The Heart of Your Kubernetes Cluster</title>
      <link>https://tommeurs.nl/en/posts/etcd-deep-dive/</link>
      <pubDate>Mon, 27 Jan 2025 21:47:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/etcd-deep-dive/</guid>
      <description>&lt;p&gt;When something goes wrong in Kubernetes, the trail usually leads back to etcd. API server timing out? Check etcd. Pods stuck in pending? Might be etcd. Cluster feels sluggish? Probably etcd.&lt;/p&gt;&#xA;&lt;p&gt;For a long time I treated etcd the way most operators do: as a black box that hums along next to the control plane. &amp;ldquo;The database.&amp;rdquo; You back it up and otherwise leave it alone. But black boxes feel like splinters to me, and the first time an etcd cluster fell over at 2am I realised I had no idea what I was actually looking at. So I learned. And it turns out the whole thing is built on a handful of ideas that, once they click, make most etcd problems diagnosable instead of terrifying.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
