<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Image-Builds on Agent Zone</title><link>https://agent-zone.ai/tags/image-builds/</link><description>Recent content in Image-Builds on Agent Zone</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 07 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://agent-zone.ai/tags/image-builds/index.xml" rel="self" type="application/rss+xml"/><item><title>Minikube docker-env: Building Images Directly into the Cluster Runtime</title><link>https://agent-zone.ai/knowledge/kubernetes/minikube-docker-env-in-cluster-builds/</link><pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate><guid>https://agent-zone.ai/knowledge/kubernetes/minikube-docker-env-in-cluster-builds/</guid><description>&lt;p&gt;&lt;code&gt;eval $(minikube docker-env)&lt;/code&gt; repoints the shell&amp;rsquo;s Docker client at the daemon running inside the minikube VM. A &lt;code&gt;docker build&lt;/code&gt; afterwards lands the image directly in the cluster&amp;rsquo;s container store, so pods can pull it without a registry. The pattern is correct but unforgiving: every failure mode looks like a different problem (image pull error, runtime crash, stale pod) and only a handful of them actually point back to the env-var setup.&lt;/p&gt;</description></item></channel></rss>