Group Kubernetes API traffic by the intended flow identity

Bottom line: Choose the grouping key that matches the actual traffic population. Two application instances should not be assumed to receive separate treatment merely because they run in different Pods; map the identity and namespace seen by the API before proposing a fairness change.

Source fact: documented behavior

The API Priority and Fairness documentation is the primary reference.

Within a priority level, a flow is identified by the matching FlowSchema name together with a distinguisher: the requesting user, target namespace or no additional value. ByUser groups matching requests by user, ByNamespace groups them by resource namespace, and omitting the distinguisher places all requests matched by that FlowSchema into one flow. The source advises controllers with many instances to authenticate with distinct usernames when distinct handling is required.

What the source does not establish

This article chooses a flow-grouping key. It does not grant permissions, prescribe concurrency shares or promise a latency target. Keep matching-rule priority, exemptions, recursive-server risks and release-specific metrics under their own assessment. A correctly identified flow is an input to controlled testing, not proof that important requests cannot be delayed.

Applicability questions

• Which authenticated user does each client actually present?
• Are requests separated by resource namespace or shared across them?
• Which FlowSchema matches the selected request population?
• Which operational requirement needs separate treatment within a priority level?

DSE recommendation: draw the identity-to-flow map

DSE recommends reviewing request identity and target namespace before choosing a FlowSchema distinguisher.

Create a traffic map for the specific controllers or clients under investigation. Record the authenticated identity, requested resource, target namespace and matched configuration. Use permitted diagnostic evidence rather than assuming that a Pod name is the API user. Keep credentials and private request content outside the shared map.

Write which traffic populations should be grouped and which should be separated. Have the control-plane owner assess whether user-based or namespace-based grouping expresses that requirement. For a shared identity, document the intentional grouping instead of promising instance isolation that the selected key does not express. Review any proposed identity change with the separate authorization and credential owners.

Check the matched FlowSchema and associated priority-level configuration as different entries. A request reaching the intended schema and a request receiving an acceptable service response are separate observations. Preserve both before considering capacity or queue changes. Avoid solving a single slow client by exempting broad traffic without a supported risk assessment.

Pilot the grouping change with bounded harmless traffic in a suitable test environment. Define a modest request ceiling, an observation window and an immediate stop condition. Keep ordinary clients under observation while testing the selected population so the owner can assess effects beyond the noisy participant.

Verification and evidence

Proposed verification, not performed: prepare a small request matrix with two approved test identities and two harmless resource namespaces. First predict the grouping for user-based, namespace-based and omitted distinguishers as desk cases. Mark all request rates and timings as proposed inputs.

Exercise only the accepted configuration with authorized clients and the installed release’s supported diagnostics. Retain identity references, namespaces, matched schema, configuration revision and actual responses. Reconcile observed grouping before interpreting queue or latency measurements. Do not flood a production API server, manufacture a starvation incident or claim that this article establishes a throughput guarantee.

Official references

• API Priority and Fairness — Kubernetes.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.