mirror of https://github.com/status-im/consul.git
37 lines
2.7 KiB
Plaintext
37 lines
2.7 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Configure Health Checks for Consul on Kubernetes
|
|
description: >-
|
|
Kubernetes has built-in health probes you can sync with Consul's health checks to ensure service mesh traffic is routed to healthy pods. Learn how to register a TTL Health check and use mutating webhooks to redirect k8s liveness, readiness, and startup probes through Envoy proxies.
|
|
---
|
|
|
|
# Configure Health Checks for Consul on Kubernetes
|
|
|
|
~> This topic requires familiarity with [Kubernetes Health Checks](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
|
|
|
|
This page describes how Consul on Kubernetes will sync the status of Kubernetes health probes of a pod to Consul for service mesh use cases.
|
|
Health check synchronization with Consul is done automatically whenever `connectInject.enabled` is `true`.
|
|
|
|
For each Kubernetes pod that is connect-injected the following will be configured:
|
|
|
|
1. A [TTL health check](/docs/discovery/checks#ttl) is registered within Consul.
|
|
The Consul health check's state will reflect the pod's readiness status,
|
|
which is the combination of all Kubernetes probes registered with the pod.
|
|
|
|
1. If the pod is utilizing [Transparent Proxy](/docs/connect/transparent-proxy) mode, the mutating webhook will mutate all `http` based Startup, Liveness, and Readiness probes in the pod to redirect through the Envoy proxy.
|
|
This is done with [`ExposePaths` configuration](/docs/connect/registration/service-registration#expose-paths-configuration-reference) for each probe so that kubelet can access the endpoint through the Envoy proxy.
|
|
|
|
~> The mutation behavior can be disabled by either setting the `consul.hashicorp.com/transparent-proxy-overwrite-probes` pod annotation to `false` or the `connectInject.defaultOverwriteProbes` Helm value to `false`.
|
|
|
|
When readiness probes are set for a pod, the status of the pod will be reflected within Consul and will cause Consul to redirect service
|
|
mesh traffic to the pod based on the pod's health. If the pod has failing health checks, Consul will no longer use
|
|
the service instance associated with the pod for service mesh traffic. When the pod passes its health checks, Consul will
|
|
then use the respective service instance for service mesh traffic.
|
|
|
|
In the case where no user defined health checks are assigned to a pod, the default behavior is that the Consul health check will
|
|
be marked `passing` until the pod becomes unready.
|
|
|
|
-> It is highly recommended to [enable TLS](/docs/k8s/helm#v-global-tls-enabled) for all production configurations to mitigate any
|
|
security concerns should the pod network ever be compromised. The controller makes calls across the network to Consul agents on all
|
|
nodes so an attacker could potentially sniff ACL tokens *if those calls are not encrypted* via TLS.
|