You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -54,68 +54,123 @@ Detachments can be performed with `deis config:unset`.
54
54
55
55
## Custom Health Checks
56
56
57
-
By default, Workflow only checks that your application containers start in
58
-
their Pod. If you would like Kubernetes to respond to appliation health, you
59
-
may add a health check by configuring URL, initial delay, and timeout
60
-
values.
57
+
By default, Workflow only checks that the application starts in their Container. If it is preferred
58
+
to have Kubernetes respond to application health, a health check may be added by configuring a
59
+
health check probe for the application.
61
60
62
-
The health checks are implemented as [Kubernetes container probes][kubernetes-probes]. Currently only HTTP GET is supported.
61
+
The health checks are implemented as [Kubernetes container probes][kubernetes-probes]. A `liveness`
62
+
and a `readiness` probe can be configured, and each probe can be of type `httpGet`, `exec`, or
63
+
`tcpSocket` depending on the type of probe the container requires.
63
64
64
-
Available configuration options for health checks are the following, including defaults:
65
+
A liveness probe is useful for applications running for long periods of time, eventually
66
+
transitioning to broken states and cannot recover except by restarting them.
65
67
66
-
**HEALTHCHECK_URL**
68
+
Other times, a readiness probe is useful when the container is only temporarily unable to serve,
69
+
and will recover on its own. In this case, if a container fails its readiness probe, the container
70
+
will not be shut down, but rather the container will stop receiving incoming requests.
67
71
68
-
Path in the application to use for health check, such as /healthz - Query Parameters are not supported.
72
+
`httpGet` probes are just as it sounds: it performs a HTTP GET operation on the Container. A
73
+
response code inside the 200-399 range is considered a pass.
69
74
70
-
This value needs to be set for any health check to happen. Needs to accept a HTTP GET request and return a HTTP status between 200-399.
75
+
`exec` probes run a command inside the Container to determine its health, such as
76
+
`cat /var/run/myapp.pid` or a script that determines when the application is ready. An exit code of
77
+
zero is considered a pass, while a non-zero status code is considered a fail.
71
78
72
-
**HEALTHCHECK_TIMEOUT**
79
+
`tcpSocket` probes attempt to open a socket in the Container. The Container is only considered
80
+
healthy if the check can establish a connection. `tcpSocket` probes accept a port number to perform
81
+
the socket connection on the Container.
73
82
74
-
Number of seconds after which the health check times out. Defaults to 50 seconds
83
+
Health checks can be configured on a per-application basis using `deis healthchecks:set`. To
84
+
configure a `httpGet` liveness probe:
75
85
76
-
**HEALTHCHECK\_INITIAL_DELAY**
77
-
78
-
Number of seconds before health checks starts checking the application after the start of the pod.
79
-
80
-
This is useful to set if the application takes a while to get setup, due to migrations, cache warming or otherwise. Prevents Kubernetes (and Deis Workflow) from replacing an application pod in its setup phase.
81
-
82
-
Defaults to 50 seconds
86
+
```
87
+
$ deis healthchecks:set liveness httpGet 80
88
+
=== peachy-waxworks Healthchecks
89
+
Liveness
90
+
--------
91
+
Initial Delay (seconds): 50
92
+
Timeout (seconds): 50
93
+
Period (seconds): 10
94
+
Success Threshold: 1
95
+
Failure Threshold: 3
96
+
Exec Probe: N/A
97
+
HTTP GET Probe: Path="/" Port=80 HTTPHeaders=[]
98
+
TCP Socket Probe: N/A
99
+
100
+
Readiness
101
+
---------
102
+
No readiness probe configured.
103
+
```
83
104
84
-
**HEALTHCHECK\_PERIOD_SECONDS**
105
+
If the application relies on certain headers being set (such as the `Host` header) or a specific
106
+
URL path relative to the root, you can also send specific HTTP headers:
85
107
86
-
How often (in seconds) to perform the health check. Defaults every 10 seconds
108
+
```
109
+
$ deis healthchecks:set liveness httpGet 80 \
110
+
--path /welcome/index.html \
111
+
--header "X-Client-Version=v1.0"
112
+
=== peachy-waxworks Healthchecks
113
+
Liveness
114
+
--------
115
+
Initial Delay (seconds): 50
116
+
Timeout (seconds): 50
117
+
Period (seconds): 10
118
+
Success Threshold: 1
119
+
Failure Threshold: 3
120
+
Exec Probe: N/A
121
+
HTTP GET Probe: Path="/welcome/index.html" Port=80 HTTPHeaders=[X-Client-Version=v1.0]
122
+
TCP Socket Probe: N/A
123
+
124
+
Readiness
125
+
---------
126
+
No readiness probe configured.
127
+
```
87
128
88
-
**HEALTHCHECK\_SUCCESS_THRESHOLD**
129
+
To configure an `exec` readiness probe:
89
130
90
-
Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1 success
131
+
```
132
+
$ deis healthchecks:set readiness exec -- /bin/echo -n hello
133
+
=== peachy-waxworks Healthchecks
134
+
Liveness
135
+
--------
136
+
No liveness probe configured.
137
+
138
+
Readiness
139
+
---------
140
+
Initial Delay (seconds): 50
141
+
Timeout (seconds): 50
142
+
Period (seconds): 10
143
+
Success Threshold: 1
144
+
Failure Threshold: 3
145
+
Exec Probe: Command="/bin/echo -n hello"
146
+
HTTP GET Probe: N/A
147
+
TCP Socket Probe: N/A
148
+
```
91
149
92
-
**HEALTHCHECK\_FAILURE_THRESHOLD**
150
+
You can overwrite a probe by running `deis healthchecks:set` again:
93
151
94
-
Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3 failures
152
+
```
153
+
$ deis healthchecks:set readiness httpGet 80
154
+
=== peachy-waxworks Healthchecks
155
+
Liveness
156
+
--------
157
+
No liveness probe configured.
158
+
159
+
Readiness
160
+
---------
161
+
Initial Delay (seconds): 50
162
+
Timeout (seconds): 50
163
+
Period (seconds): 10
164
+
Success Threshold: 1
165
+
Failure Threshold: 3
166
+
Exec Probe: N/A
167
+
HTTP GET Probe: Path="/" Port=80 HTTPHeaders=[]
168
+
TCP Socket Probe: N/A
169
+
```
95
170
171
+
Configured health checks also modify the default application deploy behavior. When starting a new
172
+
Pod, Workflow will wait for the health check to pass before moving onto the next Pod.
96
173
97
-
Configure these health checks on a per-application basis using `deis config:set`:
98
-
```
99
-
$ deis config:set HEALTHCHECK_URL=/200.html
100
-
=== peachy-waxworks
101
-
HEALTHCHECK_URL: /200.html
102
-
$ deis config:set HEALTHCHECK_INITIAL_DELAY=5
103
-
=== peachy-waxworks
104
-
HEALTHCHECK_INITIAL_DELAY: 5
105
-
HEALTHCHECK_URL: /200.html
106
-
$ deis config:set HEALTHCHECK_TIMEOUT=5
107
-
=== peachy-waxworks
108
-
HEALTHCHECK_TIMEOUT: 5
109
-
HEALTHCHECK_INITIAL_DELAY: 5
110
-
HEALTHCHECK_URL: /200.html
111
-
112
-
If an application times out, or responds to a health check with a response code
113
-
outside the 200-399 range, Kubernetes will stop sending requests to the
114
-
application and re-schedule the pod to another node.
115
-
116
-
Configured health checks also modify the default application deploy behavior.
117
-
When starting a new pod, Workflow will wait for the health check to pass before
0 commit comments