Kubernetes多容器Pod优雅终止：依赖容器终止致请求失败的解决方案咨询

Great question—this is a super common pain point when dealing with dependent containers in Kubernetes, especially with sidecar setups where one container relies on another to handle requests. Let’s walk through the most practical, battle-tested solutions to fix this:

Kubernetes sends SIGTERM to all containers in a Pod at the same time by default, which is exactly what’s causing your issue. To fix this, we need to make sure:

• Container 1 stops accepting new requests and finishes processing all in-flight requests first
• Container 2 only shuts down after Container 1 has fully exited or completed its work

Here’s how to implement this with lifecycle hooks:

apiVersion: v1
kind: Pod
metadata:
  name: dependent-container-pod
spec:
  # Set a grace period long enough to cover both containers' shutdown processes
  terminationGracePeriodSeconds: 60
  containers:
  - name: container1
    image: your-container1-image:latest
    lifecycle:
      preStop:
        exec:
          # Example for an Nginx container: stop accepting new requests, wait for existing ones to finish
          command: ["sh", "-c", "nginx -s quit; sleep 30"]
          # For other apps: replace with your app's graceful shutdown command + a buffer wait
  - name: container2
    image: your-container2-image:latest
    lifecycle:
      preStop:
        exec:
          # Wait until Container 1's main process is gone before shutting down
          command: ["sh", "-c", "while pgrep -x nginx > /dev/null; do sleep 1; done"]
          # Replace "nginx" with the name of Container 1's main process

Key notes here:

• terminationGracePeriodSeconds ensures Kubernetes doesn’t force-kill your containers before they finish shutting down
• Container 1’s PreStop hook triggers first, telling it to stop new traffic and wrap up ongoing work
• Container 2’s PreStop hook actively waits for Container 1’s process to exit, so it won’t shut down prematurely

If you trust the containers in your Pod (since sharing PID namespaces lets containers see each other’s processes), this method is more reliable than pgrep (which can fail if process names are duplicated).

Enable shared PID namespace in your Pod, then modify Container 2’s PreStop hook to monitor Container 1’s process directly:

apiVersion: v1
kind: Pod
metadata:
  name: dependent-container-pod-shared-pid
spec:
  # Turn on shared process namespace
  shareProcessNamespace: true
  terminationGracePeriodSeconds: 60
  containers:
  - name: container1
    image: your-container1-image:latest
    lifecycle:
      preStop:
        exec:
          command: ["sh", "-c", "nginx -s quit; sleep 30"]
  - name: container2
    image: your-container2-image:latest
    lifecycle:
      preStop:
        exec:
          # Use kill -0 to check if Container 1's process is still running (no signal sent)
          command: ["sh", "-c", "while kill -0 $(pidof nginx) 2>/dev/null; do sleep 1; done"]

The kill -0 command doesn’t terminate the process—it just verifies if it exists, making this a more robust way to monitor Container 1’s status.

Even with Kubernetes hooks, your app needs to handle SIGTERM properly to avoid dropping requests. Make sure Container 1’s application:

• Listens for the SIGTERM signal
• Immediately stops accepting new connections/requests
• Waits for all in-flight requests to complete (with a reasonable timeout) before exiting
• Closes any open connections to Container 2 cleanly

If your app doesn’t support this natively, you can wrap it in a startup script that handles the signal for you. For example, a Python app might use a signal handler to trigger a graceful shutdown sequence.

If you don’t want to use PreStop hooks, you can set different termination grace periods for each container. Container 1 gets a shorter grace period to finish its work, and Container 2 gets a longer one to wait:

containers:
- name: container1
  image: your-container1-image:latest
  terminationGracePeriodSeconds: 30
- name: container2
  image: your-container2-image:latest
  terminationGracePeriodSeconds: 60

This is simpler but less reliable—Kubernetes still sends SIGTERM to both at the same time, so Container 2 might shut down before Container 1 finishes if Container 1 takes longer than expected. PreStop hooks are always preferred for dependent setups.

内容的提问来源于stack exchange，提问作者Ravi Chauhan