### What would you like to be added?

When a Kubernetes Pod has a container with a startup script as the entrypoint to do some initialization work before starting the actual main process, only the script host process gets the shutdown signal (`SIGTERM` on Linux; `CTRL_SHUTDOWN_EVENT` on Windows according to the [docs](https://kubernetes.io/docs/concepts/windows/intro/#compatibility-v1-pod)). This is consistent with the [documented behavior](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), so I guess it's on purpose.

I'd like to suggest adding a mode (flag in the container spec) to allow sending the shutdown signal to all processes inside the container, at least on Windows.

### Why is this needed?

Unfortunately, when used as a script host entrypoint, neitther `cmd.exe` nor PowerShell will propagate the shutdown signal to the main process by default. In PowerShell, it's probably possible to come up with some code to handle `CTRL_SHUTDOWN_EVENT` explicitly and then somehow send the signal to the main process, but AFAIK that requires some (relatively) complicated programming; and also, PowerShell entrypoint processes come at a rather high memory overhead. In `cmd.exe`, often preferred for efficiency, there doesn't seem to be any way to do that at all.

I've noticed that Docker does it differently: it will send its own shutdown signal to all processes, even ones unrelated to the entrypoint process. Kubernetes' [Windows compatibility documentation](https://kubernetes.io/docs/concepts/windows/intro/#compatibility-v1-pod) actually references the Docker implementation, with a link to this Github issue: https://github.com/moby/moby/issues/25982. An [answer to that issue](https://github.com/moby/moby/issues/25982#issuecomment-375105522) mentions the behavior I observed with Docker (emphasis mine):

> The second fix for this was in Windows 10 Build 17074, which changes two things. First, the notification to is changed to CTRL_SHUTDOWN_EVENT for both windowsservercore and nanoserver based images. **Second, it extends the notification in windowsservercore based images to affect all process running in the container**, including sending service shutdown notifications to services running in the container. This is currently available in insider builds, and will be available in Windows Version 1803, in the 1803 based container images.

I guess, it's not possible to change the default behavior of Kubernetes on Windows to align with that of Docker, as it should remain consistent with Linux and would be a breaking change. But maybe a corresponding mode could be introduced to allow easy graceful shutdown when using entrypoint scripts?
Provide an easy way to send graceful shutdown signal to all processes in a Windows container
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : Provide an easy way to send graceful shutdown signal to all processes in a Windows container
Issue date:

--- start body ---
### What would you like to be added?

When a Kubernetes Pod has a container with a startup script as the entrypoint to do some initialization work before starting the actual main process, only the script host process gets the shutdown signal (`SIGTERM` on Linux; `CTRL_SHUTDOWN_EVENT` on Windows according to the [docs](https://kubernetes.io/docs/concepts/windows/intro/#compatibility-v1-pod)). This is consistent with the [documented behavior](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), so I guess it's on purpose.

I'd like to suggest adding a mode (flag in the container spec) to allow sending the shutdown signal to all processes inside the container, at least on Windows.

### Why is this needed?

Unfortunately, when used as a script host entrypoint, neitther `cmd.exe` nor PowerShell will propagate the shutdown signal to the main process by default. In PowerShell, it's probably possible to come up with some code to handle `CTRL_SHUTDOWN_EVENT` explicitly and then somehow send the signal to the main process, but AFAIK that requires some (relatively) complicated programming; and also, PowerShell entrypoint processes come at a rather high memory overhead. In `cmd.exe`, often preferred for efficiency, there doesn't seem to be any way to do that at all.

I've noticed that Docker does it differently: it will send its own shutdown signal to all processes, even ones unrelated to the entrypoint process. Kubernetes' [Windows compatibility documentation](https://kubernetes.io/docs/concepts/windows/intro/#compatibility-v1-pod) actually references the Docker implementation, with a link to this Github issue: https://github.com/moby/moby/issues/25982. An [answer to that issue](https://github.com/moby/moby/issues/25982#issuecomment-375105522) mentions the behavior I observed with Docker (emphasis mine):

> The second fix for this was in Windows 10 Build 17074, which changes two things. First, the notification to is changed to CTRL_SHUTDOWN_EVENT for both windowsservercore and nanoserver based images. **Second, it extends the notification in windowsservercore based images to affect all process running in the container**, including sending service shutdown notifications to services running in the container. This is currently available in insider builds, and will be available in Windows Version 1803, in the 1803 based container images.

I guess, it's not possible to change the default behavior of Kubernetes on Windows to align with that of Docker, as it should remain consistent with Linux and would be a breaking change. But maybe a corresponding mode could be introduced to allow easy graceful shutdown when using entrypoint scripts?
--- end body ---
