-
Notifications
You must be signed in to change notification settings - Fork 15.1k
Document KEP-5116 #51457
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document KEP-5116 #51457
Conversation
👷 Deploy Preview for kubernetes-io-vnext-staging processing.
|
This KEP is byte for byte compatible IIRC. Is there much to document? If we want to expand anything, it would be the documentation about API server performance. |
Exactly |
I suggest adding a brief (stub?) page under https://kubernetes.io/docs/concepts/cluster-administration/#managing-a-cluster, about API server performance, and making no other changes. |
Don't think https://kubernetes.io/docs/concepts/cluster-administration/#managing-a-cluster has anything related to performance. |
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
Ready for review. |
Hello @serathius 👋! I'm reaching out from the Docs team. Just checking in as we approach Docs Freeze on Wednesday August 6, 2025 18:00 PDT. This documentation appears to still be under review. To meet the Docs Freeze, this PR must have a technical review as well as lgtm and approve labels applied, without any unaddressed comments or concerns from SIG Docs. Thank you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one tweak, lgtm otherwise
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should emphasize that this is streaming but it's not about the kind of streaming you can do with a watch (nor, if we want to be clear, is it support for fetching collections over a WebSocket).
Over HTTP, Kubernetes supports JSON, YAML, CBOR and Protobuf wire encodings. | ||
|
||
By default, Kubernetes returns objects in [JSON serialization](#json-encoding), using the | ||
`application/json` media type. Although JSON is the default, clients may request a response in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we mention (alpha) CBOR here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should mention stage, I think CBOR should be going Beta in 1.34. All the media types are explained in more detail below, so I would depend on that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(CBOR is still alpha in 1.34, fwiw)
but allows API server to avoid loading whole responses into memory. | ||
Using other types of encoding (including pretty representation of JSON) | ||
should be avoided for large collections of resources (>100MB) as it can have negative performance impact. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have a to impose rate limits (APF) or outright restrictions on the media type that Kubernetes responds with, right?
(if we did, I would be recommending adding an item to the security checklist, or recommending a custom expression APF rule, or something).
Can we somehow make it easy for someone reading this to spot that support for CBOR (optional?) and YAML (GA) makes it easier for a malicious or reckless client to DoS your control plane?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have a to impose rate limits (APF) or outright restrictions on the media type that Kubernetes responds with, right?
I have been looking into it as part of kubernetes/kubernetes#132233 however I discovered that APF is not very good at punishing very expensive requests. It's focuses on priority and fairness and not resource protection. I plan to add the logic to detect whether media type is streamed to APF cost estimation, however at the current state APF it would not help much with preventing apiserver overload.
Can we somehow make it easy for someone reading this to spot that support for CBOR (optional?) and YAML (GA) makes it easier for a malicious or reckless client to DoS your control plane?
This is the biggest issue with K8s for any cloud provider. It's too easy for misguided client to take down control plane.
Alternative name I was considering was |
/assign @divya-mohan0209 |
## HTTP media types {#alternate-representations-of-resources} | ||
|
||
Over HTTP, Kubernetes supports JSON and Protobuf wire encodings. | ||
Over HTTP, Kubernetes supports JSON, YAML, CBOR and Protobuf wire encodings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree about mentioning CBOR being alpha (non blocking)
Over HTTP, Kubernetes supports JSON, YAML, CBOR and Protobuf wire encodings. | |
Over HTTP, Kubernetes supports JSON, YAML, CBOR (alpha) and Protobuf wire encodings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On line 341 we have whole section for CBOR that doesn't mention alpha at all, only the feautre gate CBORServingAndStorage. Why mention Alpha here and not there?
Hello @serathius 👋! I'm reaching out on behalf of the Release Docs team. A friendly reminder that Docs Freeze is approaching today, at 18:00 PT (less than 8 hours). This documentation PR appears to still be under review. Here's where it currently stands:
If you wish to include this enhancement in 1.34 but are concerned about meeting the deadline, please consider proactively filing an exception request. Thanks! cc: @kubernetes/sig-api-machinery-emeritus FYSA |
/lgtm |
LGTM label has been added. Git tree hash: 23aad1499e2ab74bb5e6163d2481c4445dcf228d
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to document any feature gates? I think the change in this PR is OK to merge but I also expect there needs to be more than just this part.
/lgtm
/approve
a `406 Not acceptable` error message. | ||
All built-in resource types support the `application/json` media type. | ||
|
||
#### Chunked encoding of collections |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is OK and I'll merge it, but AIUI we support HTTP/2 and you can get streaming response serialisation without chunked encoding.
I also don't know whether the HTTP/1 implementation means we actually emit chunks for this (I assume we do, but haven't checked).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AIUI we support HTTP/2 and you can get streaming response serialisation without chunked encoding.
HTTP/2 is the transport / network transfer, not the serialization.
This improvement and documentation is describing how the server can do streaming serialization of the response to the writer / network, rather than fully serializing into a byte array in memory, then copying that byte array to the writer / network, which is what it did previously.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lmktfy The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Documenting kubernetes/enhancements#5116