11a25bfeb6
* De-share the Handler struct in core API An upcoming PR adds a handler that only applies on one of these paths. Having fields that don't work seems bad. This never should have been shared. Lifecycle hooks are like a "write" while probes are more like a "read". HTTPGet and TCPSocket don't really make sense as lifecycle hooks (but I can't take that back). When we add gRPC, it is EXPLICITLY a health check (defined by gRPC) not an arbitrary RPC - so a probe makes sense but a hook does not. In the future I can also see adding lifecycle hooks that don't make sense as probes. E.g. 'sleep' is a common lifecycle request. The only option is `exec`, which requires having a sleep binary in your image. * Run update scripts |
||
|---|---|---|
| .. | ||
| README.md | ||
| swagger.json | ||
Kubernetes's OpenAPI Specification
This folder contains an OpenAPI specification for Kubernetes API.
Vendor Extensions
Kubernetes 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.