Support for built-in resources (pods, jobs, etc)

[nolar]

Expected Behaviour

Kopf should be able to handle the built-in resources, like pods, jobs, pvcs, etc. — Both in the spy-handlers (#30) and in the regular handlers (if decided so).

Actual Behaviour

Currently, Kopf is only able to serve the custom resources — because it uses the kubernetes.client.CustomObjectsApi API (for watching & for patching).

Suggestions

Maybe, pykube-ng can be beneficial here, as it has a nice syntax to operate on all the resources, built-in and custom. See #15. With the official Kubernetes client, we have to implement our own branching on the object kind, and using the proper class+methods for every kind — basically turning Kopf into a Kubernetes client library, which is not the goal.

Maybe, a pre-scan of the cluster would be needed to identify all the existing resources. See #57.

Specifications

kopf==0.13

[nolar]

Quick-check results:

It might look like a good idea to use CustomObjectsApi() for the built-in resources too, e.g. @kopf.on.event('', 'v1', 'pods') — as an expected semantics. Sadly so, the resulting URLs are different:

Built-in V1 pods URL: /api/v1/namespaces/default/pods
Via custom resources: /apis//v1/namespaces/default/pods

First of all, the /api vs /apis is a problem, which leads to "404 Not Found".
Second, the double-slash // is a problem, it also returns "404 Not Found" (event with /api/).
When both of these are hacked, it works as expected.

The URL parts are quoted, so it is impossible to do anything like @kopf.on.event('../api', 'v1', 'pods'), as the resulting URL becomes /apis/..%2Fapi/v1/namespaces/default/pods.

---

Which means, there is no easy hack in Kopf itself to get to the built-in resources with the official client with all the hard-coded URLs. Runtime monkey-patching of the client library might be a bad idea for the stability of the Kopf-based operators that use this library.

So, the choice is either to map every known builtin resource to proper classes&methods, which means making Kopf into a Kubernetes client library (which is not the framework's mission), or using another Kubernetes client with dynamic mapping of any resources, builtin and custom, via the same interface.

[nolar]

This is actually solved in #15 as a side-effect (but needs to be merged first).

[cliffburdick]

@nolar is there an example of watching a pod under a parent crd? I noticed you sketched ideas in several issues, but I'm not sure which you ended up on.