mirror of https://github.com/k3s-io/k3s
![]() Automatic merge from submit-queue (batch tested with PRs 49971, 51357, 51616, 51649, 51372) add information for subresource kind determination xref https://github.com/kubernetes/kubernetes/issues/38810 https://github.com/kubernetes/kubernetes/issues/38756 Polymorphic subresources usually have different groupVersions for their discovery kinds than their "native" groupVersions. Even though the APIResourceList shows the kind properly, it does not reflect the group or version of that kind, which makes it impossible to unambiguously determine if the subresource matches you and it is impossible to determine how to serialize your data. See HPA controller. This adds an optional Group and Version to the discovery doc, which can be used to communicate the "native" groupversion of an endpoint. Doing this does not preclude fancier contenttype negotiation in the future and doesn't prevent future expansion from indicating equivalent types, but it does make it possible to solve the problem we have today or polymorphic categorization. @kubernetes/sig-api-machinery-misc @smarterclayton @cheftako since @lavalamp is out. ```release-note Adds optional group and version information to the discovery interface, so that if an endpoint uses non-default values, the proper value of "kind" can be determined. Scale is a common example. ``` |
||
---|---|---|
.. | ||
BUILD | ||
README.md | ||
swagger.json |
README.md
Kubernetes's OpenAPI Specification
This folder contains an [OpenAPI specification][openapi] for Kubernetes API.
Vendor Extensions
Kuberntes extends OpenAPI using these extensions. Note the version that extensions has been added.
x-kubernetes-group-version-kind
Operations and Definitions may have x-kubernetes-group-version-kind
if they
are associated with a kubernetes resource.
For example:
"paths": {
...
"/api/v1/namespaces/{namespace}/pods/{name}": {
...
"get": {
...
"x-kubernetes-group-version-kind": {
"group": "",
"version": "v1",
"kind": "Pod"
}
}
}
}
x-kubernetes-action
Operations and Definitions may have x-kubernetes-action
if they
are associated with a kubernetes resource.
Action can be one of get
, list
, put
, patch
, post
, delete
, deletecollection
, watch
, watchlist
, proxy
, or connect
.
For example:
"paths": {
...
"/api/v1/namespaces/{namespace}/pods/{name}": {
...
"get": {
...
"x-kubernetes-action": "list"
}
}
}
x-kubernetes-patch-strategy
and x-kubernetes-patch-merge-key
Some of the definitions may have these extensions. For more information about PatchStrategy and PatchMergeKey see
[strategic-merge-patch] (3a1e6d22f8/contributors/devel/strategic-merge-patch.md
).