Health Check

    This policy enables Kuma to keep track of the health of every data plane proxy, with the goal of minimizing the number of failed requests in case a data plane proxy is temporarily unhealthy.

    By creating an HealthCheck 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.

    As usual, we can apply sources and destinations selectors to determine how health-checks will be performed across our data plane proxies.

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

    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.   healthyThreshold: 1
    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: # only one of tcp or http can be defined
    24.     send: Zm9v
    25.     receive:
    26.     - YmFy
    27.     - YmF6
    28.   http:
    29.     path: /health
    30.     requestHeadersToAdd:
    31.     - append: false
    32.         key: Content-Type
    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 API.

    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;
      • if receive section won’t be provided or will be empty, checks will be performed as “connect only” and will be marked as successful when TCP connection will be successfully established.

    Matching