<p>I'm not quite sure if which of the following approaches is the better approach to create a controller in kubernetes however I know that:</p>
<ul>
<li>I don't want to create a custom resource by any means.</li>
<li>I do only want to fetch information about k8s native resources (pods, ...) given that there might be a lot of pods in each namespace</li>
</ul>
<p>I have seens some patterns like:</p>
<pre><code>ctrl, err := controller.New(&quot;name-here&quot;, mgr, controller.Options{
    Reconciler: &amp;ReconcilePod{Client: mgr.GetClient(), Logger: log},
})
</code></pre>
<p>which <code>ReconcilePod</code> is a struct that has a function <code>Reconcile</code> that keep whole business logic.</p>
<p>Another approach I have seens is like following:</p>
<pre><code>type Controller struct {
    indexer  cache.Indexer
    queue    workqueue.RateLimitingInterface
    informer cache.Controller
}
</code></pre>
<p>and then defining <code>shared informer</code> and <code>watcher</code> etc.
And the third pattern that I have seen is using <code>operators</code></p>
<p>what I don't get perhaps is what is the main differences between mentioned approaches above and which one fits my need at scale.</p>

<p>If you don't want to &quot;control&quot; anything, there is no need to create a <em>controller</em>.</p>
<p>If you just want to &quot;read&quot; and &quot;watch&quot; resources, you can use <a href="https://github.com/kubernetes/client-go" rel="nofollow noreferrer">client-go</a> and see e.g. <a href="https://www.cncf.io/blog/2019/10/15/extend-kubernetes-via-a-shared-informer/" rel="nofollow noreferrer">Extend Kubernetes via a shared informer</a> for inspiration about how to <em>read</em> and <em>watch</em> resources.</p>
<blockquote>
<p>To stay informed about when these events get triggered you can use a primitive exposed by Kubernetes and the client-go called SharedInformer, inside the cache package. Let’s see how it works in practice.</p>
</blockquote>
<p>Controllers are more complex and contains a <em>reconciliation loop</em> since they should realize/manage a <em>desired state</em>.</p>
<p>An &quot;operator&quot; is a <em>controller</em> as well.</p>
