python
python copied to clipboard
kubernetes-client
Implement an Informer in python-client
https://github.com/kubernetes/client-go has an Informer implementation. Internally it leverages a watcher of some collection of resources, continually streams changes (add/modify/delete events), reflects the resources into a downstream store (cache), handles connectivity drops, and periodically does a full resync. This all happens on some background thread (goroutine). A client of the informer is free to iterate over that stored cache without concern for how it's populated, and immediately get (possibly outdated) state.
Applications using https://github.com/kubernetes-client/python that want a local store of resources reflecting some in-cluster state need to concern themselves with those lower-level details. There's a lot of room for error.
On 2019-06-25, go#28 added a simple informer implementation to the openapi-generated client for Golang. It defines a Cache struct, with both a list of all objects and event handler callbacks that a consumer could register.
https://github.com/kubernetes-client/python should contain a similar implementation.
People have been talking about this a bit in various places.
- kubernetes-client/go#28 is a PR adding a simple informer implementation to the openapi-generated client for Golang (in contrast to the more mature https://github.com/kubernetes/client-go).
- kubernetes-client/python#124 is about reconnection, no cache
- kubernetes-client/python#334 is about a sample controller and briefly discusses the lack of an informer
- bazelbuild/rules_k8s#55 doesn't implement a cache; it's an example of a watch
- https://borismattijssen.github.io/articles/kubernetes-informers-controllers-reflectors-stores has a nice high-level description of the whole flow from the perspective of consuming the client-go implementation
- https://kubernetes.slack.com/archives/C0EG7JC6T/p1520698801000158 has @marcellodesales and @liggitt discussing options in 2018-March
- https://kubernetes.slack.com/archives/C09NXKJKA/p1504044752000260 is confusion from @dimberman about the lack of a python informer in 2017-August
https://github.com/kubernetes-client/python should contain a similar implementation.
Philosophical consensus: should the openapi-generated client libraries contain implementations of higher-level abstractions like this?
I wrote a SharedIndexInformer in Python after ~4000 lines of code including tests by directly translating it, its dependencies, and unit tests from client-go. I could share it but would want to be sure licensing/copyright isn't an issue; maybe it's ok as long as the "Kubernetes Authors" license header is on each translated file and the license is Apache? Also, I'm not sure if it's fit for this client:
- It uses asyncio (and isn't thread-safe) and currently requires Python 3.7. I think it would make sense to add types because it's relatively complex
- The APIs would need some work. They aren't always Pythonic because I focused on translating it first
- I got an example working with a kind cluster but haven't tried to measure its performance. There may be stray tasks as of now
- I'm missing context about client-go such as knowledge about technical debt that shouldn't be replicated. In general I'm not sure if it makes sense to maintain a Python version of DeltaFIFO, Reflector, and SharedIndexInformer...
Is there any interest in such a translation? Would licensing be a concern?
@alanjcastonguay if you aren't actively working on this, it may make sense to un-assign yourself from this issue. That way any would-be contributors won't have to wonder whether work is in progress before making their own attempt.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
I pushed hacky junk to https://github.com/alanjcastonguay/python-base/commits/master - anyone want to help?
There's a lot at https://github.com/tbarrella/aiok8s, although I realized I probably won't be able to maintain it right now...
I'm working on hacking together an informer-like object for kubernetes_asyncio. If it turns into something useful I'll publish it and link it here for reference.
Regarding the comment above:
Philosophical consensus: should the openapi-generated client libraries contain implementations of higher-level abstractions like this?
Have there been any discussions about this?
IMO it should be a part of the library. We already have such high-level abstractions like recently added Leader-Election or applying manifests from yaml files etc.
The kopf's has a watch implementation that is claimed to be informer-equivalent, which may be interesting to look into.
fwiw (since I just noticed this issue) there are Informers for both the Java (https://github.com/kubernetes-client/java/tree/master/util/src/main/java/io/kubernetes/client/informer) and JavaScript (https://github.com/kubernetes-client/javascript/blob/master/src/informer.ts) client libraries.
I'm kind of suprised by how long this has been open, given that the Python client is one of the officially supported ones for K8s. I had naievely expected that official support would imply approximate feature parity across the different languages, but in tihs case it does not. (All the other officially supported client libraries, except the Haskel one, have Informer support).
Also, the difference between repeated LIST class vs an Informer can be significant in terms of API server load and performance.
Does anyone on this thread have any updates on whether this issue may be resolved soon?
