<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Lens on VisorCraft News</title><link>https://www.visorcraft.com/news/tags/lens/</link><description>Recent content in Lens on VisorCraft News</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Thu, 13 Aug 2026 10:00:00 -0500</lastBuildDate><atom:link href="https://www.visorcraft.com/news/tags/lens/index.xml" rel="self" type="application/rss+xml"/><item><title>Mongrel vs Lens Desktop: Kubernetes in the Full Investigation Context</title><link>https://www.visorcraft.com/news/2026/08/mongrel-vs-lens-kubernetes-investigation-workbench/</link><pubDate>Thu, 13 Aug 2026 10:00:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/08/mongrel-vs-lens-kubernetes-investigation-workbench/</guid><description>&lt;h2 id="the-cluster-is-never-alone"&gt;The Cluster Is Never Alone&lt;/h2&gt;
&lt;p&gt;When an operator traces a production incident, the cluster is usually the most visible surface, but it is rarely the only surface. A failing pod might be throttling because the database connection pool is exhausted, or a service might be retrying because a downstream API is returning unexpected error shapes, or a deployment might be misconfigured because someone edited a Helm value that conflicted with an operator&amp;rsquo;s CRD. Each of these scenarios involves the cluster, yes, but they also involve the database, the HTTP endpoint, the container runtime, and the shell where you paste the YAML you are about to apply. A tool that knows only the cluster forces you to context-switch through separate applications to build the complete picture.&lt;/p&gt;</description></item></channel></rss>