A health-clinic portal ENTRYPOINT uses a shell wrapper that never forwards SIGTERM, so Pods hang until they are force-killed. What image design fix helps Kubernetes stop the container cleanly?
Select an answer to reveal the explanation.
Short Explanation
If a shell sits in front of your app like a receptionist who pockets the mail, Kubernetes' polite "please shut down" (SIGTERM) never reaches the real process. Use exec-form ENTRYPOINT/CMD so the app is PID 1 and hears the signal.
Full Explanation
Health-clinic portal images that use a shell-form ENTRYPOINT wrapper often leave a shell as PID 1. Kubernetes sends SIGTERM to PID 1 during graceful termination; if the shell never forwards the signal, the app ignores shutdown until the grace period ends and the kubelet SIGKILLs the container—dropping in-flight clinic requests. Use exec-form ENTRYPOINT/CMD (JSON array syntax) so the application is PID 1 and receives SIGTERM directly, then handle shutdown cleanly inside the process.
Setting terminationGracePeriodSeconds to 0 does not fix signal routing; it only forces immediate kill and worsens user experience. Replacing SIGTERM handling with a liveness probe that kills every 30 seconds turns probes into chaos and is not graceful shutdown. Switching to a completed Job ignores the fact that long-running Deployments still need correct signal behavior for rolling updates.
Exam caveat: distinguish shell form vs exec form in Dockerfiles, and know that preStop hooks complement but do not replace correct PID 1 signal delivery. CKAD cares that application images cooperate with Pod termination.
Operational check: deploy with a longer grace period temporarily, kubectl delete pod and watch logs for orderly shutdown messages; confirm the process tree shows the app as PID 1 (kubectl exec with ephemeral debug if the image is distroless).