CODEWITHSUNDEEP
kubernetesgoogle-cloud-platformgoogle-kubernetes-enginebasic-authenticationhealth-check
realworld
realworld

Reputation: 159

How to set basic auth to Kubernetes' readinessProbe correctly?

How to set basic auth to Kubernetes' readinessProbe correctly?

If set this config for Kubernetes' readinessProbe in deployment kind.

readinessProbe:
  httpGet:
    path: /healthcheck
    port: 8080
    httpHeaders:
    - name: Authorization
      value: Basic <real base64 encoded data>

Deploy it to GKE, GCP's health check can't pass to access the inside application with using basic authentication.

But from here, it seems it should use this syntax. Why can't pass?

The server side is using JSON response at the /healthcheck point. Is it also necessary to set Accept or Content-Type to the httpHeaders?

And, is it good to set this health check to livenessProbe or readinessProbe?

Upvotes: 1

Views: 1543

Answers (1)

Pulak Kanti Bhowmick
Pulak Kanti Bhowmick

Reputation: 1255

According to kubernetes doc:

If the process in your container is able to crash on its own whenever it encounters an issue or becomes unhealthy, you do not necessarily need a liveness probe; the kubelet will automatically perform the correct action in accordance with the Pod's restartPolicy. If you'd like your container to be killed and restarted if a probe fails, then specify a liveness probe, and specify a restartPolicy of Always or OnFailure.

Ref: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-liveness-probe

If you'd like to start sending traffic to a Pod only when a probe succeeds, specify a readiness probe. In this case, the readiness probe might be the same as the liveness probe, but the existence of the readiness probe in the spec means that the Pod will start without receiving any traffic and only start receiving traffic after the probe starts succeeding. If your container needs to work on loading large data, configuration files, or migrations during startup, specify a readiness probe.

Ref: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-readiness-probe

So, you can use health check according to your need. But in kubernetes doc, they give an example of health check as a liveliness probe.

Ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request

And it is the best practice to use Content-Type when you send request other then browser or other typical client. I believe using Content-Type: application/json will solve the issue if other things go right in server side.

Upvotes: 2

Related Questions