donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
d1ae257efe615efdb17c0bcad76b441163ff5e9e
llm-wiki/raw/company-tech-blogs/runtime-health-datadog-engineering-graceful-shutdown.md
T

9.8 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
Datadog Engineering — Graceful Shutdown and Lifecycle in Kubernetes (요약, 검증 실패) company-tech-blog https://www.datadoghq.com/blog/ needs-confirmation low
ca-skeleton
runtime
health
lifecycle
datadog
kubernetes
graceful-shutdown
company-tech-blog
unsupported
ca-skeleton-operational-contract
feature-runtime-health-lifecycle-contract
feature-container-runtime-contract
2026-05-22 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

핵심 인용 / 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 / 관련

Reference in New Issue View Git Blame Copy Permalink