Enhance EgressQoS CR as a generic QoS feature #4366
Conversation
|
Changes unknown |
tssurya
added
kind/enhancement
docs/enhancements/qos.md
Outdated
| The `qos-external-bar` doesn't have podSelector, so QoS rule specified in this object is applied to all pods in the `default` namespace. | ||
|
|
||
| ```yaml | ||
| kind: QoS |
There was a problem hiding this comment.
Shouldn't we call this NetworkQoS? Plain QoS can be confusing and collide with other kinds. QoS could refer as well to CPU, Memory, GPU, Storage. And since we are doing this only for network I would name it as such. We already have NetworkPolicy (and not just Policy) so why not NetworkQoS :)
There was a problem hiding this comment.
There is also https://github.com/kubernetes/enhancements/pull/3004/files that could be relevant in the future.
There was a problem hiding this comment.
yes @VirrageS , NetworkQoS seems to be appropriate name for CRD, let's go with it.
Thanks for the KEP link, looks like it's targeting only memory, cpu, device resources now. as you said we can also see how that can be adapted for networking qos. not sure if we can just use capacity parameter for dscp marking. but i hope this is for future.
The current EgressQoS is tied to pod's egress traffic and may be used only for DSCP marking. so this enhances the CR to be more generic enough so that it can be easily extended for applying QoS for both east west and north south traffic and supporting traffic policing and shaping. Signed-off-by: Periyasamy Palanisamy <[email protected]>
The current EgressQoS is tied to pod's egress traffic and may be used only for DSCP marking. so this enhances the CR to be more generic enough so that it can be easily extended for applying QoS for both east west and north south traffic and supporting traffic policing and shaping.