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

---
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 요약: (미작성)