kube-watch icon indicating copy to clipboard operation
kube-watch copied to clipboard

Events getting queued up or not returned immediately

Open thenayr opened this issue 8 years ago • 3 comments

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/

thenayr avatar Nov 02 '16 15:11 thenayr

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 avatar Nov 02 '16 17:11 thenayr

@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 avatar Aug 16 '17 22:08 sppatel

@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.

thenayr avatar Aug 17 '17 03:08 thenayr