<p>I am new to the custom controllers and trying to understand this. I have started referring the sample-controller but unable to find much difference or understand properly in between the example files</p>
<ol>
<li><a href="https://github.com/kubernetes/sample-controller/blob/master/artifacts/examples/crd.yaml" rel="nofollow noreferrer">https://github.com/kubernetes/sample-controller/blob/master/artifacts/examples/crd.yaml</a></li>
<li><a href="https://github.com/kubernetes/sample-controller/blob/master/artifacts/examples/crd-status-subresource.yaml" rel="nofollow noreferrer">https://github.com/kubernetes/sample-controller/blob/master/artifacts/examples/crd-status-subresource.yaml</a></li>
</ol>
<p>Both the files look similar to me except for the below part in crd-status-subresource.yaml.</p>
<pre><code>subresources:
  status: {}
</code></pre>
<p>Can anyone help or give suggestions on this to proceed. ?</p>

john snowker
<p>Just to be on the same page, here is a quick summary of what a controller in Kubernetes does:</p>
<p>It watches over a certain state - usually, CustomResources (CRs) that can be defined using CustomResourceDefinitions (CRDs) - and performs actions based on rules that you define inside your code.</p>
<blockquote>
<p>I have started referring the sample-controller but unable to find much difference or understand properly in between the example files</p>
</blockquote>
<p>The files you are referring to do not have any difference other than what you already pointed out, so there truly is nothing more to look for.</p>
<p>If you take a detailed look at a native Kubernetes object such as a Pod (<code>kubectl get pod &lt;some-pod&gt; -o yaml</code>) you will see that it has a <code>.status</code> field which simply stores additional information. By enabling the <code>status</code> subresource you are telling Kubernetes to create a CR where you can then go ahead and edit that additional <code>.status</code> field by accessing a new REST API path: <code>/apis/&lt;group&gt;/&lt;version-name&gt;/namespaces/*/&lt;kind&gt;/status</code>. If you don't need it, then don't define it, that's it.</p>
<p>As to why one may want to add the <code>status</code> subresource depends on the use-case of the CR. Sometimes you simply want to have a more verbose field to store information in for a user to look at and sometimes you are telling your controller to fetch data from there as it represents the current status of the object. Just take a look at a Pods <code>.status</code> field and you will see some nice additional data in there such as if the Pod is <code>Ready</code>, information about the containers, and so on.</p>
<p>With that being said, <code>status</code> is not the only subresource. You may also want to take a look at the <code>scale</code> subresource as well (depending on the use-case). For more information regarding subresources you can refer to: <a href="https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#subresources" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#subresources</a></p>
