<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>GitOps on Landry Zetam - Tech Blog</title><link>https://blog.landryzetam.net/tags/gitops/</link><description>Recent content in GitOps on Landry Zetam - Tech Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Mon, 10 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.landryzetam.net/tags/gitops/index.xml" rel="self" type="application/rss+xml"/><item><title>The Full Architecture of My Kubernetes Agents</title><link>https://blog.landryzetam.net/posts/kubernetes-agents-full-architecture/</link><pubDate>Mon, 10 Aug 2026 00:00:00 +0000</pubDate><guid>https://blog.landryzetam.net/posts/kubernetes-agents-full-architecture/</guid><description>&lt;p>Five agents run against my K3s cluster. Three of them form a closed loop — one detects problems, one fixes them, one reviews the fix — and none of the three can do another&amp;rsquo;s job. This is everything about how they&amp;rsquo;re built: the framework, the prompt assembly, every tool, both safety gates, the memory layers, and a real pull request one of them opened.&lt;/p>
&lt;p>Then I merged it and spent a day fixing what production found. Eight more bugs, none of them in the agent logic — §17 onward is that day, and it&amp;rsquo;s the more useful half.&lt;/p></description></item><item><title>GitOps Framework: How the Fako Cluster Repository is Organized</title><link>https://blog.landryzetam.net/posts/gitops-framework/</link><pubDate>Sun, 21 Dec 2025 00:00:00 +0000</pubDate><guid>https://blog.landryzetam.net/posts/gitops-framework/</guid><description>&lt;h2 id="overview">Overview&lt;/h2>
&lt;p>The Fako Cluster uses a GitOps approach where &lt;strong>Git is the single source of truth&lt;/strong> for all cluster state. Every deployment, configuration change, and infrastructure update flows through Git commits. FluxCD watches the repository and automatically reconciles the cluster to match the desired state defined in code.&lt;/p>
&lt;p>This post explains the repository structure, the reasoning behind each directory, and how the pieces work together.&lt;/p>
&lt;h2 id="repository-structure">Repository Structure&lt;/h2>
&lt;pre tabindex="0">&lt;code>fako-cluster/
├── apps/ # Application deployments
│ ├── base/ # Base Kustomize configurations
│ └── staging/ # Environment overlay (what actually deploys)
├── clusters/ # Cluster bootstrap and Flux config
│ └── staging/ # Flux Kustomizations that orchestrate everything
├── infrastructure/ # Platform components
│ ├── controllers/ # Operators (Cert-Manager, CloudNative-PG, etc.)
│ └── configs/ # Configuration for controllers
├── monitoring/ # Observability stack
│ ├── controllers/ # Prometheus, Loki, Grafana, etc.
│ └── configs/ # Dashboards, alerting rules
├── scripts/ # Deployment and maintenance scripts
└── notes/ # Documentation and troubleshooting
&lt;/code>&lt;/pre>&lt;h2 id="the-basestaging-pattern">The Base/Staging Pattern&lt;/h2>
&lt;p>The most important concept to understand is the &lt;strong>base/staging pattern&lt;/strong> used throughout the repository.&lt;/p></description></item><item><title>From Transcripts to Summaries: Completing the Audio Pipeline</title><link>https://blog.landryzetam.net/posts/transcripts-to-summaries-audio-pipeline/</link><pubDate>Sat, 20 Dec 2025 00:00:00 +0000</pubDate><guid>https://blog.landryzetam.net/posts/transcripts-to-summaries-audio-pipeline/</guid><description>&lt;p>Remember that audio transcription pipeline I built? Raw recordings flow in, get compressed, transcribed by Whisper, and stored as JSON. Great for archival, but 204 transcript files sitting on NFS storage aren&amp;rsquo;t exactly useful. Today I&amp;rsquo;ll show you how I completed the loop—automatically summarizing transcripts with an LLM and publishing everything to my Obsidian vault.&lt;/p>
&lt;hr>
&lt;h2 id="part-1-the-problem-with-raw-transcripts">Part 1: The Problem with Raw Transcripts&lt;/h2>
&lt;p>The original pipeline worked beautifully. Every morning, new transcripts appeared as JSON files:&lt;/p></description></item><item><title>Complete Kubernetes Security Pipeline - Kube-bench and Kubescape to Obsidian</title><link>https://blog.landryzetam.net/posts/kubernetes-security-pipeline-kubebench-kubescape/</link><pubDate>Fri, 19 Dec 2025 00:00:00 +0000</pubDate><guid>https://blog.landryzetam.net/posts/kubernetes-security-pipeline-kubebench-kubescape/</guid><description>&lt;p>What if your Kubernetes cluster could write comprehensive security reports directly into your second brain every night? Not just one perspective, but two complementary views: infrastructure security &lt;em>and&lt;/em> workload security. I built exactly that—a pipeline combining kube-bench (CIS benchmarks) and kubescape (NSA/MITRE frameworks) that publishes human-readable reports to Obsidian automatically. Here&amp;rsquo;s how the complete system works.&lt;/p>
&lt;hr>
&lt;h2 id="part-1-why-you-need-both-tools">Part 1: Why You Need Both Tools&lt;/h2>
&lt;h3 id="the-security-visibility-gap">The Security Visibility Gap&lt;/h3>
&lt;p>Running a Kubernetes homelab means wearing many hats. Security scanning tools exist, but most people either:&lt;/p></description></item><item><title>Prometheus WAL Replay: When Your Metrics Database Can't Start Fast Enough</title><link>https://blog.landryzetam.net/posts/prometheus-wal-replay/</link><pubDate>Thu, 18 Dec 2025 00:00:00 +0000</pubDate><guid>https://blog.landryzetam.net/posts/prometheus-wal-replay/</guid><description>&lt;p>There&amp;rsquo;s a special kind of frustration that comes from watching a pod restart 90 times over 37 hours, each time getting &lt;em>just&lt;/em> a little further before Kubernetes kills it again. Today I debugged a Prometheus instance stuck in an infinite crash loop, and the root cause was surprisingly subtle: the database was simply too large to start within the default health check window.&lt;/p>
&lt;p>This is the story of startup probes, Write-Ahead Logs, and why your monitoring system might be the hardest thing to monitor.&lt;/p></description></item><item><title>Building a Kubernetes Security Reporter for Obsidian</title><link>https://blog.landryzetam.net/posts/kubernetes-security-reporter-obsidian/</link><pubDate>Wed, 17 Dec 2025 00:00:00 +0000</pubDate><guid>https://blog.landryzetam.net/posts/kubernetes-security-reporter-obsidian/</guid><description>&lt;p>What if your Kubernetes cluster could automatically write security reports directly into your second brain? Today I built exactly that—a system that runs CIS benchmark scans against my K3s cluster and publishes the results as beautifully formatted Obsidian notes. No more checking dashboards or parsing JSON files; just open your vault and see your cluster&amp;rsquo;s security posture.&lt;/p>
&lt;hr>
&lt;h2 id="part-1-the-problem">Part 1: The Problem&lt;/h2>
&lt;h3 id="security-visibility-in-a-homelab">Security Visibility in a Homelab&lt;/h3>
&lt;p>Running a Kubernetes homelab means wearing many hats: developer, operator, and security engineer. Tools like &lt;a href="https://github.com/aquasecurity/kube-bench">kube-bench&lt;/a> exist to scan your cluster against CIS benchmarks, but they typically output JSON or text that sits in a PersistentVolume gathering dust.&lt;/p></description></item><item><title>Building an Automated Audio Transcription Pipeline on Kubernetes</title><link>https://blog.landryzetam.net/posts/audio-transcription-pipeline/</link><pubDate>Fri, 12 Dec 2025 00:00:00 +0000</pubDate><guid>https://blog.landryzetam.net/posts/audio-transcription-pipeline/</guid><description>&lt;p>Every day, raw audio recordings land on an SFTP server. By morning, they&amp;rsquo;re compressed, transcribed, and stored as searchable JSON - all without human intervention. Here&amp;rsquo;s how I built this pipeline on my homelab Kubernetes cluster.&lt;/p>
&lt;h2 id="the-problem">The Problem&lt;/h2>
&lt;p>I had a growing collection of audio recordings that needed transcription. Manual processing wasn&amp;rsquo;t sustainable: download files, compress them, run through a transcription service, organize the output. This needed automation.&lt;/p>
&lt;p>The requirements were straightforward:&lt;/p></description></item><item><title>From GitHub Notes to Production Blog</title><link>https://blog.landryzetam.net/posts/hugo-blogging/</link><pubDate>Thu, 07 Aug 2025 00:00:00 +0000</pubDate><guid>https://blog.landryzetam.net/posts/hugo-blogging/</guid><description>&lt;h2 id="why-this-guide-exists">Why This Guide Exists&lt;/h2>
&lt;p>I&amp;rsquo;ve been doing a lot of dev work, research and hadn&amp;rsquo;t really thought about sharing the knowledge without having to learn frontend development or maintain complex code. I knew I had a bunch of markdown GitHub notes and thought they could be used as a baseline to catch up on all my lack of documentation. Then I found Hugo.&lt;/p>
&lt;p>This guide covers the entire workflow of creating a Hugo blog, containerizing it, and deploying it to Kubernetes - all without writing a single line of frontend code (html, css, js).&lt;/p></description></item><item><title>Running 184 Pods on a 6-Node K3s Homelab Cluster</title><link>https://blog.landryzetam.net/posts/k8s/</link><pubDate>Thu, 07 Aug 2025 00:00:00 +0000</pubDate><guid>https://blog.landryzetam.net/posts/k8s/</guid><description>&lt;h2 id="project-overview">Project Overview&lt;/h2>
&lt;p>The Fako Cluster is my production Kubernetes environment that serves as the foundation for all other projects. It&amp;rsquo;s a self-hosted, production-grade K8s cluster that demonstrates enterprise-level practices while running on homelab hardware.&lt;/p>
&lt;h3 id="why-fako">Why &amp;ldquo;Fako&amp;rdquo;?&lt;/h3>
&lt;p>The name &amp;ldquo;Fako&amp;rdquo; holds special significance - it&amp;rsquo;s named after Mount Fako (Mount Cameroon), the highest peak in West and Central Africa. Just as Mount Fako stands as a towering landmark visible from miles away, this Kubernetes cluster serves as the foundational infrastructure that all other services can rely on.&lt;/p></description></item><item><title>Securing GitOps: SOPS Secret Management in k8s with FluxCD</title><link>https://blog.landryzetam.net/posts/secrets-management-with-sops-flux-gitops/</link><pubDate>Thu, 07 Aug 2025 00:00:00 +0000</pubDate><guid>https://blog.landryzetam.net/posts/secrets-management-with-sops-flux-gitops/</guid><description>&lt;h2 id="the-problem-secrets-in-gitops">The Problem: Secrets in GitOps&lt;/h2>
&lt;p>When I started my Kubernetes homelab journey, I quickly hit a wall that every GitOps practitioner faces: &lt;strong>How do you store secrets in Git without compromising security?&lt;/strong>&lt;/p>
&lt;p>The GitOps philosophy is beautifully simple - everything should be in Git. Your entire cluster state, all your applications, configurations, and yes, even secrets. But committing passwords, API keys, and certificates to a public (or even private) repository feels fundamentally wrong. It is wrong.&lt;/p></description></item><item><title>GitOps in Practice: Managing k8s with FluxCD</title><link>https://blog.landryzetam.net/posts/gitops-with-fluxcd/</link><pubDate>Wed, 06 Aug 2025 00:00:00 +0000</pubDate><guid>https://blog.landryzetam.net/posts/gitops-with-fluxcd/</guid><description>&lt;p>After running the Fako Cluster for several months, I can confidently say that adopting GitOps with FluxCD has been one of the best decisions for managing my Kubernetes infrastructure. In this post, I&amp;rsquo;ll share practical insights and patterns that have proven invaluable.&lt;/p>
&lt;h2 id="what-is-gitops">What is GitOps?&lt;/h2>
&lt;p>GitOps is a way of implementing Continuous Deployment for cloud native applications.
FluxCD is designed to simplify that, making it easier than ever to manage your Kubernetes environments. Here’s why i leverage it in my workflow:&lt;/p></description></item></channel></rss>