<p>How to set basic auth to Kubernetes' readinessProbe correctly?</p>
<p>If set this config for Kubernetes' <code>readinessProbe</code> in deployment kind.</p>
<pre><code>readinessProbe:
  httpGet:
    path: /healthcheck
    port: 8080
    httpHeaders:
    - name: Authorization
      value: Basic &lt;real base64 encoded data&gt;
</code></pre>
<p>Deploy it to GKE, GCP's health check can't pass to access the inside application with using basic authentication.</p>
<p>But from <a href="https://stackoverflow.com/a/43948832/15279606">here</a>, it seems it should use this syntax. Why can't pass?</p>
<p>The server side is using JSON response at the /healthcheck point. Is it also necessary to set <code>Accept</code> or <code>Content-Type</code> to the <code>httpHeaders</code>?</p>
<p>And, is it good to set this health check to livenessProbe or readinessProbe?</p>

<p>According to kubernetes doc:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Ref: <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-liveness-probe" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-liveness-probe</a></p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Ref: <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-readiness-probe" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-readiness-probe</a></p>
<p>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.</p>
<p>Ref: <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request</a></p>
<p>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.</p>
