<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Registry on Krkn</title><link>https://krkn-chaos.dev/tags/registry/</link><description>Recent content in Registry on Krkn</description><generator>Hugo</generator><language>en</language><atom:link href="https://krkn-chaos.dev/tags/registry/index.xml" rel="self" type="application/rss+xml"/><item><title>Publish and Run with Krkn Operator</title><link>https://krkn-chaos.dev/docs/developers-guide/custom-scenario/operator-lab/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://krkn-chaos.dev/docs/developers-guide/custom-scenario/operator-lab/</guid><description>&lt;p>&lt;strong>Starting point:&lt;/strong> the &lt;a href="https://krkn-chaos.dev/docs/developers-guide/custom-scenario/package-and-test/">scenario image passes its local tests&lt;/a>.
&lt;strong>Result:&lt;/strong> the operator discovers the image, renders its two inputs, and runs
it against a target you have already registered.&lt;/p>
&lt;p>The management cluster hosts the registry, operator, and scenario Pods. The
target&amp;rsquo;s kubeconfig is mounted into each scenario Pod. You do not need to place
the private registry on the target or configure the target&amp;rsquo;s runtime to pull
this scenario image.&lt;/p>
&lt;figure>&lt;a href="https://krkn-chaos.dev/images/developers-guide/registry-access.svg">&lt;img src="https://krkn-chaos.dev/images/developers-guide/registry-access.svg"
 alt="Podman pushes to localhost port 5001, which maps to the Kind registry NodePort 30500. Inside Kind, the operator reads metadata and containerd pulls image layers through separate HTTP connections to the stable node hostname. The scenario Pod then uses a mounted kubeconfig to reach the target API.">&lt;/a>&lt;figcaption>
 &lt;p>One registry, two client configurations. Select the diagram to view it at full size.&lt;/p></description></item></channel></rss>