Reflectors Vs Watchers

[DevasiaThomas]

My intention is to get event notifications for whenever a, for eg,, Pod is touched( added, modified or deleted), which I believe this library categorizes into Applied and Deleted, and emit the same out. I also noticed the Restart event. Is this for when the underlying connection gets disrupted, or some error happens, and you fetch everything again?

To my question, for my purposes, I feel like a watcher is better suited? Correct me if I am wrong(also when should one use a reflector?).

The examples for watchers and reflectors use try_flatten_applied which makes I believe makes me lose the information of whether this was Apply/Delete/Restart. Is there anyway, in the library, I can get the events while knowing it belonged to Event type? Or do I have to write my own?

Also is the very first event from a watcher a Restart event? It would make sense if it was :)

Thanks again for your continued help :)

[nightkr]

Is this for when the underlying connection gets disrupted, or some error happens, and you fetch everything again?

Yes. Though not every disconnect generates a Restart; we try to recover the existing stream first and only Restart if that fails.

To my question, for my purposes, I feel like a watcher is better suited? Correct me if I am wrong(also when should one use a reflector?).

kube-runtime is a bit like a layer cake:

1. kube::Api::watch streams events from the Kubernetes API
2. kube_runtime::watcher adds error recovery on top of Api::watch (as you've already noticed), use this if you only care about raw events (for example: logging all events as they happen)
3. kube_runtime::reflector adds a persistent cache on top of watcher, use this if you want to take an action that depends on the whole cluster state (for example: rebuilding a local load balancer's config from scratch every time a pod is started/stopped)
4. kube_runtime::controller adds event deduplication, event handler retries, and event handler concurrency on top of reflector, use this if you want to take a fallible and/or potentially slow action (for example: managing other Kubernetes objects)

It's hard to make a concrete recommendation without knowing what kind of action you're planning on taking based on those events. If in doubt, I'd go with controller.

The examples for watchers and reflectors use try_flatten_applied which makes I believe makes me lose the information of whether this was Apply/Delete/Restart. Is there anyway, in the library, I can get the events while knowing it belonged to Event type? Or do I have to write my own?

You don't have to use try_flatten_applied (or co.), it's just a helper for when you don't care about the distinction between Applied and Restarted. That said, it's worth keeping in mind that Deleted events are not reliable. You will miss deletions that happened right before a Restarted, or while your program wasn't running at all. If you want reliable deletion events, use kube_runtime::finalizer.

Also is the very first event from a watcher a Restart event? It would make sense if it was :)

Yes.

[DevasiaThomas]

@teozkr I would say since I just want the events to be passed to upstream, it would be akin to logging events as described in point 2.

You mentioned event dedup when talking about the kube_runtime::controller. Does the k8s API send duplicate events during an active watch (if the code was just using a watcher)?

I can ask upstream to invalidate previous info incase of Restart. Then I wouldn't need to worry about Delete events being reliable.

I want my code just to be an observer and not affect the state of the cluster in anyway. Since the finalizer can hold up deletes, I don't think it fits my objective.

[nightkr]

I would say since I just want the events to be passed to upstream, it would be akin to logging events as described in point 2.

Depends on what that upstream is. If it's a local Mutex, raw watcher should be fine. If it's over the network then you'll want to consider what your reliability requirements are.

You mentioned event dedup when talking about the kube_runtime::controller. Does the k8s API send duplicate events during an active watch (if the code was just using a watcher)?

Not duplicate per se, but you might see events that are obsolete by the time you get to them. Consider the following timeline:

1. App starts watch
2. App gets initial state and starts processing foo/rev1
3. foo/rev2 is written to k8s
4. foo/rev3 is written to k8s
5. App finishes processing foo/rev1 and moves on

Here, watcher (and reflector) will start processing rev2 before moving on to rev3, since that's the order it received the events in. controller, on the other hand, will see that rev2 is already obsolete and start processing rev3 immediately.

I can ask upstream to invalidate previous info incase of Restart. Then I wouldn't need to worry about Delete events being reliable.

That sounds reasonable to me.

I want my code just to be an observer and not affect the state of the cluster in anyway. Since the finalizer can hold up deletes, I don't think it fits my objective.

If it's OK to do a reset on Restart then you probably don't need a finalizer, correct.