Skip to content
This repository has been archived by the owner on Feb 22, 2022. It is now read-only.

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>
@helm-bot helm-bot added Contribution Allowed If the contributor has signed the DCO or the CNCF CLA (prior to the move to a DCO). size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Nov 20, 2018
@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

LGTM @JaredReisinger,

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

@helm-bot helm-bot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. Contribution Allowed If the contributor has signed the DCO or the CNCF CLA (prior to the move to a DCO). labels Dec 22, 2018
@helm-bot helm-bot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Dec 22, 2018
Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
@helm-bot helm-bot added Contribution Allowed If the contributor has signed the DCO or the CNCF CLA (prior to the move to a DCO). size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Dec 22, 2018
@JaredReisinger
Copy link
Contributor Author

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

/ok-to-test
/lgtm

@k8s-ci-robot k8s-ci-robot added ok-to-test lgtm Indicates that a PR is ready to be merged. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Jan 2, 2019
@tompizmor
Copy link
Collaborator

/retest

1 similar comment
@JaredReisinger
Copy link
Contributor Author

/retest

@JaredReisinger
Copy link
Contributor Author

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

@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

Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
@k8s-ci-robot k8s-ci-robot removed the lgtm Indicates that a PR is ready to be merged. label Jan 5, 2019
@helm-bot helm-bot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Jan 5, 2019
Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
@helm-bot helm-bot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Jan 5, 2019
Copy link
Collaborator

@tompizmor tompizmor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/ok-to-test
/lgtm

@k8s-ci-robot
Copy link
Contributor

[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 added the lgtm Indicates that a PR is ready to be merged. label Jan 7, 2019
@k8s-ci-robot k8s-ci-robot merged commit d2cd36b into helm:master Jan 7, 2019
@JaredReisinger
Copy link
Contributor Author

Thanks, @tompizmor!

wgiddens pushed a commit to wgiddens/charts that referenced this pull request 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 pushed a commit to hakamadare/charts that referenced this pull request 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 pushed a commit to hakamadare/charts that referenced this pull request 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 July 16, 2019 22:49
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. Contribution Allowed If the contributor has signed the DCO or the CNCF CLA (prior to the move to a DCO). lgtm Indicates that a PR is ready to be merged. ok-to-test size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants