如何配置Kubernetes在代码错误时触发Pod重启？

This is such a common pain point—basic health checks that only verify if a container is running or a port is open won’t catch cases where your app is technically "up" but serving broken content. Let’s walk through how to configure Kubernetes to detect these PHP errors and restart faulty pods automatically.

1. Why Your Current Checks Aren’t Working #

Your existing liveness probe is probably only checking surface-level health:

• Is the PHP-FPM/Nginx process still running?
• Is port 80/443 open?

Since the broken pod is still outputting error text (not crashing entirely), these checks pass. We need to make our checks validate the actual content being served instead of just the container’s state.

2. Use HTTP Readiness + Liveness Probes (Basic Case) #

If your healthy pages return a 200 OK status code, and the broken state triggers a 5xx or non-200 response, an HTTP probe will work perfectly. This cuts off traffic to unhealthy pods first (via readiness probe) then restarts them (via liveness probe):

apiVersion: v1
kind: Pod
metadata:
  name: php-app
spec:
  containers:
  - name: php-container
    image: your-php-image:latest
    ports:
    - containerPort: 80
    # Readiness probe: Removes pod from service endpoints if unhealthy
    readinessProbe:
      httpGet:
        path: / # Or a dedicated health endpoint like /healthz
        port: 80
      initialDelaySeconds: 10 # Wait for app to fully bootstrap
      periodSeconds: 5 # Check every 5 seconds
      failureThreshold: 2 # Mark unready after 2 failures
    # Liveness probe: Restarts pod if unhealthy
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 10
      failureThreshold: 3 # Restart after 3 failed checks

3. Use an Exec Probe for Content Validation (Advanced Case) #

If the broken pod still returns a 200 OK but outputs the "unexpected end of file" error in the response body, you’ll need to check the actual content. Use an exec probe to run a script that verifies the response doesn’t contain the error, or does include a healthy marker (like your site’s header text).

Example Exec Probe Configuration #

livenessProbe:
  exec:
    command:
      - /bin/sh
      - -c
      # Check that the response has no PHP error AND includes a healthy string
      - 'curl -s http://localhost/ | grep -v "unexpected end of file" | grep -q "Your Site Main Header"'
  initialDelaySeconds: 15
  periodSeconds: 10
  failureThreshold: 2

How This Works: #

• curl -s http://localhost/ fetches the page content silently
• grep -v "unexpected end of file" filters out responses with the error
• grep -q "Your Site Main Header" checks for a string that should exist in healthy pages
• If either check fails, the command exits with code 1, triggering the liveness probe to restart the pod

4. Add a Dedicated Health Check Endpoint (Best Practice) #

For more reliability, create a simple PHP health endpoint (e.g., /healthz.php) that runs internal checks (like file integrity, database connectivity) and returns clear status codes:

// healthz.php
<?php
// Check critical application files exist and are readable
$criticalFiles = ['/var/www/html/index.php', '/var/www/html/config.php'];
foreach ($criticalFiles as $file) {
    if (!file_exists($file) || !is_readable($file)) {
        http_response_code(500);
        echo "Critical file missing: $file";
        exit;
    }
}

// Add additional checks (database connection, cache health) here

http_response_code(200);
echo "OK";
?>

Then update your probe to use this endpoint:

livenessProbe:
  httpGet:
    path: /healthz.php
    port: 80
  initialDelaySeconds: 10
  periodSeconds: 5

5. Bonus: Log Monitoring for Early Detection #

Even with solid probes, adding log monitoring can help you catch issues before they affect users. Configure your cluster to watch for the "unexpected end of file" string in pod logs and trigger an alert (using tools like Promtail + Loki or Elasticsearch). This is especially useful for debugging why files are getting corrupted in the first place.

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