docs(kubernetes): explain readiness probe #58
Conversation
README.md
Outdated
| ```javascript | ||
| function beforeShutdown () { | ||
| // given your readiness probes run every 5 second | ||
| // may worth using a bigger number so you won't |
README.md
Outdated
|
|
||
| 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. | ||
|
|
||
| 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.
Is this specific to the nginx ingress controller? Or do other implementations also have this result?
There was a problem hiding this comment.
afaik, this is how all implementations work
There was a problem hiding this comment.
any chance @peterkuiper or @thockin that you can verify that?
There was a problem hiding this comment.
I think its relevant because the service itself can be a single IP that fronts the pods and it won't be taken out of the DNS pool until readiness check tells it.
There was a problem hiding this comment.
the nginx ingress controller routes directly to Pods (not via the Service). If it routed via the Service, we wouldn't have this issue (https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/)
There was a problem hiding this comment.
Also relevant:
README.md
Outdated
|
|
||
| When a pod is deleted, Kubernetes will notify it and will 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.
Same q as below -- Do i only need to be concerned about this with the nginx ingress controller? If I've configured my Service to use a NodePort or something, then I don't need to worry, correct?
README.md
Outdated
| // may worth using a bigger number so you won't | ||
| // run into any race conditions | ||
| return Promise(resolve => { | ||
| setTimeout(5000, resolve) |
There was a problem hiding this comment.
based off the function signature on MDN, should be setTimeout(resolve, 5000) https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout
There was a problem hiding this comment.
omg, thanks, great catch Mayank!
README.md
Outdated
| @@ -103,6 +103,32 @@ terminus(server, options); | |||
| server.listen(PORT || 3000); | |||
| ``` | |||
|
|
|||
| ## How to set Terminus up with Kubernetes? | |||
|
|
|||
| When a pod is deleted, Kubernetes will notify it and will wait for `gracePeriod` seconds before killing it. | |||
There was a problem hiding this comment.
nit: ... Kubernetes will notify it and wait for ... (removes double use of will)
README.md
Outdated
|
|
||
| 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.
I think this should come after the description about why a terminating pod (that is removed from a service) might still receive requests.
README.md
Outdated
| @@ -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. | |||
README.md
Outdated
|
|
||
| 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. | ||
|
|
||
| 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.
Can you give a specific example of "load-balancer". e.g., the nginx ingress controller.
No description provided.