---
title: "Istio — Health Checking of Istio Services (mTLS and Probes)"
source_type: official-doc
url: https://istio.io/latest/docs/ops/configuration/mesh/app-health-check/
archive_url:
status: raw
confidence: high
tags: [ca-skeleton, runtime, health, lifecycle, istio, service-mesh, official-doc]
related_projects: [ca-skeleton-operational-contract]
related_branches: [feature-runtime-health-lifecycle-contract]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# Istio — Health Checking of Istio Services (mTLS and Probes)

> Layer: `raw/official-docs/` — Istio 공식 문서 "Health Checking of Istio Services" 절 verbatim 발췌. ca-tmpl 대안 모델 (mesh-based health) baseline.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-runtime-health-lifecycle-contract]] | ca-tmpl "application 이 직접 actuator health endpoint 책임" 채택의 **대안** (mesh-based health) trade-off baseline |
| [[raw/project-notes/ca-skeleton-operational-contract]] | Group G-D (Runtime health lifecycle) 대안 4 — Service mesh based health (Istio/Linkerd/Consul Connect) baseline |

## 컨텍스트

ca-tmpl `feature-runtime-health-lifecycle-contract`는 application이 직접 `/actuator/health/*`을 노출하는 모델을 채택. 본 source는 대안 — **service mesh가 health를 대신 수행**하는 모델 — 의 trade-off를 baseline으로 보존.

## 출처 / Source

- 원본 URL: https://istio.io/latest/docs/ops/configuration/mesh/app-health-check/
- 아카이브 URL: (미수집)
- 저자 / 조직: Istio Project
- 발행일: rolling docs (Istio 1.x reference)
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim)

> [§Liveness/Readiness probes — mTLS issue] "The health check requests to the `liveness-http` service are sent by Kubelet. This becomes a problem when mutual TLS is enabled, because the Kubelet does not have an Istio issued certificate. Therefore the health check requests will fail."

> [§Probe rewrite mechanism] "Istio solves both these problems by rewriting the application `PodSpec` readiness/liveness probe, so that the probe request is sent to the [sidecar agent]." (The sidecar "redirects the request to the application and strips the response body, only returning the response code.")

> [§Default enablement] "The rewriting of problematic probes is enabled by default in all built-in Istio [configuration profiles]."

> [§Disabling probe rewrite] Two methods to disable: annotate pods with `sidecar.istio.io/rewriteAppHTTPProbers: "false"` or install with `--set values.sidecarInjectorWebhook.rewriteAppHTTPProbe=false`.

> [§Command/exec probes] "The command approach works with no changes required" — exec-based probes operate independently of mTLS concerns.

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| RH-IST-C1 | mTLS 가 활성화된 Istio mesh 에서 **Kubelet 의 httpGet probe 가 실패** — Kubelet 이 Istio issued cert 를 보유하지 않기 때문 | [§Liveness/Readiness probes — mTLS issue] "The health check requests to the `liveness-http` service are sent by Kubelet. This becomes a problem when mutual TLS is enabled, because the Kubelet does not have an Istio issued certificate. Therefore the health check requests will fail." | `official-vendor-doc` | Istio mesh + mTLS 활성화 + httpGet probe | mTLS 가 default 로 STRICT 라는 뜻은 본 인용에 없음 (별도 PeerAuthentication 정책에 따름) |
| RH-IST-C2 | Istio 는 application `PodSpec` 의 readiness/liveness probe 를 rewrite 하여 **probe request 가 sidecar agent 로 전송**되도록 함. sidecar 는 application 으로 redirect 하고 response body 를 strip 한 뒤 response code 만 반환 | [§Probe rewrite mechanism] "Istio solves both these problems by rewriting the application `PodSpec` readiness/liveness probe, so that the probe request is sent to the [sidecar agent]." + "redirects the request to the application and strips the response body, only returning the response code." | `official-vendor-doc` | Istio 의 자동 probe rewrite 활성화 환경 | probe rewrite 가 application 자체의 deadlock 을 감지한다는 뜻은 아님 — sidecar→app HTTP probe 가 통과하면 healthy 로 판정 |
| RH-IST-C3 | probe rewrite 는 **모든 built-in Istio configuration profile 에서 default 활성화** | [§Default enablement] "The rewriting of problematic probes is enabled by default in all built-in Istio [configuration profiles]." | `official-vendor-doc` | Istio 기본 설치 | custom profile 에서도 자동 활성화된다는 뜻은 아님 |
| RH-IST-C4 | probe rewrite 비활성화 방법 2가지: (a) pod annotation `sidecar.istio.io/rewriteAppHTTPProbers: "false"`, (b) 설치 옵션 `--set values.sidecarInjectorWebhook.rewriteAppHTTPProbe=false` | [§Disabling probe rewrite] Two methods to disable: annotate pods with `sidecar.istio.io/rewriteAppHTTPProbers: "false"` or install with `--set values.sidecarInjectorWebhook.rewriteAppHTTPProbe=false`. | `official-vendor-doc` | probe rewrite 비활성화 운영 결정 | 비활성화 후 권장되는 대체 probe 종류는 본 인용 범위 밖 |
| RH-IST-C5 | **exec/command probe** 는 변경 없이 동작 — mTLS 와 무관하게 application container 내부에서 실행되므로 | [§Command/exec probes] "The command approach works with no changes required" — exec-based probes operate independently of mTLS concerns. | `official-vendor-doc` | Istio + mTLS 환경에서 health 구현 선택 | exec probe 가 httpGet probe 와 동일한 fine-grained dependency 분류를 제공한다는 뜻은 아님 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `RH-IST-C1`: mTLS 환경에서 Kubelet httpGet probe 실패 원인
  - `RH-IST-C2`: Istio probe rewrite 의 동작 메커니즘 (kubelet → sidecar → app)
  - `RH-IST-C3`: rewrite 가 default 활성화
  - `RH-IST-C4`: rewrite 비활성화의 정확한 두 가지 방법
  - `RH-IST-C5`: exec probe 가 mTLS 영향 없이 동작
- **이 자료가 증명하지 않는 것**:
  - "Istio 가 `STRICT` mTLS 를 default 사용" — 본 fetch 인용에 없음. 이전 노트의 해당 진술은 **검증 실패**. STRICT/PERMISSIVE 는 PeerAuthentication 정책에 따른 별도 결정.
  - "`PERMISSIVE` PeerAuthentication 또는 `tcpSocket` probe 를 대안으로 권장" — 본 fetch 인용에 없음. 이전 노트의 해당 진술은 **검증 실패** (UNSUPPORTED). 별도 PeerAuthentication 문서로 확인 필요.
  - probe rewrite 가 sidecar 자체의 health 까지 검증한다는 보장 (sidecar 가 healthy 면 통과하므로 false-healthy 가능성은 본 페이지로 직접 입증되지 않음 — interpretation)
  - Linkerd / Consul Connect 의 동등 메커니즘 (별도 vendor doc 필요)
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - ca-tmpl 이 mesh 환경으로 이동할 경우 `/actuator/health/liveness` 와 `/actuator/health/readiness` 의 정확한 path 가 probe rewrite 와 호환되는지
  - mesh 환경에서 Spring Actuator Health Group (fine-grained DB/broker dependency 분류) 의 신호 손실 여부
  - Istio 외 Linkerd / Consul Connect 사용 시 동등 mechanism

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

- 적용 시나리오: Istio / Linkerd / Consul Connect 등 mTLS-by-default service mesh 환경.
- 장점:
  - application code가 health endpoint를 직접 노출하지 않고 mesh가 대신 처리 (별도 healthIndicator 구현 불필요).
  - mTLS 환경에서도 kubelet probe가 정상 동작.
- 단점:
  - **probe가 sidecar에 묶이므로 application 자체의 deadlock을 감지하지 못할 수 있다.** sidecar는 정상이지만 app은 죽어있는 경우 false-healthy.
  - probe 결과의 정확한 의미가 흐려진다 — "sidecar가 살아있다 vs. application이 살아있다"의 구분이 불분명.
  - Spring Actuator Health Group의 fine-grained dependency 분류(DB, broker 등)와 결합되지 않으면 의미 손실.
- ca-tmpl과의 차이: ca-tmpl은 **application이 직접 actuator health endpoint를 책임지는** 모델. mesh-based health는 trade-off로 알아두지만 ca-tmpl default가 아님.
- testability 영향: mesh 환경에서는 contract test에 sidecar 시뮬레이션이 필요해 부담.

## Related / 관련

- 같은 주제 다른 official-doc:
  - (Kubernetes probe spec — 별도 추가 후보)
- 같은 주제 company-tech-blog:
  - [[raw/company-tech-blogs/runtime-health-datadog-engineering-graceful-shutdown]] (shutdown 측면, mesh 와 별개)
- 적용 branch / contract:
  - [[raw/branch-notes/feature-runtime-health-lifecycle-contract]]
  - canonical contract: [[raw/project-notes/ca-skeleton-operational-contract]] (runtime health lifecycle section, 예정)
- 대안 그룹: **Group G-D — Runtime health lifecycle**, 대안 4 — Service mesh based health
- 인용하는 wiki: (미작성)