The OVN-Kubernetes has an existing EgressQoS feature which supports DSCP marking for a pod traffic which destined to a specific CIDR.
This has few limitations.
No support of DSCP marking for pod to pod traffic.
It doesn't have an extensive classifier to choose destination, The destination may target set of pod(s), namespace, CIDRs, protocol and port.
No option to set bandwidth limit parameters like rate and burst.
The EgressQoS targets only egress traffic, but in future this may target QoS for ingress traffic as well, so make CR to be generic enough to accommodate this.
only one EgressQoS object per namespace is supported.
These limitations must be removed so that QoS can be deployed as a full-blown feature in customer deployments.
Why is this needed?
The workloads running in Kubernetes using OVN-Kubernetes as a networking backed might have different requirements in handling network traffic. For example video streaming application needs low latency and jitter whereas storage application can tolerate with packet loss. Hence QoS is essential in meeting these SLAs to provide better service quality.
The workload traffic can be either east west (pod to pod traffic) or north south traffic (pod to external traffic) types in a Kubernetes cluster which is limited by finite bandwidth. So QoS must ensure high priority applications get the necessary QoS marking so that it can prevent network congestion.
What would you like to be added?
The OVN-Kubernetes has an existing EgressQoS feature which supports DSCP marking for a pod traffic which destined to a specific CIDR.
This has few limitations.
These limitations must be removed so that QoS can be deployed as a full-blown feature in customer deployments.
Why is this needed?
The workloads running in Kubernetes using OVN-Kubernetes as a networking backed might have different requirements in handling network traffic. For example video streaming application needs low latency and jitter whereas storage application can tolerate with packet loss. Hence QoS is essential in meeting these SLAs to provide better service quality.
The workload traffic can be either east west (pod to pod traffic) or north south traffic (pod to external traffic) types in a Kubernetes cluster which is limited by finite bandwidth. So QoS must ensure high priority applications get the necessary QoS marking so that it can prevent network congestion.