kube-watch
kube-watch copied to clipboard
Events getting queued up or not returned immediately
This is a common issue I've noticed amongst Kubernetes clients that integrate the watch API, the stream appears to not read in the entire buffer and doesn't return the most recent event. This is the workflow where I experience this:
- Create new pod - 'added' event triggers just fine.
- Delete existing pod - no events triggered
- Create new pod again - 'added' event triggers, followed by 'deleted' event for previously deleted pod
There is a similar discussion about this exact problem, albeit surrounding Python - https://cobe.io/blog/posts/kubernetes-watch-python/
Please disregard this issue, updating my local kubectl
version remedied this problem.
Previous version:
Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.0", GitCommit:"283137936a498aed572ee22af6774b6fb6e9fd94", GitTreeState:"clean", BuildDate:"2016-07-01T19:26:38Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.3", GitCommit:"4957b090e9a4f6a68b4a40375408fdc74a212260", GitTreeState:"clean", BuildDate:"1970-01-01T00:00:00Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"}
Updated version:
Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.3", GitCommit:"4957b090e9a4f6a68b4a40375408fdc74a212260", GitTreeState:"clean", BuildDate:"2016-10-16T06:36:33Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.3", GitCommit:"4957b090e9a4f6a68b4a40375408fdc74a212260", GitTreeState:"clean", BuildDate:"1970-01-01T00:00:00Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"}
@thenayr I'm seeing this same issue - even though I'm on the latest kubectl version.. the events seems to be staggered. I've seen this with this module as well as when implementing my own login using REST (w/ node) I'm only receiving partial events, and the missing events only come in with the next kubectl operation.
I'm seeing this work correctly against minikube, so I'm wondering if there is something else going on as well. Have you experienced any more issues or discovered any other reasonings/solutions on why this occurs?
@sppatel I can only really point you at some (relatively) outdated code that I put together for managing the event stream Here
I believe I ended up using https://github.com/godaddy/kubernetes-client as my k8s client in the end, although it was for reasons that have escaped my memory at this point.
One other gotcha that I would say to look out for is that the event stream will eventually time out at some point. This is due to the connection timeout configured somewhere in your Kubernetes API settings.
I captured most of this on a blog post here, hope it helps.