donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
main
llm-wiki/raw/official-docs/runtime-health-istio-mesh-health-check.md
T

9.0 KiB
Raw Permalink Blame History

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

핵심 인용 / 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 / 관련

Reference in New Issue View Git Blame Copy Permalink