Configure liveness and readiness probes

In Astronomer Software, you can create liveness and readiness probes to assess whether your Kubernetes Pods or network are healthy and can process requests.

Some components in Astronomer Software include liveness and readiness probes by default, but all components support adding and configuring them. Astronomer Software allows you to use the Kubernetes liveness and readiness probe definitions so you can monitor the state of your Pods.

Default probe behavior

You can use the following structure to define your probes in your values.yaml file. For example, you might want to adjust any default values by configuring the amount of time until a timeout.

You can add any definitions that are compatible with Kubernetes probes.

Liveness probe template

1
livenessProbe:
2
  enabled: true
3
  httpGet:
4
    path: /index.html
5
    port: 443

Readiness probe template

1
readinessProbe:
2
  enabled: true
3
  httpGet:
4
    path: /index.html
5
    port: 444

Retrieve existing probe definitions

You can retrieve the default probe definitions from the Kubernetes manifest. The following example shows how to retrieve the definitions for Houston.

$
kubectl -n "${NAMESPACE}" get deployment -l component=houston -o yaml

This command produces a large amount of yaml output describing your Houston configuration. Within this output, is a section describing the livenessProbe, which looks like the following:

1
livenessProbe:
2
  failureThreshold: 10
3
  httpGet:
4
    path: /v1/healthz
5
    port: 8871
6
    scheme: HTTP
7
  initialDelaySeconds: 30
8
  periodSeconds: 10
9
  successThreshold: 1
10
  timeoutSeconds: 1

You can copy and paste this output into your values.yaml file for your Houston configuration, then adjust the values you want to customize. Then apply a platform config change.

Reference Helm values within your probes

Because values for the liveness and readiness probes are passed through the Helm template function, you can reference Helm values within the probes. Specifically, the livenessProbe and readiness values are rendered to yaml, then passed through the Helm template function, which renders any Helm template syntaxes into the produced yaml.

For example, instead of hardcoding values for your probes to match values defined by other configurations in your values.yaml file, you can use the configuration variable itself.

The following example, using the alertsmanager yaml configuration, shows how the path and ports are defined by Values.ports.http and Values.prefixURL elsewhere in the values.yaml file.

1
readinessProbe:
2
  httpGet:
3
    path: {{ .Values.prefixURL }}/#/status
4
    port: {{ .Values.ports.http }}
5
  initialDelaySeconds: 30
6
  timeoutSeconds: 30