--- title: "Kubernetes — Configure Liveness, Readiness and Startup Probes (Task Page)" source_type: official-doc url: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ archive_url: status: raw confidence: high tags: [ca-skeleton, runtime, health, lifecycle, kubernetes, probe, startup-probe] related_projects: [ca-skeleton-operational-contract] related_branches: [feature-runtime-health-lifecycle-contract] created: 2026-05-27 last_reviewed: 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) > ```yaml > 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) ## 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: - [[raw/branch-notes/feature-runtime-health-lifecycle-contract]] - 인용하는 project: - [[raw/project-notes/ca-skeleton-operational-contract]] - 인용한 wiki 요약: (미작성)