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

stable/wordpress/Chart.yaml

@@ -1,5 +1,5 @@
 name: wordpress
-version: 5.0.3
+version: 5.0.4
 appVersion: 5.0.2
 description: Web publishing platform for building blogs and websites.
 icon: https://bitnami.com/assets/stacks/wordpress/img/wordpress-stack-220x234.png

stable/wordpress/README.md

@@ -87,6 +87,8 @@ The following table lists the configurable parameters of the WordPress chart and
 | `service.nodePorts.http`                 | Kubernetes http node port                  | `""`                                                    |
 | `service.nodePorts.https`                | Kubernetes https node port                 | `""`                                                    |
 | `healthcheckHttps`               | Use https for liveliness and readiness     | `false`                                                 |
+| `livenessProbeHeaders`           | Headers to use for livenessProbe           | `nil`                                                   |
+| `readinessProbeHeaders`          | Headers to use for readinessProbe          | `nil`                                                   |
 | `ingress.enabled`                | Enable ingress controller resource         | `false`                                                 |
 | `ingress.hosts[0].name`          | Hostname to your WordPress installation    | `wordpress.local`                                       |
 | `ingress.hosts[0].path`          | Path within the url structure              | `/`                                                     |
@@ -246,6 +248,21 @@ kubectl create secret tls wordpress.local-tls --key /path/to/key.key --cert /pat
 Please see [this example](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx/examples/tls)
 for more information.
 
+### Ingress-terminated https
+
+In cases where HTTPS/TLS is terminated on the ingress, you may run into an issue where non-https liveness and readiness probes result in a 302 (redirect from HTTP to HTTPS) and are interpreted by Kubernetes as not-live/not-ready.  (See [Kubernetes issue #47893 on GitHub](https://github.com/kubernetes/kubernetes/issues/47893) for further details about 302 _not_ being interpreted as "successful".)  To work around this problem, use `livenessProbeHeaders` and `readinessProbeHeaders` to pass the same headers that your ingress would pass in order to get an HTTP 200 status result.  For example (where the following is in a `--values`-referenced file):
+
+```
+livenessProbeHeaders:
+- name: X-Forwarded-Proto
+  value: https
+readinessProbeHeaders:
+- name: X-Forwarded-Proto
+  value: https
+```
+
+Any number of name/value pairs may be specified; they are all copied into the liveness or readiness probe definition.
+
 ## Upgrading
 
 ### To 3.0.0

stable/wordpress/templates/deployment.yaml

@@ -142,6 +142,10 @@ spec:
             port: https
             scheme: HTTPS
           {{- end }}
+          {{- if .Values.livenessProbeHeaders }}
+            httpHeaders:
+{{ toYaml .Values.livenessProbeHeaders | indent 14 }}
+          {{- end }}
 {{ toYaml .Values.livenessProbe | indent 10 }}
         readinessProbe:
           httpGet:
@@ -152,6 +156,10 @@ spec:
             port: https
             scheme: HTTPS
           {{- end }}
+          {{- if .Values.readinessProbeHeaders }}
+            httpHeaders:
+{{ toYaml .Values.readinessProbeHeaders | indent 14 }}
+          {{- end }}
 {{ toYaml .Values.readinessProbe | indent 10 }}
         volumeMounts:
         - mountPath: /bitnami/apache

stable/wordpress/values-production.yaml

@@ -172,6 +172,16 @@ readinessProbe:
   timeoutSeconds: 5
   failureThreshold: 6
   successThreshold: 1
+## If using an HTTPS-terminating load-balancer, the probes may need to behave
+## like the balancer to prevent HTTP 302 responses.  According to the Kubernetes
+## docs, 302 should be considered "successful", but this issue on GitHub
+## (https://github.com/kubernetes/kubernetes/issues/47893) shows that it isn't.
+# livenessProbeHeaders:
+# - name: X-Forwarded-Proto
+#   value: https
+# readinessProbeHeaders:
+# - name: X-Forwarded-Proto
+#   value: https
 
 ## Configure the ingress resource that allows you to access the
 ## Wordpress installation. Set up the URL

stable/wordpress/values.yaml

@@ -175,6 +175,16 @@ readinessProbe:
   timeoutSeconds: 5
   failureThreshold: 6
   successThreshold: 1
+## If using an HTTPS-terminating load-balancer, the probes may need to behave
+## like the balancer to prevent HTTP 302 responses.  According to the Kubernetes
+## docs, 302 should be considered "successful", but this issue on GitHub
+## (https://github.com/kubernetes/kubernetes/issues/47893) shows that it isn't.
+# livenessProbeHeaders:
+# - name: X-Forwarded-Proto
+#   value: https
+# readinessProbeHeaders:
+# - name: X-Forwarded-Proto
+#   value: https
 
 ## Configure the ingress resource that allows you to access the
 ## Wordpress installation. Set up the URL