Answers: <p>You are most likely using Istio which you did not mention in the question. By default (from version <a href="https://istio.io/latest/news/releases/1.5.x/announcing-1.5.2/" rel="nofollow noreferrer">1.5.2</a>) probe rewrites are enabled. This is required because of mTLS - for more details read the <a href="https://istio.io/latest/docs/ops/configuration/mesh/app-health-check/" rel="nofollow noreferrer">documentation</a>.</p>
  <blockquote>
  <p>The health check requests to the liveness-http service are sent by
  Kubelet. This becomes a problem when mutual TLS is enabled, because
  the Kubelet does not have an Istio issued certificate. Therefore the
  health check requests will fail.</p>
  <p>TCP probe checks need special handling, because Istio redirects all
  incoming traffic into the sidecar, and so all TCP ports appear open.
  The Kubelet simply checks if some process is listening on the
  specified port, and so the probe will always succeed as long as the
  sidecar is running.</p>
  <p>Istio solves both these problems by rewriting the application PodSpec
  readiness/liveness probe, so that the probe request is sent to the
  sidecar agent. For HTTP and gRPC requests, the sidecar agent redirects
  the request to the application and strips the response body, only
  returning the response code. For TCP probes, the sidecar agent will
  then do the port check while avoiding the traffic redirection.</p>
  </blockquote>
  
Answers: CC BY-SA 4.0
Answers: 2023-06-25T15:20:16.730Z
Answers: Brilliant!  This is what I needed to know!!
Answers: Vaccano
Answers: CC BY-SA 4.0
Answers: 2023-06-26T10:14:26.527Z
Answers: Perfect. Good luck.
Answers: Kyslik
Answers: CC BY-SA 4.0
Answers: 2023-06-24T14:35:07.343Z
Answers: 2023-06-24T14:35:07.343Z
Answers: Kyslik
Body: <p>I have a helm chart that defines my container's <code>readinessProbe</code> as:</p>
  <pre><code>readinessProbe:
      httpGet:
        path: /health/readiness
        port: http
  </code></pre>
  <p>And when I deploy it I can browse to <a href="http://myservice.mydomain/istioBasePath/health/readiness" rel="nofollow noreferrer">http://myservice.mydomain/istioBasePath/health/readiness</a> and I get a response of <code>Healthy</code>.</p>
  <p>But if I do a <code>kubectl describe pod</code> on one of the pods that comprise this service, I see this in the details for my container:</p>
  <pre><code>Readiness:  http-get http://:15020/app-health/my-servce-name-is-shown-here/readyz 
  </code></pre>
  <p>Which is not at all what I setup in the deployment for my container. (If nothing else, it has a <code>z</code> in the name.)</p>
  <p>Additionally, when I add the IP address of the container to that URL and run a <code>curl</code> from within the cluster, it does not respond with any text.  Running <code>curl</code> with the <code>-I</code> option shows:</p>
  <pre><code>HTTP/1.1 200 OK
  Date: Wed, 17 May 2023 23:26:11 GMT
  </code></pre>
  <p>(Again, no <code>Healthy</code> text is returned.)</p>
  <p>Something is different here, but I am not quite sure what it is.  The URL for my &quot;Deployment Defined&quot; readiness probe works, but it returns the text <code>Healthy</code>.  The probe defined on the container (that I did not setup, and thought I was overriding with my deployment), just has a Http status result.</p>
  <p>I thought I had only one probe going on, but clearly there is a difference.</p>
  <p>Can someone explain the difference to me?</p>
  
Tags: <kubernetes><healthcheck>
Title: What is the relationship between deployment and container level readiness probes?
UserDisplayName: Vaccano
ThreadText: # What is the relationship between deployment and container level readiness probes?
  
  (Asked by: username_0 on 2023-05-17)
  
  I have a helm chart that defines my container's `readinessProbe` as:
  
  ```
  readinessProbe:
      httpGet:
        path: /health/readiness
        port: http
  
  ```
  
  And when I deploy it I can browse to <http://myservice.mydomain/istioBasePath/health/readiness> and I get a response of `Healthy`.
  
  But if I do a `kubectl describe pod` on one of the pods that comprise this service, I see this in the details for my container:
  
  ```
  Readiness:  http-get http://:15020/app-health/my-servce-name-is-shown-here/readyz 
  
  ```
  
  Which is not at all what I setup in the deployment for my container. (If nothing else, it has a `z` in the name.)
  
  Additionally, when I add the IP address of the container to that URL and run a `curl` from within the cluster, it does not respond with any text. Running `curl` with the `-I` option shows:
  
  ```
  HTTP/1.1 200 OK
  Date: Wed, 17 May 2023 23:26:11 GMT
  
  ```
  
  (Again, no `Healthy` text is returned.)
  
  Something is different here, but I am not quite sure what it is. The URL for my "Deployment Defined" readiness probe works, but it returns the text `Healthy`. The probe defined on the container (that I did not setup, and thought I was overriding with my deployment), just has a Http status result.
  
  I thought I had only one probe going on, but clearly there is a difference.
  
  Can someone explain the difference to me?
  
  **Tags:** kubernetes, healthcheck
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-06-24. Score: 1 | Accepted answer
  
  You are most likely using Istio which you did not mention in the question. By default (from version [1.5.2](https://istio.io/latest/news/releases/1.5.x/announcing-1.5.2/)) probe rewrites are enabled. This is required because of mTLS - for more details read the [documentation](https://istio.io/latest/docs/ops/configuration/mesh/app-health-check/).
  
  > The health check requests to the liveness-http service are sent by
  > Kubelet. This becomes a problem when mutual TLS is enabled, because
  > the Kubelet does not have an Istio issued certificate. Therefore the
  > health check requests will fail.
  >
  > TCP probe checks need special handling, because Istio redirects all
  > incoming traffic into the sidecar, and so all TCP ports appear open.
  > The Kubelet simply checks if some process is listening on the
  > specified port, and so the probe will always succeed as long as the
  > sidecar is running.
  >
  > Istio solves both these problems by rewriting the application PodSpec
  > readiness/liveness probe, so that the probe request is sent to the
  > sidecar agent. For HTTP and gRPC requests, the sidecar agent redirects
  > the request to the application and strips the response body, only
  > returning the response code. For TCP probes, the sidecar agent will
  > then do the port check while avoiding the traffic redirection.
  
  > **Comments:**
  > **username_0**: Brilliant!  This is what I needed to know!!  
  > **username_1**: Perfect. Good luck.  
  
  ---
  
  