Skip to content
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

Helm chart's liveness/readiness probe fails #3323

Open
ShavaShav opened this issue Aug 22, 2023 · 1 comment
Open

Helm chart's liveness/readiness probe fails #3323

ShavaShav opened this issue Aug 22, 2023 · 1 comment

Comments

@ShavaShav
Copy link

ShavaShav commented Aug 22, 2023

Description of problem

Deploying the helm chart, and the kiwi-0 never shows in a ready state due to failing readinessProbes. I'm able to see use the kiwi UI inbetween restarts, so it is in fact ready. It's just that the probes are broken.

Version or commit hash (if applicable)

dd0ccf1

Steps to Reproduce

  1. Deploy helm chart
    1. Set serviceName: {{ include "kiwi.fullname" . }}-http in statefulset spec as the chart seems to be missing this required field on StatefulSet. This is another issue (that might be related specifically to my kubernetes version which is why I didn't open an issue for it) but is easily resolved.
  2. kubectl -n kiwi get pods
  3. kubectl -n kiwi logs -f kiwi-0

Actual results

  1. kiwi-0 ready state is always 0/1, and goes into CrashLoopBackoff after a while since readinessProbes fails every time.
  2. Logs show the readiness probe, returning 400 http status: 10.223.9.1 - - [22/Aug/2023:21:49:12 +0000] "GET /accounts/login/ HTTP/1.1" 400 255 "-" "kube-probe/1.24" "-"

Expected results

kiwi-0 readiness probes should succeed

Additional info (Python traceback, logs, etc.)

I've tried swapping the port in the probes for https and I get the same result, which makes me think that the http probe is actually redirecting to https, but I'm pretty sure the kubernetes livenessProbes/readinessProbes won't work with https which is why it's producing a 400 code.

I've also tried removing the trailing slash (path: /account/login), but then the probe reports a 301.

Workaround:

Use TCP-based probes instead

@nvanlaerebeke
Copy link

Having the probes like this should fix it:

        livenessProbe:
          httpGet:
            path: /accounts/login/
            port: https
            scheme: HTTPS
        readinessProbe:
          httpGet:
            path: /accounts/login/
            port: https
            scheme: HTTPS

Even when the TLS certificate is not valid this will work as the probes do not very the certs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants