Expose livenessProbe and readinessProbe headers to consumer (in stable/wordpress)#9390
Conversation
**Problem:** Despite docs that say otherwise, Kubernetes treats a 302 HTTP response as "failed" in liveness and readiness probes. When using ingress-terminated HTTPS, it is common for HTTP requests to WordPress to result in 302-redirects to the HTTPS equivalent. As a result, the container is considered unhealthy/unready. **Solution:** Expose the `httpHeaders` property of the `httpGet` in the probe definition so that consumers can, for example, pass the `X-Forwarded-Proto: https` header to prevent the 302 and instead get a 200 response status. The headers are exposed as optional `livenessProbeHeaders` and `readinessProbeHeaders` arrays, and only included in the deployment definition when defined. * Update `deployment.yaml` to include optional headers. * Update `values.yaml` and `values-production.yaml` with commented-out examples. * Update `README.md` with configuration options, and a more detailed explanation in the Ingress section. * Update `Chart.yaml` version number from `3.3.0` to `3.3.1`. Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
|
LGTM @JaredReisinger, Can you fix the conflicts in the |
9c86b34 to
b032d02
Compare
Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
b032d02 to
d472343
Compare
|
Sorry for all the noise... I managed to push two commits without the |
|
/ok-to-test |
|
/retest |
1 similar comment
|
/retest |
|
Well... that didn't help. The first run failed due to a "volume multi attach" problem, and the retest may have run into the chart version having already been updated once. :-( Any suggestion? |
|
@JaredReisinger you need to bump the chart version again. In this PR you changed it to 5.0.3 but that version is already committed in master because of a different PR has been merged. |
Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JaredReisinger, tompizmor The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Thanks, @tompizmor! |
…e/wordpress) (helm#9390) * Expose livenessProbe and readinessProbe headers to consumer **Problem:** Despite docs that say otherwise, Kubernetes treats a 302 HTTP response as "failed" in liveness and readiness probes. When using ingress-terminated HTTPS, it is common for HTTP requests to WordPress to result in 302-redirects to the HTTPS equivalent. As a result, the container is considered unhealthy/unready. **Solution:** Expose the `httpHeaders` property of the `httpGet` in the probe definition so that consumers can, for example, pass the `X-Forwarded-Proto: https` header to prevent the 302 and instead get a 200 response status. The headers are exposed as optional `livenessProbeHeaders` and `readinessProbeHeaders` arrays, and only included in the deployment definition when defined. * Update `deployment.yaml` to include optional headers. * Update `values.yaml` and `values-production.yaml` with commented-out examples. * Update `README.md` with configuration options, and a more detailed explanation in the Ingress section. * Update `Chart.yaml` version number from `3.3.0` to `3.3.1`. Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com> * bump version Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com> * bump version Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
…e/wordpress) (helm#9390) * Expose livenessProbe and readinessProbe headers to consumer **Problem:** Despite docs that say otherwise, Kubernetes treats a 302 HTTP response as "failed" in liveness and readiness probes. When using ingress-terminated HTTPS, it is common for HTTP requests to WordPress to result in 302-redirects to the HTTPS equivalent. As a result, the container is considered unhealthy/unready. **Solution:** Expose the `httpHeaders` property of the `httpGet` in the probe definition so that consumers can, for example, pass the `X-Forwarded-Proto: https` header to prevent the 302 and instead get a 200 response status. The headers are exposed as optional `livenessProbeHeaders` and `readinessProbeHeaders` arrays, and only included in the deployment definition when defined. * Update `deployment.yaml` to include optional headers. * Update `values.yaml` and `values-production.yaml` with commented-out examples. * Update `README.md` with configuration options, and a more detailed explanation in the Ingress section. * Update `Chart.yaml` version number from `3.3.0` to `3.3.1`. Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com> * bump version Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com> * bump version Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
…e/wordpress) (helm#9390) * Expose livenessProbe and readinessProbe headers to consumer **Problem:** Despite docs that say otherwise, Kubernetes treats a 302 HTTP response as "failed" in liveness and readiness probes. When using ingress-terminated HTTPS, it is common for HTTP requests to WordPress to result in 302-redirects to the HTTPS equivalent. As a result, the container is considered unhealthy/unready. **Solution:** Expose the `httpHeaders` property of the `httpGet` in the probe definition so that consumers can, for example, pass the `X-Forwarded-Proto: https` header to prevent the 302 and instead get a 200 response status. The headers are exposed as optional `livenessProbeHeaders` and `readinessProbeHeaders` arrays, and only included in the deployment definition when defined. * Update `deployment.yaml` to include optional headers. * Update `values.yaml` and `values-production.yaml` with commented-out examples. * Update `README.md` with configuration options, and a more detailed explanation in the Ingress section. * Update `Chart.yaml` version number from `3.3.0` to `3.3.1`. Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com> * bump version Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com> * bump version Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
What this PR does / why we need it:
Problem: Despite docs that say otherwise, Kubernetes treats a 302 HTTP response as "failed" in liveness and readiness probes. (See kubernetes/kubernetes#47893.) When using ingress-terminated HTTPS, it is common for HTTP requests to WordPress to result in 302-redirects to the HTTPS equivalent. As a result, the container is considered unhealthy/unready.
Solution: Expose the
httpHeadersproperty of thehttpGetin the probe definition so that consumers can, for example, pass theX-Forwarded-Proto: httpsheader to prevent the 302 and instead get a 200 response status. The headers are exposed as optionallivenessProbeHeadersandreadinessProbeHeadersarrays, and thehttpHeadersarray is only included in the deployment probe definitions when the respective probe headers are defined.Signed-off-by: Jared Reisinger jaredreisinger@hotmail.com
Which issue this PR fixes
(no existing issues)
Special notes for your reviewer:
deployment.yamlto include optional headers.values.yamlandvalues-production.yamlwith commented-out examples.README.mdwith configuration options, and a more detailed explanation in the Ingress section.Chart.yamlversion number from3.3.0to3.3.1.Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]