Current state
KFC currently establish a watch by performing a LIST+WATCH requests to populate its cache. Which is currently the default way of handling things. With the changes coming from KEP-3157, see also the doc page.
Describe the solution you'd like
KFC should consider switching to a single WATCH request setting the following parameters:
sendInitialEvents=true - this parameter tells the kube-apiserver to return the initial list of resources, thus replacing the LIST request.resourceVersionMatch=NotOlderThan - is a required parameter with the previous one, telling kube-apiserver to return data at least as new as the provided resource version.watch=true - the usual parameter initiating the watch request.
Describe alternatives you've considered
The alternative is to stay with the current flow, which for small requests will not bring too much gain. But at a certain scale, we might definitely benefit from less requests and simpler code.
Timeline
Currently the KEP-3157 is still in beta in kubernetes 1.35, likely to be promoted to GA sometime in 1.36 or 1.37 (unconfirmed information). So it doesn't make sense to implement this functionality anytime sooner than around that time frame, to ensure the clusters we are talking to are capable of handling the new semantics. Still, we'd need to provide the fallback to the old way of doing things, when necessary.
Current state
KFC currently establish a watch by performing a LIST+WATCH requests to populate its cache. Which is currently the default way of handling things. With the changes coming from KEP-3157, see also the doc page.
Describe the solution you'd like
KFC should consider switching to a single WATCH request setting the following parameters:
sendInitialEvents=true- this parameter tells the kube-apiserver to return the initial list of resources, thus replacing the LIST request.resourceVersionMatch=NotOlderThan- is a required parameter with the previous one, telling kube-apiserver to return data at least as new as the provided resource version.watch=true- the usual parameter initiating the watch request.Describe alternatives you've considered
The alternative is to stay with the current flow, which for small requests will not bring too much gain. But at a certain scale, we might definitely benefit from less requests and simpler code.
Timeline
Currently the KEP-3157 is still in beta in kubernetes 1.35, likely to be promoted to GA sometime in 1.36 or 1.37 (unconfirmed information). So it doesn't make sense to implement this functionality anytime sooner than around that time frame, to ensure the clusters we are talking to are capable of handling the new semantics. Still, we'd need to provide the fallback to the old way of doing things, when necessary.