CRD are managed by a controller specific to that CRD.
Validation of an object concerning the CRD is achieved through a service that takes a call from the API, in this case validation would work along these lines, admission controller validating webhook
More generally, your CRD does not need to concern itself with podspec per se. The CRD is just some declarative representation of the resource you want your controller to manage.
Extending the k8s api mostly works something like this;
- think up some bundled functionality you would like to represent declaratively in one schema (the CRD)
- create a controller that handles your CRD
- add some validation to make sure the API will reject objects that will confuse the controller you made, and hook it up to the API by way of the Dynamic Admission Control
- your controller manages the resources required to fullfil the functionality described
I'm sure you could use a podspec in your CRD, but I wouldn't. Generally that's an abstraction better left to the controller managing that specific resource.