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
What happened:
[A clear and concise description of what the bug is.]
The CAPMVM controller's readiness probe gets stuck in an endless loop of restarts:
Warning Unhealthy 9h (x2 over 13h) kubelet Liveness probe failed: Get "http://10.244.0.10:9440/healthz": dial tcp 10.244.0.10:9440: connect: connection refused
Warning Unhealthy 9h (x8 over 15h) kubelet Readiness probe failed: Get "http://10.244.0.10:9440/readyz": dial tcp 10.244.0.10:9440: connect: connection refused
In the logs above^, the liveness probe (which occurs right before the readiness probe) passes much faster and does not get stuck in a loop of restarts, probably because it is configured to have more time:
# The initial delay for the liveness probe is intentionally large to
# avoid an endless kill & restart cycle if in the event that the initial
# bootstrapping takes longer than expected.
initialDelaySeconds: 120
What did you expect to happen:
I expected the readiness probe to not get stuck as much / wait for longer, similarly to the liveness probe :)
How to reproduce it:
I am using docker.io/niki2401/flintlock-kernel:5.10.77 as a kernel image and mounting it as an additional volume as well.
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Environment:
capmvm version:v0.7.0
OS (e.g. from /etc/os-release):
The text was updated successfully, but these errors were encountered:
What happened:
[A clear and concise description of what the bug is.]
The CAPMVM controller's readiness probe gets stuck in an endless loop of restarts:
In the logs above^, the liveness probe (which occurs right before the readiness probe) passes much faster and does not get stuck in a loop of restarts, probably because it is configured to have more time:
What did you expect to happen:
I expected the readiness probe to not get stuck as much / wait for longer, similarly to the liveness probe :)
How to reproduce it:
I am using
docker.io/niki2401/flintlock-kernel:5.10.77
as a kernel image and mounting it as an additional volume as well.Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Environment:
v0.7.0
/etc/os-release
):The text was updated successfully, but these errors were encountered: