From d772a7dc2958af44886a287aa49fbe31bf40e7a3 Mon Sep 17 00:00:00 2001 From: Anurag Ojha Date: Thu, 3 Jul 2025 17:11:34 +0000 Subject: [PATCH] Fix: Correct sidecar container termination order in pod lifecycle doc --- .../en/docs/concepts/workloads/pods/sidecar-containers.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/workloads/pods/sidecar-containers.md b/content/en/docs/concepts/workloads/pods/sidecar-containers.md index 4424cca8ec6d7..1ebc09848b14f 100644 --- a/content/en/docs/concepts/workloads/pods/sidecar-containers.md +++ b/content/en/docs/concepts/workloads/pods/sidecar-containers.md @@ -69,10 +69,9 @@ That status either becomes true because there is a process running in the container and no startup probe defined, or as a result of its `startupProbe` succeeding. Upon Pod [termination](/docs/concepts/workloads/pods/pod-lifecycle/#termination-with-sidecars), -the kubelet postpones terminating sidecar containers until the main application container has fully stopped. -The sidecar containers are then shut down in the opposite order of their appearance in the Pod specification. -This approach ensures that the sidecars remain operational, supporting other containers within the Pod, -until their service is no longer required. +the sidecar containers are stopped first, before the main application container. +This ensures that the main application logic can complete without interference +after the sidecars providing auxiliary functionality have been shut down. ### Jobs with sidecar containers