---
title: "Datadog Engineering — Graceful Shutdown and Lifecycle in Kubernetes (요약, 검증 실패)"
source_type: company-tech-blog
url: https://www.datadoghq.com/blog/
archive_url:
status: needs-confirmation
confidence: low
tags: [ca-skeleton, runtime, health, lifecycle, datadog, kubernetes, graceful-shutdown, company-tech-blog, unsupported]
related_projects: [ca-skeleton-operational-contract]
related_branches: [feature-runtime-health-lifecycle-contract, feature-container-runtime-contract]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# Datadog Engineering — Graceful Shutdown and Lifecycle in Kubernetes (요약, 검증 실패)

> Layer: `raw/company-tech-blogs/` — Datadog Engineering 블로그 추정 요약. **2026-05-27 재확인 결과 원본 URL(`/blog/kubernetes-pod-termination/`) 가 404 응답** + blog 인덱스에서 해당 주제 글을 찾지 못함. 따라서 본 문서의 **요약 1~4 는 verbatim 출처 미확보 (UNSUPPORTED)**.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-runtime-health-lifecycle-contract]] | graceful shutdown timeout 표 (`app shutdown 20s + preStop 5s + grace 35s + safety 10s`) 의 회사 관점 reference 후보 — **현재 verbatim 미확보** |
| [[raw/branch-notes/feature-container-runtime-contract]] | container runtime 의 SIGTERM/SIGKILL 처리 모델 baseline 후보 — **현재 verbatim 미확보** |
| [[raw/project-notes/ca-skeleton-operational-contract]] | Group G-D (Runtime health lifecycle) graceful shutdown 비율 baseline |

## 컨텍스트 / 왜 저장했는지

ca-tmpl `feature-runtime-health-lifecycle-contract` + `feature-container-runtime-contract`의 graceful shutdown 표(`app shutdown 20s + preStop 5s + grace 35s + safety 10s`) 결정의 baseline. Datadog Engineering이 같은 모델을 권장하는지, 다른 timeout 비율을 권장하는지 비교용. **단, 현재 출처 verbatim 미확보 상태.**

## 출처 / Source

- 원본 URL (재확인 시 404): https://www.datadoghq.com/blog/kubernetes-pod-termination/ — **2026-05-27 WebFetch 결과 404 Not Found**
- blog index: https://www.datadoghq.com/blog/ — 해당 주제 글 발견 안 됨 (2026-05-27 기준)
- Kubernetes topic page: https://www.datadoghq.com/blog/topic/kubernetes/ — 해당 주제 글 발견 안 됨
- 아카이브 URL: (미수집 — verbatim 원문 미확보로 archive 등록 불가)
- 저자 / 조직: Datadog Engineering (특정 글 비확정)
- 발행일: 2021–2024년 사이 추정 (원본 문서에 기록된 추정값)
- 마지막 확인일: 2026-05-27 (재확인 → URL 죽음)

## 핵심 인용 / Key quotes (verbatim — 미확보)

> **주의: 아래 4개 항목은 원본 글에서 직접 발췌한 verbatim quote 가 아니라 작성자의 paraphrase ("요약 1~4")** 이다. 2026-05-27 재확인 시 원본 URL 이 404 응답이어서 verbatim 검증 불가. Strength 는 `needs-confirmation` 으로 등급 하향.

> [요약 1, paraphrase — 출처 미확인] "K8s가 pod에 SIGTERM을 보낼 때 endpoint controller가 service에서 pod IP를 제거하는 작업과 race가 발생한다. 이 race window를 좁히려면 `preStop` hook에서 `sleep`을 두어 endpoint propagation을 기다리는 패턴이 필요하다."

> [요약 2, paraphrase — 출처 미확인] "일반적으로 `preStop sleep` 5-10s + application graceful drain 10-30s + `terminationGracePeriodSeconds` 30-60s 조합이 권장된다. application drain timeout이 `terminationGracePeriodSeconds`를 초과하면 SIGKILL로 inflight 요청이 손실된다."

> [요약 3, paraphrase — 출처 미확인] "readiness probe failure보다 endpoint propagation이 더 느리다 (보통 수 초). 이 때문에 readiness가 fail로 전환된 직후에도 신규 요청이 도착할 수 있어, application은 graceful shutdown 진입 후에도 잠깐 요청을 받아낼 수 있어야 한다."

> [요약 4, paraphrase — 출처 미확인] "SIGTERM 핸들링이 누락된 컨테이너는 `terminationGracePeriodSeconds` 종료 후 SIGKILL을 받는다. 결과적으로 inflight 요청 손실 + 부정확한 metric flush."

## Claims Extracted / 추출된 주장

> **중요**: 본 자료는 company-tech-blog 이면서 verbatim quote 미확보. 따라서 아래 claim 들은 모두 `needs-confirmation` 으로 표시. 공식 best practice 로 인용 금지 — 별도 `official-vendor-doc` / `official-standard` (Kubernetes 공식 문서 등) 의 corroboration 필요.

| Claim ID | Claim (이 자료가 직접 말한다고 추정되는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| RH-DD-C1 | (추정) K8s 에서 SIGTERM 발송 시점과 endpoint controller 의 pod IP 제거 사이에 race 가 존재하며 `preStop` sleep 으로 흡수 권장 | [요약 1 — paraphrase, 출처 미확인] — verbatim 미확보 | `needs-confirmation` | K8s pod termination 일반 | 모든 mesh / ingress 환경에서 동일 race window 가 발생한다는 뜻은 아님. **공식 best practice 아님** |
| RH-DD-C2 | (추정) preStop sleep 5–10s + drain 10–30s + terminationGracePeriodSeconds 30–60s 의 조합이 일반적 권장 | [요약 2 — paraphrase, 출처 미확인] — verbatim 미확보 | `needs-confirmation` | K8s deployment 의 graceful shutdown 설정 | 본 숫자가 Datadog 공식 권장값이라는 검증된 출처 없음. ca-tmpl 의 20/5/35/10 조합이 "Datadog 권장 범위 내" 라는 진술도 **검증 실패** |
| RH-DD-C3 | (추정) readiness probe failure 보다 endpoint propagation 이 더 느려, readiness fail 직후에도 신규 요청 수신 가능 | [요약 3 — paraphrase, 출처 미확인] — verbatim 미확보 | `needs-confirmation` | K8s service endpoint 모델 | propagation delay 의 정량값 ("보통 수 초") 의 출처 미확인. Kubernetes 공식 문서로 corroboration 필요 |
| RH-DD-C4 | (추정) SIGTERM handling 누락 컨테이너는 terminationGracePeriodSeconds 후 SIGKILL → inflight 요청 손실 + metric flush 손실 | [요약 4 — paraphrase, 출처 미확인] — verbatim 미확보 | `needs-confirmation` | K8s pod termination 일반 | Kubernetes 공식 문서 (`Termination of Pods`) 에서 SIGKILL fallback 은 공식 명시 — 별도 official-vendor-doc 으로 대체 권장 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - **없음.** verbatim 출처 미확보 상태로, 본 문서는 작성자의 paraphrase 만 보존하고 있음. company-tech-blog 가 "공식 best practice" 가 아니라는 §5 규약을 그대로 적용해도, **본 문서는 그 약한 기준조차 충족하지 못함**.
- **이 자료가 증명하지 않는 것**:
  - ca-tmpl 의 20/5/35/10 timeout 비율이 Datadog Engineering 권장 범위 내라는 점 — **UNSUPPORTED_DECISION**
  - preStop sleep 패턴이 Datadog 의 공식 권장이라는 점 — **UNSUPPORTED_DECISION**
  - readiness vs endpoint propagation 의 정량적 delay 차이 — **UNSUPPORTED**
  - K8s 공식 문서 (`Termination of Pods`) 의 어떤 부분과도 1:1 매핑되지 않음 (별도 공식 문서로 대체 권장)
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - Kubernetes 공식 문서 (`Pod Lifecycle`, `Termination of Pods`) 에서 동일 메커니즘 verbatim 확보 → **official-vendor-doc 으로 대체** 권장 (예: `raw/official-docs/k8s-pod-termination-lifecycle.md` 신규 작성)
  - Datadog 의 실제 글 URL 재탐색 (Wayback Machine, 다른 블로그 mirror, 공식 docs Knowledge Base)
  - 본 문서의 paraphrase 요약은 보존하되, 인용 시 반드시 "출처 미확인" 표기

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

- 본 자료는 회사 블로그 다수 글의 종합 요약 — 직접 인용 아님. **공식 best practice로 사용 금지**.
- ca-tmpl과의 일치점 (작성자 추론, 출처 미확인):
  - `preStop sleep 5s` — endpoint propagation race를 흡수하기 위한 표준 패턴.
  - `app shutdown 20s + preStop 5s + grace 35s + safety 10s` 비율 — Datadog 권장 범위(preStop 5-10s + drain 10-30s + grace 30-60s) 내. **→ verbatim 미확보로 이 일치 평가는 보류**.
  - readiness fail → endpoint propagation → drain → exit 순서.
- ca-tmpl 결정 강화 근거: ca-tmpl이 manifest sync 표를 한 곳에서 관리하라고 요구한 이유는 정확히 이 race condition을 visible하게 만들기 위함.
- 단점/주의:
  - Datadog 모델은 K8s 환경 가정. ECS/Nomad에서는 다른 hook semantics. ca-tmpl도 K8s 가정.
- **마이그레이션 권고**: 본 자료를 ca-tmpl branch-note 의 evidence 로 인용 중인 곳이 있다면, Kubernetes 공식 문서 (`https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination`) 의 verbatim quote 로 교체. company-tech-blog 인용을 유지하려면 verbatim quote 와 정확한 URL 을 재발견해야 함.

## Related / 관련

- 같은 주제 다른 official-doc (대체 evidence 우선 권장):
  - (신규 작성 후보) `raw/official-docs/k8s-pod-termination-lifecycle` — Kubernetes 공식 Pod Lifecycle 문서
- 같은 주제 다른 official-doc:
  - [[raw/official-docs/runtime-health-istio-mesh-health-check]] (다른 측면 — mesh 환경 probe)
- 적용 branch / contract:
  - [[raw/branch-notes/feature-runtime-health-lifecycle-contract]]
  - [[raw/branch-notes/feature-container-runtime-contract]]
  - canonical contract: [[raw/project-notes/ca-skeleton-operational-contract]] (runtime health lifecycle / container runtime canonical sections, 예정)
- 대안 그룹: **Group G-D — Runtime health lifecycle** + **Container runtime**
- 본 source 위치: graceful shutdown 표 비율(20s/5s/35s/10s) 결정의 회사 관점 reference (**현재 검증 실패 → 사용 시 UNSUPPORTED 표기 필수**)
- 인용하는 wiki: (미작성)