By declaring a startupProbe, we get the key thing I wanted with #17. It allows our tests to fail if the pod fails to startup, because the pod will not become "Ready" until after startupProbe has succeeded. At the same time, we avoid making several requests to /versions etc after startup which could clutter debug logs etc.
The only point of readinessProbe is if we have multiple replicas, and want to handle our pod crashing unepxectedly, allowing other pods to take the load alone for a while. Similarly, the livenessProbe is a followup to failing readinessProbe, where it would restart itself if it failed unexpectedly for a longer duration.
For now, let's not include such things and settle for whats important - ensuring successful startup before entering Ready state - to help us catch issues.
By declaring a startupProbe, we get the key thing I wanted with #17. It allows our tests to fail if the pod fails to startup, because the pod will not become "Ready" until after startupProbe has succeeded. At the same time, we avoid making several requests to
/versionsetc after startup which could clutter debug logs etc.The only point of readinessProbe is if we have multiple replicas, and want to handle our pod crashing unepxectedly, allowing other pods to take the load alone for a while. Similarly, the livenessProbe is a followup to failing readinessProbe, where it would restart itself if it failed unexpectedly for a longer duration.
For now, let's not include such things and settle for whats important - ensuring successful startup before entering Ready state - to help us catch issues.