-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs(kubernetes): explain readiness probe #58
Changes from 3 commits
e07f822
8f71c92
4fb5a06
6ad8f71
9148dd8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -103,10 +103,38 @@ terminus(server, options); | |
server.listen(PORT || 3000); | ||
``` | ||
|
||
## How to set Terminus up with Kubernetes? | ||
|
||
When a pod is deleted, Kubernetes will notify it and wait for `gracePeriod` seconds before killing it. | ||
|
||
During that time window (30 seconds by default), the pod is in the `terminating` state and will be removed from any Services by a controller. The pod itself needs to catch the `SIGTERM` signal and start failing any readiness probes. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this should come after the description about why a terminating pod (that is removed from a service) might still receive requests. |
||
|
||
During this time, it is possible that load-balancers don't remove the pods "in time", and when the pod dies, it kills live connections. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you give a specific example of "load-balancer". e.g., the nginx ingress controller. |
||
|
||
> If the ingress controller you use route via the Service, it is not an issue for your case. At the time of this writing, we use the nginx ingress controller which routes traffic directly to the pods. | ||
|
||
To make sure you don't lose any connections, we recommend delaying the shutdown with the number of milliseconds that's defined by the readiness probe in your deployment configuration. To help with this, terminus exposes an option called `beforeShutdown` that takes any Promise-returning function. | ||
|
||
```javascript | ||
function beforeShutdown () { | ||
// given your readiness probes run every 5 second | ||
// may be worth using a bigger number so you won't | ||
// run into any race conditions | ||
return Promise(resolve => { | ||
setTimeout(resolve, 5000) | ||
}) | ||
} | ||
terminus(server, { | ||
beforeShutdown | ||
}) | ||
``` | ||
|
||
[Learn more](https://github.com/kubernetes/contrib/issues/1140#issuecomment-231641402) | ||
|
||
## Limited Windows support | ||
|
||
Due to inherent platform limitations, `terminus` has limited support for Windows. | ||
You can expect `SIGINT` to work, as well as `SIGBREAK` and to some extent `SIGHUP`. | ||
However `SIGTERM` will never work on Windows because killing a process in the task manager is unconditional, i.e., there's no way for an application to detect or prevent it. | ||
Here's some relevant documentation from [`libuv`](https://github.com/libuv/libuv) to learn more about what `SIGINT`, `SIGBREAK` etc. signify and what's supported on Windows - http://docs.libuv.org/en/v1.x/signal.html. | ||
Also see https://nodejs.org/api/process.html#process_signal_events. | ||
Also, see https://nodejs.org/api/process.html#process_signal_events. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pod -> Pod