When I read all these fancy words in the comments I regard them all as experts in their field. Which makes me a bit nervous that whether I will make it to the other end or not ...but then they all were once a beginner like me. I love how you explained it. I came here after reading an article about it. But you made it quick to grab. Well done.
Why not design K8s such that IF the Readiness and Liveness probes are both defined, then 'initialDelaySeconds' is not required; instead the Liveness probe starts after the Readiness probe succeeds or times-out; as defined by the 'failureThreshold' of the Readiness probe?
I think thi smore like Healcheck feature of AWS for ALB but I like the idea of keeping it at Service or POD level plus auto re configuring/scaling of the whole cluster.
Well thought on the design. I don't know why AWS Lambda or Azure functions come up with this similar implementation and those computes currently cry for cold start.
Should there not be a Dieness as well? If there is something the existing pod needs to complete before it dies, there should be an opportunity given for that as well. Not seeing anything clear on that. Example, sending logs or post-transaction data etc.,
Sorry but this is a bad video. It fails to clearly set the distinction between readiness and liveness probing. The example is overly simplistic: "Your app is still loading" readiness fails. "Your app has a deadlock" liveness fails.
When I read all these fancy words in the comments I regard them all as experts in their field. Which makes me a bit nervous that whether I will make it to the other end or not ...but then they all were once a beginner like me.
I love how you explained it. I came here after reading an article about it. But you made it quick to grab. Well done.
Why not design K8s such that IF the Readiness and Liveness probes are both defined, then 'initialDelaySeconds' is not required; instead the Liveness probe starts after the Readiness probe succeeds or times-out; as defined by the 'failureThreshold' of the Readiness probe?
you can use Startup Probes and then set the initialDelaySeconds to '0' for the Liveness Probe
Nothing is better to learn it from its makers
Excellent series!
I love watching your videos!! ❤️
Excellent video. Thanks for the information.
Our pleasure!
I think thi smore like Healcheck feature of AWS for ALB but I like the idea of keeping it at Service or POD level plus auto re configuring/scaling of the whole cluster.
very well explained!! thanks this helped me a lot.
If kubernetes pod can self heal itself then why we need third party monitoring tools like Prometheus?
Well thought on the design. I don't know why AWS Lambda or Azure functions come up with this similar implementation and those computes currently cry for cold start.
Testing this out next!
Should there not be a Dieness as well? If there is something the existing pod needs to complete before it dies, there should be an opportunity given for that as well. Not seeing anything clear on that. Example, sending logs or post-transaction data etc.,
There are the lifecycle hooks: kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/
What is P99 startup time ? and how to identify it ?
Monitor service startup time and calculate p99 for this metric
@5:00 how to find the average startup time?
Sorry but this is a bad video. It fails to clearly set the distinction between readiness and liveness probing. The example is overly simplistic: "Your app is still loading" readiness fails. "Your app has a deadlock" liveness fails.
4