Files
llm-wiki/raw/official-docs/k8s-configure-probes-task-page.md
T

8.7 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 — Configure Liveness, Readiness and Startup Probes (Task Page) official-doc https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ raw high
ca-skeleton
runtime
health
lifecycle
kubernetes
probe
startup-probe
ca-skeleton-operational-contract
feature-runtime-health-lifecycle-contract
2026-05-27 2026-05-27

Kubernetes — Configure Liveness, Readiness and Startup Probes (Task Page)

Layer: raw/official-docs/ — Kubernetes 공식 task 페이지의 "Protect slow starting containers with startup probes" 섹션 원문 발췌. K8s probe 설정 task-level guidance 의 SSOT.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-runtime-health-lifecycle-contract D5 startup probe budget 산식 (= failureThreshold × periodSeconds) 채택 근거 + D11 startup validation scope (legacy / slow-starting workload 보호) 정당화

컨텍스트

ca-tmpl feature-runtime-health-lifecycle-contract 의 D5 는 startup probe total budget 을 failureThreshold × periodSeconds 공식으로 산정한다는 결정. 본 source 는 그 산식의 공식 verbatim 원문 — task 페이지의 "Protect slow starting containers with startup probes" 섹션에서 직접 명시된 5분 (30 × 10 = 300s) 예시.

D11 (startup validation scope) 의 "legacy / slow-starting 컨테이너만 사용" 권고 또한 같은 섹션의 "legacy applications that take an enormous amount of time to start up" 인용으로 정당화.

출처 / Source

왜 저장했는지 / Why archived

기존 runtime-health-k8s-probes-official.md 의 K8S-PROBE-C7 이 needs-confirmation 으로 남아 있던 startup probe budget 산식 (= failureThreshold × periodSeconds) 의 단일 문장 verbatim 을 직접 확보. ca-tmpl 의 startup probe = 30 × 5s = 150s 산정의 외부 근거를 official-vendor-doc 강도로 격상.

핵심 인용 / Key quotes (verbatim)

[§Protect slow starting containers with startup probes] "Sometimes, you have to deal with legacy applications that take an enormous amount of time to start up."

[§Protect slow starting containers with startup probes] (YAML example)

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

[§Protect slow starting containers with startup probes] "In the example above, the application will have a maximum of 5 minutes (30 * 10 = 300s) to finish its startup."

[§Protect slow starting containers with startup probes] "Once the startup probe has succeeded once, the liveness probe takes over to provide a fast response to container deadlocks."

[§Protect slow starting containers with startup probes] "If your container usually starts in more than initialDelaySeconds + failureThreshold × periodSeconds, you should specify a startup probe that checks the same endpoint as the liveness probe."

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
K8S-PROBE-TASK-C1 startup probe 의 일차적 정당화 use case 는 시작에 매우 오래 걸리는 legacy 애플리케이션 보호 [§Protect slow starting] "Sometimes, you have to deal with legacy applications that take an enormous amount of time to start up." official-vendor-doc 시작 시간이 일반 컨테이너 budget 을 초과하는 legacy / heavy workload startup probe 가 모든 워크로드 default 라는 뜻은 아님 — 본 인용은 "legacy applications" 에 한정
K8S-PROBE-TASK-C2 startup probe 의 maximum startup budget 은 failureThreshold × periodSeconds 로 결정 (예: 30 × 10 = 300s = 5분) [§Protect slow starting] "In the example above, the application will have a maximum of 5 minutes (30 * 10 = 300s) to finish its startup." official-vendor-doc startup probe 가 설정된 모든 컨테이너 initialDelaySeconds 가 budget 에 포함되는지 여부는 본 인용 단독으로 명시 안 됨 — 다음 C4 인용에서 추가 정보
K8S-PROBE-TASK-C3 startup probe 가 한 번 성공한 이후에는 liveness probe 가 takeover 하여 container deadlock 에 빠른 대응 [§Protect slow starting] "Once the startup probe has succeeded once, the liveness probe takes over to provide a fast response to container deadlocks." official-vendor-doc startup probe 가 설정된 컨테이너 startup probe 성공 후 readiness probe 가 별도 cycle 로 시작한다는 명시는 본 인용 범위 밖
K8S-PROBE-TASK-C4 컨테이너 시작 시간이 initialDelaySeconds + failureThreshold × periodSeconds 보다 일반적으로 길면 liveness 와 같은 endpoint 를 가리키는 startup probe 를 명시해야 함 [§Protect slow starting] "If your container usually starts in more than initialDelaySeconds + failureThreshold × periodSeconds, you should specify a startup probe that checks the same endpoint as the liveness probe." official-vendor-doc liveness probe 가 이미 설정된 컨테이너에서 startup time 이 liveness budget 을 초과하는 경우 startup probe endpoint 가 반드시 liveness 와 달라야 한다거나 같아야 한다는 강제는 아님 — "should... the same endpoint" 는 권고
K8S-PROBE-TASK-C5 startup probe 의 공식 예시 구성은 failureThreshold: 30, periodSeconds: 10 (= 300s budget) 으로 제시됨 [§Protect slow starting] (YAML) "failureThreshold: 30 / periodSeconds: 10" official-vendor-doc K8s 문서의 reference 예시 이 값들이 모든 워크로드의 default 라는 뜻은 아님 — 어디까지나 example

Strength

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

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • K8S-PROBE-TASK-C1: startup probe 의 일차 use case 가 legacy / slow-starting 워크로드 보호
    • K8S-PROBE-TASK-C2: budget 산식 failureThreshold × periodSeconds 의 단일 문장 verbatim (= ca-tmpl D5 의 직접 외부 근거)
    • K8S-PROBE-TASK-C3: startup → liveness takeover 의 의미론
    • K8S-PROBE-TASK-C4: startup probe 가 필요한 조건의 공식 권고 (when to use)
  • 이 자료가 증명하지 않는 것:
    • failureThreshold, periodSeconds, timeoutSeconds, initialDelaySeconds 의 default 값 — 본 task 페이지 인용 범위 밖 (별도 reference 페이지 필요)
    • startup probe 가 미설정 시의 동작 (= liveness/readiness 가 즉시 적용된다는 명시) — 별도 concept 페이지 인용 필요
    • readiness probe 가 startup probe 와 어떻게 상호작용하는지 (succession 순서) — 본 인용에선 "liveness takes over" 만 명시
  • 내 프로젝트 (ca-tmpl) 에 적용하려면 추가 확인이 필요한 것:
    • ca-tmpl 의 startup probe 30 × 5s = 150s 가 ca-tmpl 의 Spring Boot 콜드스타트 + JVM warmup 시간을 cover 하는지 (실측 필요)
    • ca-tmpl 의 startup probe endpoint 가 liveness 와 같은 endpoint 인지, 다른 endpoint 인지 (C4 권고와 정합 확인)

메모 / Notes

  • 본 capture 는 기존 runtime-health-k8s-probes-official.md 의 K8S-PROBE-C7 (needs-confirmation) 을 종결시키는 후속 fetch. 산식 단일 문장 verbatim (C2) + 추가 권고 (C4) 확보.
  • WebFetch 재시도 1회로 anchor #protect-slow-starting-containers-with-startup-probes 직접 fetch 성공 (1차 전체 페이지 fetch 는 truncate 됨).
  • 후속 추가 fetch 후보: