Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Document graceful shutdown configuration for actor hosts on Kubernetes

Chiusa
  • Qualcosa non va?
#5,316 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #5317 di @shaul-apiiro — integrata

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
78/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
kubernetes
Ambito
documentation

Direzione di ricerca

Start with operations/hosting/kubernetes/kubernetes-production.md and add the requested “Graceful shutdown for actor hosts” production-guidelines section. Then add the short cross-linking note in developing-applications/building-blocks/actors/actors-runtime-config.md and the caveat in operations/resiliency/health-checks/sidecar-health.md. Done means the three pages explain the sidecar-outlives-app pattern, duration relationships, health-check warning, and native-sidecar exception.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

What content needs to be created or modified?

The docs describe dapr.io/block-shutdown-duration, dapr.io/graceful-shutdown-seconds, drainOngoingCallTimeout, and drainRebalancedActors individually, but nothing explains how they interact with Kubernetes pod termination for actor hosts.

Kubernetes sends SIGTERM to the application container and the daprd sidecar at the same time. An idle application typically exits in well under a second, while the sidecar is still in its shutdown sequence. The sidecar then fails every actor deactivation with connection refused (Failed to halt all actors...), OnDeactivateAsync never runs, and until the sidecar exits and placement is re-disseminated, other sidecars keep routing calls to actors placed on the dying pod — a multi-second window of failed actor invocations on every ordinary rolling restart. The drain settings are silently ineffective in this configuration because the application is already gone when draining happens.

We hit this in production and verified the behavior experimentally on dapr 1.18.4: with defaults, every rolling restart produces refused deactivations and a multi-second actor black-hole; with the sidecar-outlives-app configuration described below, deactivations complete against a live app and the failure window disappears.

Describe the solution you'd like

A production-guidelines section explaining the parallel-SIGTERM pitfall and the sidecar-outlives-app pattern: a preStop sleep on the application container, block-shutdown-duration, terminationGracePeriodSeconds, the drain settings, and the app health check (on an app-only endpoint) so the block ends early if the app genuinely dies — including how to size the durations relative to each other, a warning against probing the app through the sidecar (circular dependency), and a note that this guidance does not apply to native sidecars (where the app terminates first by design).

Where should the new material be placed?

  • operations/hosting/kubernetes/kubernetes-production.md — new section "Graceful shutdown for actor hosts" (main content)
  • developing-applications/building-blocks/actors/actors-runtime-config.md — short note that the drain settings require the app to outlive the sidecar's shutdown, linking to the new section
  • operations/resiliency/health-checks/sidecar-health.md — one-line caveat under "Delay graceful shutdown" (the flag list there is also duplicated and can be fixed in passing)

The associated pull request from dapr/dapr, dapr/components-contrib, or other Dapr code repos

None — documentation of existing runtime behavior.

Additional context

Happy to submit the PR; the content is written and follows the docs contribution guide.

Lingua principale
SCSS
Stelle
1k
Fork
808
Merge medio
2g 15h
PR unite (30g)
73

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dapr/docs

Tutte le issue di dapr/docs

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.