Merge pull request #77807 from matthyx/startupProbe

Add startupProbe to health checks
This commit is contained in:
Kubernetes Prow Robot
2019-08-29 21:21:30 -07:00
committed by GitHub
104 changed files with 21991 additions and 17780 deletions

View File

@@ -7159,6 +7159,10 @@
"$ref": "#/definitions/io.k8s.api.core.v1.SecurityContext",
"description": "Security options the pod should run with. More info: https://kubernetes.io/docs/concepts/policy/security-context/ More info: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/"
},
"startupProbe": {
"$ref": "#/definitions/io.k8s.api.core.v1.Probe",
"description": "StartupProbe indicates that the Pod has successfully initialized. If specified, no other probes are executed until this completes successfully. If this probe fails, the Pod will be restarted, just as if the livenessProbe failed. This can be used to provide different probe parameters at the beginning of a Pod's lifecycle, when it might take a long time to load data or warm a cache, than during steady-state operation. This cannot be updated. This is an alpha feature enabled by the StartupProbe feature flag. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes"
},
"stdin": {
"description": "Whether this container should allocate a buffer for stdin in the container runtime. If this is not set, reads from stdin in the container will always result in EOF. Default is false.",
"type": "boolean"
@@ -7372,6 +7376,10 @@
"format": "int32",
"type": "integer"
},
"started": {
"description": "Specifies whether the container has passed its startup probe. Initialized as false, becomes true after startupProbe is considered successful. Resets to false when the container is restarted, or if kubelet loses state temporarily. Is always true when no startupProbe is defined.",
"type": "boolean"
},
"state": {
"$ref": "#/definitions/io.k8s.api.core.v1.ContainerState",
"description": "Details about the container's current condition."
@@ -7745,6 +7753,10 @@
"$ref": "#/definitions/io.k8s.api.core.v1.SecurityContext",
"description": "SecurityContext is not allowed for ephemeral containers."
},
"startupProbe": {
"$ref": "#/definitions/io.k8s.api.core.v1.Probe",
"description": "Probes are not allowed for ephemeral containers."
},
"stdin": {
"description": "Whether this container should allocate a buffer for stdin in the container runtime. If this is not set, reads from stdin in the container will always result in EOF. Default is false.",
"type": "boolean"
@@ -8422,7 +8434,7 @@
},
"preStop": {
"$ref": "#/definitions/io.k8s.api.core.v1.Handler",
"description": "PreStop is called immediately before a container is terminated due to an API request or management event such as liveness probe failure, preemption, resource contention, etc. The handler is not called if the container crashes or exits. The reason for termination is passed to the handler. The Pod's termination grace period countdown begins before the PreStop hooked is executed. Regardless of the outcome of the handler, the container will eventually terminate within the Pod's termination grace period. Other management of the container blocks until the hook completes or until the termination grace period is reached. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks"
"description": "PreStop is called immediately before a container is terminated due to an API request or management event such as liveness/startup probe failure, preemption, resource contention, etc. The handler is not called if the container crashes or exits. The reason for termination is passed to the handler. The Pod's termination grace period countdown begins before the PreStop hooked is executed. Regardless of the outcome of the handler, the container will eventually terminate within the Pod's termination grace period. Other management of the container blocks until the hook completes or until the termination grace period is reached. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks"
}
},
"type": "object"
@@ -10003,7 +10015,7 @@
"x-kubernetes-patch-strategy": "merge"
},
"initContainers": {
"description": "List of initialization containers belonging to the pod. Init containers are executed in order prior to containers being started. If any init container fails, the pod is considered to have failed and is handled according to its restartPolicy. The name for an init container or normal container must be unique among all containers. Init containers may not have Lifecycle actions, Readiness probes, or Liveness probes. The resourceRequirements of an init container are taken into account during scheduling by finding the highest request/limit for each resource type, and then using the max of of that value or the sum of the normal containers. Limits are applied to init containers in a similar fashion. Init containers cannot currently be added or removed. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/",
"description": "List of initialization containers belonging to the pod. Init containers are executed in order prior to containers being started. If any init container fails, the pod is considered to have failed and is handled according to its restartPolicy. The name for an init container or normal container must be unique among all containers. Init containers may not have Lifecycle actions, Readiness probes, Liveness probes, or Startup probes. The resourceRequirements of an init container are taken into account during scheduling by finding the highest request/limit for each resource type, and then using the max of of that value or the sum of the normal containers. Limits are applied to init containers in a similar fashion. Init containers cannot currently be added or removed. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/",
"items": {
"$ref": "#/definitions/io.k8s.api.core.v1.Container"
},
@@ -10344,7 +10356,7 @@
"type": "integer"
},
"successThreshold": {
"description": "Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness. Minimum value is 1.",
"description": "Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup. Minimum value is 1.",
"format": "int32",
"type": "integer"
},