Health Check

    By creating an resource we can instruct a data plane proxy to keep track of the health status for any other data plane proxy. When health-checks are properly configured, a data plane proxy will never send a request to another data plane proxy that is considered unhealthy. When an unhealthy proxy returns to a healthy state, Kuma will resume sending requests to it again.

    This policy provides active checks. If you want to configure passive checks, please utilize the Circuit Breaker policy. Data plane proxies with active checks will explicitly send requests to other data plane proxies to determine if target proxies are healthy or not. This mode generates extra traffic to other proxies and services as described in the policy configuration.

    The HealthCheck policy supports both L4/TCP (default) and L7/HTTP checks.

    If you want to add two health checks - one TCP and other HTTP you can specify both in one manifest.

    1. type: HealthCheck
    2. name: web-to-backend-check
    3. mesh: default
    4. sources:
    5. - match:
    6.     kuma.io/service: web
    7. destinations:
    8. - match:
    9.     kuma.io/service: backend
    10. conf:
    11.   interval: 10s
    12.   timeout: 2s
    13.   unhealthyThreshold: 3
    14.   initialJitter: 5s # optional
    15.   intervalJitter: 6s # optional
    16.   intervalJitterPercent: 10 # optional
    17.   healthyPanicThreshold: 60 # optional, by default 50
    18.   failTrafficOnPanic: true # optional, by default false
    19.   noTrafficInterval: 10s # optional, by default 60s
    20.   eventLogPath: "/tmp/health-check.log" # optional
    21.   alwaysLogHealthCheckFailures: true # optional, by default false
    22.   reuseConnection: false # optional, by default true
    23.   tcp:
    24.     send: Zm9v
    25.     receive:
    26.     - YmFy
    27.     - YmF6
    28.   http:
    29.     path: /health
    30.     requestHeadersToAdd:
    31.     - append: false
    33.         value: application/json
    34.     - header:
    35.         key: Accept
    36.         value: application/json
    37.     expectedStatuses: [200, 201]

    We will apply the configuration with kumactl apply -f [..] or via the .

    HTTP health checks are executed using HTTP 2

    • path - HTTP path which will be requested during the health checks
    • expectedStatuses (optional) - list of status codes which should be considered as a healthy during the checks
      • only statuses in the range [100, 600) are allowed
      • by default, when this property is not provided only responses with status code 200 are being considered healthy
    • requestHeadersToAdd (optional) - list of headers which should be added to every health check request:
      • append (default, optional) - should the value of the provided header be appended to already existing headers (if present)
      • header:
        • key - the name of the header
        • value (optional) - the value of the header
    • send - Base64 encoded content of the message which should be sent during the health checks
    • receive list of Base64 encoded blocks of strings which should be found in the returning message which should be considered as healthy
      • when checking the response, “fuzzy” matching is performed such that each block must be found, and in the order specified, but not necessarily contiguous;

    Matching