
* 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
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.