<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kine on Rusty Bower</title><link>https://www.rustybower.com/tags/kine/</link><description>Recent content in Kine on Rusty Bower</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© Rusty Bower</copyright><lastBuildDate>Tue, 08 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.rustybower.com/tags/kine/index.xml" rel="self" type="application/rss+xml"/><item><title>How K3s Silently Grew a 40 GB SQLite Database and Took Down My Cluster</title><link>https://www.rustybower.com/posts/k3s-sqlite-kine-40gb-database-compaction/</link><pubDate>Tue, 08 Sep 2026 00:00:00 +0000</pubDate><guid>https://www.rustybower.com/posts/k3s-sqlite-kine-40gb-database-compaction/</guid><description>&lt;p&gt;My cluster — a single-node K3s instance running about 60 ArgoCD-managed applications — had been slowly dying for months. Pods crash-looped with &amp;ldquo;context deadline exceeded&amp;rdquo; errors. Leader elections failed. The metrics server stopped working entirely. I assumed it was resource pressure and tuned probe timeouts. The real problem was underneath all of it: K3s&amp;rsquo;s SQLite datastore had silently grown to 40 GB.&lt;/p&gt;</description></item></channel></rss>