コンテンツにスキップ
Kong Logo | Kong Docs Logo
  • ドキュメント
    • API仕様を確認する
      View all API Specs すべてのAPI仕様を表示 View all API Specs arrow image
    • ドキュメンテーション
      API Specs
      Kong Gateway
      軽量、高速、柔軟なクラウドネイティブAPIゲートウェイ
      Kong Konnect
      SaaSのエンドツーエンド接続のための単一プラットフォーム
      Kong AI Gateway
      GenAI インフラストラクチャ向けマルチ LLM AI Gateway
      Kong Mesh
      Kuma と Envoy をベースにしたエンタープライズサービスメッシュ
      decK
      Kongの構成を宣言型で管理する上で役立ちます
      Kong Ingress Controller
      Kubernetesクラスタ内で動作し、Kongをプロキシトラフィックに設定する
      Kong Gateway Operator
      YAMLマニフェストを使用してKubernetes上のKongデプロイメントを管理する
      Insomnia
      コラボレーティブAPI開発プラットフォーム
  • Plugin Hub
    • Plugin Hubを探索する
      View all plugins すべてのプラグインを表示 View all plugins arrow image
    • 機能性 すべて表示 View all arrow image
      すべてのプラグインを表示
      AI's icon
      AI
      マルチ LLM AI Gatewayプラグインを使用してAIトラフィックを管理、保護、制御する
      認証's icon
      認証
      認証レイヤーでサービスを保護する
      セキュリティ's icon
      セキュリティ
      追加のセキュリティレイヤーでサービスを保護する
      トラフィック制御's icon
      トラフィック制御
      インバウンドおよびアウトバウンドAPIトラフィックの管理、スロットル、制限
      サーバーレス's icon
      サーバーレス
      他のプラグインと組み合わせてサーバーレス関数を呼び出します
      分析と監視's icon
      分析と監視
      APIとマイクロサービストラフィックを視覚化、検査、監視
      変革's icon
      変革
      Kongでリクエストとレスポンスをその場で変換
      ログ記録's icon
      ログ記録
      インフラストラクチャに最適なトランスポートを使用して、リクエストと応答データをログに記録します
  • サポート
  • コミュニティ
  • Kongアカデミー
デモを見る 無料トライアルを開始
Kong Mesh
2.6.x
  • Home icon
  • Kong Mesh
  • Policies
  • Health Check
report-issue問題を報告する
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Kong AI Gateway
  • Plugin Hub
  • decK
  • Kong Ingress Controller
  • Kong Gateway Operator
  • Insomnia
  • Kuma

  • ドキュメント投稿ガイドライン
  • 2.10.x (latest)
  • 2.9.x
  • 2.8.x
  • 2.7.x (LTS)
  • 2.6.x
  • 2.5.x
  • 2.4.x
  • 2.3.x
  • 2.2.x
  • Introduction
    • About service meshes
    • Overview of Kong Mesh
    • How Kong Mesh works
    • Architecture
    • Stages of software availability
    • Version support policy
    • Mesh requirements
    • Release notes
  • Quickstart
    • Deploy Kong Mesh on Kubernetes
    • Deploy Kong Mesh on Universal
  • Kong Mesh in Production
    • Overview
    • Deployment topologies
      • Overview
      • Single-zone deployment
      • Multi-zone deployment
    • Install kumactl
    • Use Kong Mesh
    • Control plane deployment
      • Kong Mesh license
      • Deploy a single-zone control plane
      • Deploy a multi-zone global control plane
      • Zone Ingress
      • Zone Egress
      • Configure zone proxy authentication
      • Control plane configuration reference
      • Systemd
      • Kubernetes
      • kumactl
    • Configuring your Mesh and multi-tenancy
    • Data plane configuration
      • Data plane proxy
      • Configure the data plane on Kubernetes
      • Configure the data plane on Universal
      • Configure the Kong Mesh CNI
      • Configure transparent proxying
      • IPv6 support
    • Secure your deployment
      • Manage secrets
      • Authentication with the API server
      • Authentication with the data plane proxy
      • Configure data plane proxy membership
      • Secure access across services
      • Kong Mesh RBAC
      • FIPS support
    • Kong Mesh user interface
    • Inspect API
      • Matched policies
      • Affected data plane proxies
      • Envoy proxy configuration
    • Upgrades and tuning
      • Upgrade Kong Mesh
      • Performance fine-tuning
      • Version specific upgrade notes
    • Control Plane Configuration
      • Modifying the configuration
      • Inspecting the configuration
      • Store
  • Using Kong Mesh
    • Zero Trust & Application Security
      • Mutual TLS
      • External Service
    • Resiliency & Failover
      • Dataplane Health
      • Service Health Probes
    • Managing incoming traffic with gateways
      • How ingress works in Kuma
      • Delegated gateways
      • Built-in gateways
      • Running built-in gateway pods on Kubernetes
      • Configuring built-in listeners
      • Configuring built-in routes
      • Using the Kubernetes Gateway API
    • Observability
      • Demo setup
      • Control plane metrics
      • Configuring Prometheus
      • Configuring Grafana
      • Configuring Datadog
      • Observability in multi-zone
    • Route & Traffic shaping
      • Protocol support in Kong Mesh
    • Service Discovery & Networking
      • Service Discovery
      • DNS
      • Non-mesh traffic
      • Transparent Proxying
  • Policies
    • Introduction
    • Applying Policies
    • Understanding TargetRef policies
    • MeshAccessLog
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshCircuitBreaker
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshFaultInjection
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshHealthCheck
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshHTTPRoute
      • TargetRef support matrix
      • Configuration
      • Examples
      • Merging
    • MeshMetric
      • TargetRef support matrix
      • Configuration
      • Prometheus
      • OpenTelemetry
      • Examples
    • MeshProxyPatch
      • TargetRef support matrix
      • Configuration
      • Examples
      • Merging
    • MeshRateLimit
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshRetry
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshTCPRoute
      • TargetRef support matrix
      • Configuration
      • Examples
      • Route policies with different types targeting the same destination
    • MeshTimeout
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshTrace
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshTrafficPermission
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshLoadBalancingStrategy
      • TargetRef support matrix
      • Configuration
      • Examples
    • MeshOPA (beta)
    • MeshGlobalRateLimit (beta)
    • Previous Policies
      • General notes about Kong Mesh policies
      • How Kong Mesh chooses the right policy to apply
      • Traffic Permissions
      • Traffic Route
      • Traffic Metrics
      • Traffic Trace
      • Traffic Log
      • Locality-aware Load Balancing
      • Fault Injection
      • Health Check
      • Circuit Breaker
      • Retry
      • Timeout
      • Rate Limit
      • Virtual Outbound
      • MeshGatewayRoute
      • OPA policy
  • Guides
    • Federate zone control plane
    • Add a builtin Gateway
    • Add Kong as a delegated Gateway
    • Upgrading Transparent Proxy
  • Enterprise Features
    • Overview
    • HashiCorp Vault CA
    • Amazon ACM Private CA
    • cert-manager Private CA
    • OPA policy support
    • MeshOPA (beta)
    • Multi-zone authentication
    • FIPS support
    • Certificate Authority rotation
    • Role-Based Access Control
    • Red Hat
      • UBI Images
      • Red Hat OpenShift Quickstart
    • Windows Support
    • ECS Support
    • Auditing
    • MeshGlobalRateLimit (beta)
  • Reference
    • HTTP API
    • Kubernetes annotations and labels
    • Kuma data collection
    • Control plane configuration reference
    • Envoy proxy template
  • Community
    • Contribute to Kuma
enterprise-switcher-icon 次に切り替える: OSS
On this pageOn this page
  • Usage
    • Examples
    • HTTP
    • TCP
  • Matching
  • All options

このページは、まだ日本語ではご利用いただけません。翻訳中です。

旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。

Health Check

New to Kuma? You don’t need this policy, check MeshHealthCheck instead. If you want to use the HealthCheck policy, remember that it requires the TrafficRoute policy to function properly.

Health Check is an outbound policy. Dataplanes whose configuration is modified are in the sources matcher.

This policy enables Kong Mesh 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, Kong Mesh 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.

Usage

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.

Examples

Kubernetes
Universal
apiVersion: kuma.io/v1alpha1
kind: HealthCheck
mesh: default
metadata:
  name: web-to-backend-check
spec:
  sources:
  - match:
      kuma.io/service: web_default_svc_80
  destinations:
  - match:
      kuma.io/service: backend_default_svc_80
  conf:
    interval: 10s
    timeout: 2s
    unhealthyThreshold: 3
    healthyThreshold: 1
    initialJitter: 5s # optional
    intervalJitter: 6s # optional
    intervalJitterPercent: 10 # optional
    healthyPanicThreshold: 60 # optional, by default 50
    failTrafficOnPanic: true # optional, by default false
    noTrafficInterval: 10s # optional, by default 60s
    eventLogPath: "/tmp/health-check.log" # optional
    alwaysLogHealthCheckFailures: true # optional, by default false
    reuseConnection: false # optional, by default true
    tcp: # only one of tcp or http can be defined
      send: Zm9v
      receive:
      - YmFy
      - YmF6
    http:
      path: /health
      requestHeadersToAdd:
      - append: false
        header:
          key: Content-Type
          value: application/json
      - header:
          key: Accept
          value: application/json
      expectedStatuses: [200, 201]

We will apply the configuration with kubectl apply -f [..].

type: HealthCheck
name: web-to-backend-check
mesh: default
sources:
- match:
    kuma.io/service: web
destinations:
- match:
    kuma.io/service: backend
conf:
  interval: 10s
  timeout: 2s
  unhealthyThreshold: 3
  healthyThreshold: 1
  initialJitter: 5s # optional
  intervalJitter: 6s # optional
  intervalJitterPercent: 10 # optional
  healthyPanicThreshold: 60 # optional, by default 50
  failTrafficOnPanic: true # optional, by default false
  noTrafficInterval: 10s # optional, by default 60s
  eventLogPath: "/tmp/health-check.log" # optional
  alwaysLogHealthCheckFailures: true # optional, by default false
  reuseConnection: false # optional, by default true
  tcp: # only one of tcp or http can be defined
    send: Zm9v
    receive:
    - YmFy
    - YmF6
  http:
    path: /health
    requestHeadersToAdd:
    - append: false
      header:
        key: Content-Type
        value: application/json
    - header:
        key: Accept
        value: application/json
    expectedStatuses: [200, 201]

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

HTTP

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

TCP

  • 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

HealthCheck is an Outbound Connection Policy. The only supported value for destinations.match is kuma.io/service.

All options

$schema: http://json-schema.org/draft-04/schema#

$ref: #/definitions/HealthCheck

definitions

HealthCheck

  • ## Health Check

  • HealthCheck defines configuration for health checking.

  • Type: object

  • This schema accepts additional properties.

  • Properties

    • sources
      • List of selectors to match dataplanes that should be configured to do health checks.
      • Type: array
        • Items
        • $ref: #/definitions/kuma.mesh.v1alpha1.Selector
    • destinations
      • List of selectors to match services that need to be health checked.
      • Type: array
        • Items
        • $ref: #/definitions/kuma.mesh.v1alpha1.Selector
    • conf
      • Configuration for various types of health checking.
      • Type: object
      • $ref: #/definitions/kuma.mesh.v1alpha1.HealthCheck.Conf
      • This schema accepts additional properties.
      • Properties kuma.mesh.v1alpha1.HealthCheck.Conf
  • ## Conf

  • Conf defines configuration for various types of health checking.

  • Type: object

  • This schema accepts additional properties.

  • Properties

    • interval
      • Interval between consecutive health checks.
      • Type: string
      • String format must be a "regex"
      • The value must match this pattern: ^([0-9]+\.?[0-9]*|\.[0-9]+)s$
    • timeout
      • Maximum time to wait for a health check response.
      • Type: string
      • String format must be a "regex"
      • The value must match this pattern: ^([0-9]+\.?[0-9]*|\.[0-9]+)s$
    • unhealthy_threshold
      • Number of consecutive unhealthy checks before considering a host unhealthy.
      • Type: integer
    • healthy_threshold
      • Number of consecutive healthy checks before considering a host healthy.
      • Type: integer
    • initial_jitter
      • If specified, Envoy will start health checking after for a random time in ms between 0 and initial_jitter. This only applies to the first health check.
      • Type: string
      • String format must be a "regex"
      • The value must match this pattern: ^([0-9]+\.?[0-9]*|\.[0-9]+)s$
    • interval_jitter
      • If specified, during every interval Envoy will add interval_jitter to the wait time.
      • Type: string
      • String format must be a "regex"
      • The value must match this pattern: ^([0-9]+\.?[0-9]*|\.[0-9]+)s$
    • intervaljitterpercent
      • *If specified, during every interval Envoy will add intervalms * intervaljitterpercent / 100 to the wait time. If intervaljitterms and intervaljitter_percent are both set, both of them will be used to increase the wait time.*
      • Type: integer
    • healthypanicthreshold
      • Allows to configure panic threshold for Envoy cluster. If not specified, the default is 50%. To disable panic mode, set to 0%.
      • Type: number
    • failtrafficon_panic
      • If set to true, Envoy will not consider any hosts when the cluster is in 'panic mode'. Instead, the cluster will fail all requests as if all hosts are unhealthy. This can help avoid potentially overwhelming a failing service.
      • Type: boolean
    • eventlogpath
      • Specifies the path to the file where Envoy can log health check events. If empty, no event log will be written.
      • Type: string
    • alwaysloghealthcheckfailures
      • If set to true, health check failure events will always be logged. If set to false, only the initial health check failure event will be logged. The default value is false.
      • Type: boolean
    • notrafficinterval
      • The "no traffic interval" is a special health check interval that is used when a cluster has never had traffic routed to it. This lower interval allows cluster information to be kept up to date, without sending a potentially large amount of active health checking traffic for no reason. Once a cluster has been used for traffic routing, Envoy will shift back to using the standard health check interval that is defined. Note that this interval takes precedence over any other. The default value for "no traffic interval" is 60 seconds.
      • Type: string
      • String format must be a "regex"
      • The value must match this pattern: ^([0-9]+\.?[0-9]*|\.[0-9]+)s$
    • tcp
      • Type: object
      • $ref: #/definitions/kuma.mesh.v1alpha1.HealthCheck.Conf.Tcp
      • This schema accepts additional properties.
      • Properties
    • http
      • Type: object
      • $ref: #/definitions/kuma.mesh.v1alpha1.HealthCheck.Conf.Http
      • This schema accepts additional properties.
      • Properties
    • reuse_connection
      • Reuse health check connection between health checks. Default is true.
      • Type: boolean kuma.mesh.v1alpha1.HealthCheck.Conf.Http
  • ## Http

  • Http defines optional Http configuration which will instruct the service the health check will be made for is an http service. It's mutually exclusive with the Tcp block so when provided you can't provide the Tcp configuration

  • Type: object

  • This schema accepts additional properties.

  • Properties

    • path
      • The HTTP path which will be requested during the health check (ie. /health) +required
      • Type: string
    • requestheadersto_add
      • The list of HTTP headers which should be added to each health check request +optional
      • Type: array
        • Items
        • $ref: #/definitions/kuma.mesh.v1alpha1.HealthCheck.Conf.Http.HeaderValueOption
    • expected_statuses
      • List of HTTP response statuses which are considered healthy +optional
      • Type: array
        • Items
        • ##### U Int 32 Value
        • Wrapper message for uint32. The JSON representation for UInt32Value is JSON number.
        • Type: integer kuma.mesh.v1alpha1.HealthCheck.Conf.Http.HeaderValue
  • ## Header Value

  • Type: object

  • This schema accepts additional properties.

  • Properties

    • key
      • Header name +required
      • Type: string
    • value
      • Header value +optional
      • Type: string kuma.mesh.v1alpha1.HealthCheck.Conf.Http.HeaderValueOption
  • ## Header Value Option

  • Type: object

  • This schema accepts additional properties.

  • Properties

    • header
      • Key/Value representation of the HTTP header +required
      • Type: object
      • $ref: #/definitions/kuma.mesh.v1alpha1.HealthCheck.Conf.Http.HeaderValue
      • This schema accepts additional properties.
      • Properties
    • append
      • The bool value which if true (default) will mean the header values should be appended to already present ones +optional
      • Type: boolean kuma.mesh.v1alpha1.HealthCheck.Conf.Tcp
  • ## Tcp

  • Tcp defines optional configuration for specifying bytes to send and expected response during the health check

  • Type: object

  • This schema accepts additional properties.

  • Properties

    • send
      • Bytes which will be send during the health check to the target
      • Type: string
    • receive
      • Bytes blocks expected as a response. When checking the response, “fuzzy” matching is performed such that each block must be found, and in the order specified, but not necessarily contiguous.
      • Type: array
        • Items
        • ##### Bytes Value
        • Wrapper message for bytes. The JSON representation for BytesValue is JSON string.
        • Type: string kuma.mesh.v1alpha1.Selector
  • ## Selector

  • Selector defines structure for selecting tags for given dataplane

  • Type: object

  • This schema accepts additional properties.

  • Properties

    • match
      • Tags to match, can be used for both source and destinations
      • Type: object
      • This schema accepts additional properties.
      • Properties

Generated with json-schema-md-doc Sat May 10 2025 08:56:41 GMT+0000 (Coordinated Universal Time)

Thank you for your feedback.
Was this page useful?
情報が多すぎる場合 close cta icon
Kong Konnectを使用すると、より多くの機能とより少ないインフラストラクチャを実現できます。月額1Mリクエストが無料。
無料でお試しください
  • Kong
    APIの世界を動かす

    APIマネジメント、サービスメッシュ、イングレスコントローラーの統合プラットフォームにより、開発者の生産性、セキュリティ、パフォーマンスを大幅に向上します。

    • 製品
      • Kong Konnect
      • Kong Gateway Enterprise
      • Kong Gateway
      • Kong Mesh
      • Kong Ingress Controller
      • Kong Insomnia
      • 製品アップデート
      • 始める
    • ドキュメンテーション
      • Kong Konnectドキュメント
      • Kong Gatewayドキュメント
      • Kong Meshドキュメント
      • Kong Insomniaドキュメント
      • Kong Konnect Plugin Hub
    • オープンソース
      • Kong Gateway
      • Kuma
      • Insomnia
      • Kongコミュニティ
    • 会社概要
      • Kongについて
      • お客様
      • キャリア
      • プレス
      • イベント
      • お問い合わせ
  • 利用規約• プライバシー• 信頼とコンプライアンス
© Kong Inc. 2025