What is the difference between crd.yaml and crd-status-subresource.yaml?

Question

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

1. https://github.com/kubernetes/sample-controller/blob/master/artifacts/examples/crd.yaml
2. https://github.com/kubernetes/sample-controller/blob/master/artifacts/examples/crd-status-subresource.yaml

Both the files look similar to me except for the below part in crd-status-subresource.yaml.

subresources:
  status: {}

Can anyone help or give suggestions on this to proceed. ?

Answer 1

Just to be on the same page, here is a quick summary of what a controller in Kubernetes does:

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.

I have started referring the sample-controller but unable to find much difference or understand properly in between the example files

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.

If you take a detailed look at a native Kubernetes object such as a Pod (kubectl get pod <some-pod> -o yaml) you will see that it has a .status field which simply stores additional information. By enabling the status subresource you are telling Kubernetes to create a CR where you can then go ahead and edit that additional .status field by accessing a new REST API path: /apis/<group>/<version-name>/namespaces/*/<kind>/status. If you don't need it, then don't define it, that's it.

As to why one may want to add the status 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 .status field and you will see some nice additional data in there such as if the Pod is Ready, information about the containers, and so on.

With that being said, status is not the only subresource. You may also want to take a look at the scale subresource as well (depending on the use-case). For more information regarding subresources you can refer to: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#subresources