donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
7bcb54c4647589f64c703fd0de34b9c9ea759661
llm-wiki/raw/official-docs/k8s-pod-lifecycle-probes-concept.md
T

11 KiB
Raw 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
Kubernetes — Pod Lifecycle / Container Probes (Concept Page) official-doc https://kubernetes.io/docs/concepts/workloads/pods/probes/ raw high
ca-skeleton
runtime
health
lifecycle
kubernetes
probe
timeout
ca-skeleton-operational-contract
feature-runtime-health-lifecycle-contract
2026-05-27 2026-05-27

Kubernetes — Pod Lifecycle / Container Probes (Concept Page)

Layer: raw/official-docs/ — Kubernetes 공식 concept 페이지 "Liveness, Readiness, and Startup Probes" 의 probe 종류 / probe 메커니즘 / probe outcome / 설정 필드 원문 발췌. timeoutSeconds vs periodSeconds 의 의미 구분이 본 capture 의 핵심.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-runtime-health-lifecycle-contract D7 timeoutSeconds vs periodSeconds 의미 구분 (timeout 은 단일 probe 호출의 응답 대기, period 는 probe 반복 주기) 의 외부 근거 + probe outcome (Success/Failure/Unknown) 의미 정의

컨텍스트

ca-tmpl feature-runtime-health-lifecycle-contract 의 D7 은 timeoutSeconds 와 periodSeconds 의 의미를 분명히 구분 — timeoutSeconds 는 단일 probe 호출의 응답 대기 시간, periodSeconds 는 probe 호출의 반복 주기. 본 source 는 그 구분의 K8s 공식 정의.

추가로 probe 의 4가지 메커니즘 (exec / httpGet / tcpSocket / grpc) 과 outcome 3종 (Success / Failure / Unknown) 의 공식 verbatim 정의도 함께 capture — ca-tmpl 의 health endpoint 가 httpGet 으로 정의된 근거 + readiness fail 시 동작 정의.

출처 / Source

왜 저장했는지 / Why archived

timeoutSeconds 와 periodSeconds 가 혼동되는 흔한 오해를 막기 위해 두 필드의 의미가 다른 시간 차원 임을 공식 verbatim 으로 보존. 또한 4가지 probe 메커니즘과 3가지 outcome 의 공식 정의를 단일 source 로 통합 보존.

핵심 인용 / Key quotes (verbatim)

[§Types of probe — Startup] "Startup probes verify whether the application within a container is started."

[§Types of probe — Liveness] "Liveness probes determine when to restart a container."

[§Types of probe — Readiness] "Readiness probes determine when a container is ready to accept traffic."

[§Probe mechanisms — exec] "Executes a specified command inside the container. The diagnostic is considered successful if the command exits with a status code of 0."

[§Probe mechanisms — httpGet] "Performs an HTTP GET request against the Pod's IP address on a specified port and path. The diagnostic is considered successful if the response has a status code greater than or equal to 200 and less than 400."

[§Probe mechanisms — tcpSocket] "Performs a TCP check against the Pod's IP address on a specified port. The diagnostic is considered successful if the port is open."

[§Probe mechanisms — grpc] "Performs a remote procedure call using gRPC. The target should implement gRPC health checks. The diagnostic is considered successful if the status of the response is SERVING."

[§Probe outcome — Success] "The container passed the diagnostic."

[§Probe outcome — Failure] "The container failed the diagnostic. For liveness and startup probes, the kubelet kills the container, and the container is subjected to its restart policy. For readiness probes, the kubelet marks the container as not ready, and the Pod stops receiving traffic from matching Services."

[§Probe outcome — Unknown] "The diagnostic failed (no action should be taken, and the kubelet will make further checks)."

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
K8S-POD-LC-C1 startup probe 의 정의는 컨테이너 안의 애플리케이션이 시작되었는지 검증 [§Types — Startup] "Startup probes verify whether the application within a container is started." official-vendor-doc 모든 startup probe startup probe 가 readiness 의미를 가진다는 뜻은 아님 (시작 완료 ≠ 트래픽 수신 준비)
K8S-POD-LC-C2 liveness probe 의 정의는 컨테이너 재시작 시점을 결정 [§Types — Liveness] "Liveness probes determine when to restart a container." official-vendor-doc 모든 liveness probe 외부 dependency 장애 시 재시작 여부는 본 인용 범위 밖 (best practice 영역)
K8S-POD-LC-C3 readiness probe 의 정의는 컨테이너가 트래픽 수신 준비됐는지 결정 [§Types — Readiness] "Readiness probes determine when a container is ready to accept traffic." official-vendor-doc 모든 readiness probe 트래픽 차단 메커니즘의 detail (EndpointSlice 등) 은 별도 page
K8S-POD-LC-C4 httpGet probe 는 Pod IP + port + path 에 HTTP GET 을 보내고, 응답 status code 가 200 이상 400 미만일 때 success [§Probe mechanisms — httpGet] "Performs an HTTP GET request against the Pod's IP address on a specified port and path. The diagnostic is considered successful if the response has a status code greater than or equal to 200 and less than 400." official-vendor-doc httpGet 메커니즘을 쓰는 모든 probe 응답 body / header 가 평가에 사용되지 않는다 는 명시는 본 인용에 없음 (관습적으로 status code 만 평가)
K8S-POD-LC-C5 exec probe 는 컨테이너 내부에서 명령을 실행하고, exit code 0 일 때 success [§Probe mechanisms — exec] "Executes a specified command inside the container. The diagnostic is considered successful if the command exits with a status code of 0." official-vendor-doc exec 메커니즘 probe 명령 실행 비용 / 리소스 사용은 본 인용 범위 밖
K8S-POD-LC-C6 tcpSocket probe 는 Pod IP + port 에 TCP 연결을 시도하고 포트가 열려 있으면 success [§Probe mechanisms — tcpSocket] "Performs a TCP check against the Pod's IP address on a specified port. The diagnostic is considered successful if the port is open." official-vendor-doc tcpSocket 메커니즘 probe TCP 연결 성공이 애플리케이션 레이어 health 를 증명하지 않음 은 공식 경고로 별도
K8S-POD-LC-C7 grpc probe 는 gRPC RPC 호출이며 target 은 gRPC health check 를 구현해야 하고, response 의 status 가 SERVING 이면 success [§Probe mechanisms — grpc] "Performs a remote procedure call using gRPC. The target should implement gRPC health checks. The diagnostic is considered successful if the status of the response is SERVING." official-vendor-doc grpc 메커니즘 probe gRPC health check 프로토콜 spec 자체는 별도 (grpc/grpc-proto/health/v1)
K8S-POD-LC-C8 probe outcome 의 Failure 시: liveness · startup probe 는 kubelet 이 컨테이너를 kill 후 restart policy 적용, readiness probe 는 컨테이너를 not ready 마킹 + Pod 가 매칭 Service 의 트래픽 수신 중지 [§Probe outcome — Failure] "For liveness and startup probes, the kubelet kills the container, and the container is subjected to its restart policy. For readiness probes, the kubelet marks the container as not ready, and the Pod stops receiving traffic from matching Services." official-vendor-doc 세 probe 종류 모두 failureThreshold (연속 실패 수) 이전의 단일 실패는 즉시 Failure 가 아님 — 본 인용은 "the container failed" 이후의 동작 정의
K8S-POD-LC-C9 probe outcome 의 Unknown 은 진단 자체가 실패한 케이스이며 아무 액션도 취하지 않고 kubelet 이 후속 검사를 진행 [§Probe outcome — Unknown] "The diagnostic failed (no action should be taken, and the kubelet will make further checks)." official-vendor-doc 진단 실행 자체가 불가능한 케이스 (네트워크 오류 등) Unknown 이 카운트에 어떻게 반영되는지 (failureThreshold 영향) 는 본 인용 범위 밖

Strength

모두 official-vendor-doc (Kubernetes Project concept page).

Note on D7 (timeoutSeconds vs periodSeconds)

본 fetch 응답에서 configuration fields 의 periodSeconds / timeoutSeconds 정의 sentence 가 truncate 되었음. 두 필드의 의미 구분 은 본 capture 의 4가지 probe 메커니즘 (모두 단일 호출 = timeout 적용 대상) 과 outcome (= 호출 결과) 의 정의를 통해 간접적 으로 정당화 가능: probe 가 "단일 호출" 의 결과를 평가하므로 timeout 은 호출 단위, period 는 반복 주기. 단, 단일 문장 verbatim 은 별도 fetch 또는 runtime-health-k8s-probes-official.md 의 periodSeconds default 10s 인용과 조합 필요.

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • K8S-POD-LC-C1 ~ C3: 세 probe 종류의 정의 (verbatim)
    • K8S-POD-LC-C4 ~ C7: 4가지 probe 메커니즘의 success 조건 (verbatim)
    • K8S-POD-LC-C8 ~ C9: 3가지 outcome 의 동작 정의 (verbatim)
  • 이 자료가 증명하지 않는 것:
    • periodSeconds 와 timeoutSeconds 의 단일 문장 정의 — 본 capture 에서 truncate (구분의 의미론적 근거 는 메커니즘/outcome 정의로 재구성 가능)
    • failureThreshold 와 outcome 의 관계 (몇 번 실패 후 Failure 처리?)
    • probe 의 default 값들
  • 내 프로젝트 (ca-tmpl) 에 적용하려면 추가 확인이 필요한 것:
    • ca-tmpl 의 health endpoint 가 httpGet 의 success 조건 (status 200~399) 을 만족하는지 (Spring Boot Actuator health endpoint 의 응답 코드 매핑 검증 — actuator group → HTTP status 매핑 확인)
    • ca-tmpl 의 readiness probe 가 Failure → traffic stop 의 의미를 의도한 트래픽 차단 흐름과 일치하는지

메모 / Notes

  • 본 capture 는 runtime-health-k8s-probes-official.md (probe 의 의미 + EndpointSlice 동작) 의 sister capture — 본 문서는 메커니즘 (how to probe) + outcome (what happens on fail) 정의에 집중.
  • timeoutSeconds vs periodSeconds 의 단일 문장 verbatim 은 별도 fetch 필요:
  • WebFetch 응답이 configuration fields 직전에 truncate 됨 — anchor #configuration 직접 fetch 권고.

Related / 관련

Reference in New Issue View Git Blame Copy Permalink