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

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>
@k8s-ci-robot k8s-ci-robot requested review from prydonius and sameersbn 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

This comment has been minimized.

Copy link
Collaborator

commented Nov 29, 2018

LGTM @JaredReisinger,

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

@JaredReisinger JaredReisinger force-pushed the JaredReisinger:tweak-probes branch from 9c86b34 to b032d02 Dec 22, 2018
@helm-bot helm-bot added size/M and removed size/M labels Dec 22, 2018
Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
Signed-off-by: Jared Reisinger <jaredreisinger@hotmail.com>
@JaredReisinger JaredReisinger force-pushed the JaredReisinger:tweak-probes branch from b032d02 to d472343 Dec 22, 2018
@JaredReisinger

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Collaborator

commented Jan 2, 2019

/ok-to-test
/lgtm

@tompizmor

This comment has been minimized.

Copy link
Collaborator

commented Jan 2, 2019

/retest

1 similar comment
@JaredReisinger

This comment has been minimized.

Copy link
Contributor Author

commented Jan 4, 2019

/retest

@JaredReisinger

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Collaborator

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

left a comment

/ok-to-test
/lgtm

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

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 added the lgtm label Jan 7, 2019
@k8s-ci-robot k8s-ci-robot merged commit d2cd36b into helm:master Jan 7, 2019
6 checks passed
6 checks passed
DCO DCO
Details
ci/circleci: lint-charts Your tests passed on CircleCI!
Details
ci/circleci: lint-scripts Your tests passed on CircleCI!
Details
dco-labeler All commits have signoff
pull-charts-e2e Job succeeded.
Details
tide In merge pool.
Details
@JaredReisinger

This comment has been minimized.

Copy link
Contributor Author

commented Jan 9, 2019

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 added 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 added 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 JaredReisinger: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
4 participants
You can’t perform that action at this time.