8.7 KiB
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 |
|
|
|
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
- 원본 URL: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
- 직접 anchor: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#protect-slow-starting-containers-with-startup-probes
- 아카이브 URL: (미수집)
- 저자 / 조직: Kubernetes Project (CNCF)
- 발행일: rolling docs (1.32+ reference)
- 마지막 확인일: 2026-05-27
왜 저장했는지 / 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 후보:
- https://kubernetes.io/docs/concepts/workloads/pods/probes/ — default 값 reference (이미
k8s-pod-lifecycle-probes-concept.md로 별도 capture)
- https://kubernetes.io/docs/concepts/workloads/pods/probes/ — default 값 reference (이미
Related / 관련
- 같은 주제 다른 official-doc:
- raw/official-docs/runtime-health-k8s-probes-official — 기존 K8s probe capture (concept 페이지 중심); 본 문서가 K8S-PROBE-C7 의 verbatim gap 을 보완
- raw/official-docs/k8s-pod-lifecycle-probes-concept — Pod lifecycle 의 probe 정의 (sister capture)
- 인용하는 branch:
- 인용하는 project:
- 인용한 wiki 요약: (미작성)