<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Kubernetes on Ashish Jaiswal</title>
    <link>https://ashish1099.me/tags/kubernetes/</link>
    <description>Recent content in Kubernetes on Ashish Jaiswal</description>
    <generator>Hugo -- 0.147.0</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 08 Apr 2026 09:00:00 +0530</lastBuildDate>
    <atom:link href="https://ashish1099.me/tags/kubernetes/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Obmondo Code: An AI-Powered SRE Alert Diagnosis CLI</title>
      <link>https://ashish1099.me/posts/obmondo-code-sre-alert-diagnosis-cli/</link>
      <pubDate>Wed, 08 Apr 2026 09:00:00 +0530</pubDate>
      <guid>https://ashish1099.me/posts/obmondo-code-sre-alert-diagnosis-cli/</guid>
      <description>A walkthrough of Obmondo Code, an SRE co-pilot CLI built in Go that connects an AI agent to 290+ diagnostic runbooks, SSH command execution, Gitea issue parsing, and time registration — with a strict safety model baked into every layer.</description>
    </item>
    <item>
      <title>Building a PR Review Bot Under 32K Context: Go AST Diffing, YAML Key Diffing, and Smart Truncation</title>
      <link>https://ashish1099.me/posts/pr-review-bot-go-ast-small-context-window/</link>
      <pubDate>Wed, 08 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://ashish1099.me/posts/pr-review-bot-go-ast-small-context-window/</guid>
      <description>Artoo, Obmondo&amp;rsquo;s Mattermost bot, got a PR review engine that runs on a self-hosted Qwen3-14B with a ~32K context window. The key problem: a single Kubernetes PR can have 10,000+ lines of diff. The solution: Go pre-processing that compresses diffs to ~2KB before the LLM ever sees them — using go/ast for Go files, YAML key-level diffing for Helm/K8s configs, and priority-based file truncation. This post covers why each decision was made and what the LLM still cannot do.</description>
    </item>
    <item>
      <title>Cilium on Bare Metal: How UFW Silently Breaks CoreDNS and kube-apiserver Connectivity</title>
      <link>https://ashish1099.me/posts/cilium-bare-metal-ufw-coredns-kube-apiserver/</link>
      <pubDate>Thu, 19 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://ashish1099.me/posts/cilium-bare-metal-ufw-coredns-kube-apiserver/</guid>
      <description>&lt;h2 id=&#34;the-symptom&#34;&gt;The Symptom&lt;/h2&gt;
&lt;p&gt;After standing up a Kubernetes cluster on a bare-metal node with Cilium as the CNI, CoreDNS pods were
running but completely unable to reach the kube-apiserver service IP (&lt;code&gt;10.96.0.1&lt;/code&gt;). DNS resolution inside
the cluster was broken, and any pod trying to talk to the API server via the service IP timed out.&lt;/p&gt;
&lt;p&gt;The apiserver itself was healthy — direct connections to the node&amp;rsquo;s IP worked fine. The problem was
specifically with the virtual service IP routed through Cilium&amp;rsquo;s BPF dataplane.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Why Your RPM Host Showed 0 CVEs: Fixing Vuls Package Parsing in security-exporter</title>
      <link>https://ashish1099.me/posts/rpm-cve-detection-vuls2-security-exporter/</link>
      <pubDate>Fri, 13 Mar 2026 09:00:00 +0530</pubDate>
      <guid>https://ashish1099.me/posts/rpm-cve-detection-vuls2-security-exporter/</guid>
      <description>security-exporter returned 0 CVEs on every CentOS and RHEL host. The root cause was a silent data drop: ParsePackages silently skips any line that does not match its exact tab-separated format, and our rpm collector was producing the wrong format. This post covers the full diagnosis, the fix using the vuls-recommended 6-field rpm query, source package extraction using the NVR last-two-hyphens algorithm, and the Helm chart simplification that removed the entire legacy go-cve-dictionary + PostgreSQL pipeline.</description>
    </item>
  </channel>
</rss>
