proposal: Node-level Traffic Reuse Capability #2060
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2060 +/- ##
==========================================
- Coverage 56.09% 56.01% -0.08%
==========================================
Files 186 186
Lines 18092 18092
==========================================
- Hits 10149 10135 -14
- Misses 6910 6922 +12
- Partials 1033 1035 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
@zyjhtangtang The idea in this proposal is amazing. I think that it is a very useful feature for OpenYurt. because this feature can provide the following pros:
|
| ``` | ||
|
|
||
| The Watch Cache is an in-memory cache that stores watch events and allows quick access to the current state of a resource, combined with a stream of watch events. [reference](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/cacher/watch_cache.go#L140) | ||
|
|
There was a problem hiding this comment.
please add metrics endpoints in yurthub component that provide details of requests which can reuse traffic.
so end user can check all request status on the edge node before they configure the traffic reuse requests.
|
|
||
| ## Proposal | ||
|
|
||
| To reduce the cloud-edge traffic on a single node, we recommend consolidating the full List/Watch requests for the same resource so that all components can reuse the data from this single request. The main idea is to add a full-list resource caching module within YurtHub, modeled after the cache implementation of the ApiServer. Within this module, using the apiserver as the Storage Backend, the Storage Backend actively initiates list/watch requests to the apiserver, and caches the content of the requests in the WatchCache. Consequently, the full list/watch requests for resources from the components on the node are directly served by the WatchCache. |
There was a problem hiding this comment.
end user can configure the kinds of traffic reuse requests through the startup parameter of yurthub. this means the supported traffic reuse requests can not be configured dynamically.
| ### Non-Goals/Future Work | ||
|
|
||
| - The optimization only involves the reuse of requests on a single node and does not pertain to traffic optimization at the node pool level; | ||
| - The optimization only pertains to full-scale list/watch requests for resources and does not involve requests with filtering conditions. |
There was a problem hiding this comment.
I think it is a good idea that requests with filtering conditions can also be supported if full-scale list/watch request exists.
|
|
||
| To reduce the cloud-edge traffic on a single node, we recommend consolidating the full List/Watch requests for the same resource so that all components can reuse the data from this single request. The main idea is to add a full-list resource caching module within YurtHub, modeled after the cache implementation of the ApiServer. Within this module, using the apiserver as the Storage Backend, the Storage Backend actively initiates list/watch requests to the apiserver, and caches the content of the requests in the WatchCache. Consequently, the full list/watch requests for resources from the components on the node are directly served by the WatchCache. | ||
|
|
||
| <img src = "../img/img-20240529002.png" width="800" /> |
There was a problem hiding this comment.
we should cache only one copy of service/endpointslice for all clients, because all of these clients share the copy of data.
|
What type of PR is this?