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

Expose livenessProbe and readinessProbe headers to consumer (in stable/wordpress) #9390

Merged
merged 5 commits into from Jan 7, 2019

Conversation

@JaredReisinger
Copy link
Contributor

@JaredReisinger JaredReisinger commented Nov 20, 2018

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 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 the httpHeaders array 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:

  • 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.

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

  • DCO signed
  • Chart Version bumped
  • Variables are documented in the README.md
**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>
@JaredReisinger JaredReisinger changed the title Expose livenessProbe and readinessProbe headers to consumer Expose livenessProbe and readinessProbe headers to consumer (in stable/wordpress) Nov 20, 2018
@tompizmor
Copy link
Collaborator

@tompizmor tompizmor commented Nov 29, 2018

LGTM @JaredReisinger,

Can you fix the conflicts in the stable/wordpress/Chart.yaml file so this can be merged?

Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
@JaredReisinger
Copy link
Contributor Author

@JaredReisinger JaredReisinger commented Dec 22, 2018

Sorry for all the noise... I managed to push two commits without the --signoff, and it took a bit for me to unroll the madness. It's all good now!

@tompizmor
Copy link
Collaborator

@tompizmor tompizmor commented Jan 2, 2019

/ok-to-test
/lgtm

@tompizmor
Copy link
Collaborator

@tompizmor tompizmor commented Jan 2, 2019

/retest

1 similar comment
@JaredReisinger
Copy link
Contributor Author

@JaredReisinger JaredReisinger commented Jan 4, 2019

/retest

@JaredReisinger
Copy link
Contributor Author

@JaredReisinger JaredReisinger commented Jan 4, 2019

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?

@tompizmor
Copy link
Collaborator

@tompizmor tompizmor commented Jan 4, 2019

@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.
You need to change it to 5.0.4

stable/wordpress/Chart.yaml Outdated Show resolved Hide resolved
Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
@k8s-ci-robot k8s-ci-robot removed the lgtm label Jan 5, 2019
@helm-bot helm-bot added size/M and removed size/M labels Jan 5, 2019
Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
@helm-bot helm-bot added size/M and removed size/M labels Jan 5, 2019
Copy link
Collaborator

@tompizmor tompizmor left a comment

/ok-to-test
/lgtm

@k8s-ci-robot
Copy link
Contributor

@k8s-ci-robot k8s-ci-robot commented Jan 7, 2019

[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

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot merged commit d2cd36b into helm:master Jan 7, 2019
6 checks passed
@JaredReisinger
Copy link
Contributor Author

@JaredReisinger JaredReisinger commented Jan 9, 2019

Thanks, @tompizmor!

wgiddens added a commit to wgiddens/charts that referenced this issue Jan 18, 2019
…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>
hakamadare added a commit to hakamadare/charts that referenced this issue Jan 29, 2019
…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>
hakamadare added a commit to hakamadare/charts that referenced this issue Jan 29, 2019
…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>
@JaredReisinger JaredReisinger deleted the tweak-probes branch Jul 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants