GCP Kubernetes健康检查异常求助：PHP脚本die()后检查正常

Hey there, let's break down why your health check is still showing green (healthy) even after adding a die() in your index.php, and walk through how GCP's Kubernetes health checks operate under the hood.

First: How GCP Kubernetes Health Checks Work #

When running on GKE (Google Kubernetes Engine), the "green status" you see for your Pods ties to two core Kubernetes probes, plus optional GCP Cloud Load Balancer (CLB) checks if you're using a LoadBalancer Service:

• Liveness Probe: Checks if the Pod is still "alive"—if it fails, kubelet will restart the Pod.
• Readiness Probe: Checks if the Pod is ready to receive traffic—if it fails, the Pod gets removed from your Service's endpoint list.
• GCP CLB Health Checks: If you're using a LoadBalancer Service, GCP automatically creates a separate health check for the NodePort your Service exposes. This is independent of Kubernetes' internal Pod probes.

Your issue mentions the Deployment's Pod health check showing green, so we'll focus on Kubernetes' internal probes first.

Why Your die() Isn't Triggering a Failure #

Here are the most likely culprits:

1. Your Probe Isn't Targeting the Right Path/Host #

Double-check your probe configuration—if it's hitting a different path or using a host that doesn't map to your modified index.php, it won't pick up the die():

• For example, if your probe is configured to hit /healthz instead of / (where your index.php lives), it's not accessing the modified code.
• If you set host: www.example.com in your probe, your Pod's web server needs to have a virtual host configured for that domain. If it doesn't, the request might fall back to a default page that doesn't have the die().

You can view your Deployment's probe config with this command:

kubectl get deployment <your-deployment-name> -o yaml

Look for the livenessProbe/readinessProbe sections and verify the httpGet.path, httpGet.port, and httpGet.host values.

2. Probe Thresholds Are Too Lenient #

Kubernetes probes use two key settings to determine failure:

• periodSeconds: How often the probe runs (you said 30 seconds)
• failureThreshold: Number of consecutive failures needed to mark the Pod unhealthy (default is 3)

That means it could take up to 90 seconds (3 failures × 30 seconds) before the Pod's status changes from green to unhealthy. If you checked right after adding die(), you might just need to wait a bit longer.

3. Your Web Server Is Caching or Routing Requests Away #

If your web server (like Nginx or Apache) is caching the index.php content, or routing requests to a different container/process, the probe might be getting a cached healthy response instead of your modified code.

Test this by exec-ing into the Pod and manually sending the same request the probe uses:

kubectl exec -it <your-pod-name> -- curl -H "Host: www.example.com" http://localhost:<your-port>/<probe-path> -v

Check the response status code and content—if it's still 200 without your die() output, your probe isn't hitting the modified code.

4. You're Looking at the Wrong Health Check Status #

If you're viewing the GCP Load Balancer's health status (not the Pod's status in GKE), keep in mind: CLB health checks target NodePorts, not individual Pods. Even if a Pod is unhealthy, the NodePort might still respond (if other healthy Pods are on the same node), keeping the CLB status green.

Step-by-Step Troubleshooting #

1. Verify Probe Configuration: Use the kubectl get deployment -o yaml command to confirm your probe is targeting the correct path, port, and host.
2. Test Inside the Pod: Run the curl command above to simulate the probe request and see what response it gets.
3. Check Pod Events: Use kubectl describe pod <your-pod-name> to look for probe failure messages in the Events section—this will tell you if kubelet is actually detecting failures.
4. Review Pod Logs: Run kubectl logs <your-pod-name> to see if the probe's request is being logged, and what response your application is sending.

Key Takeaways #

• Kubernetes probes run locally on the node (via kubelet) and are separate from GCP's Load Balancer checks.
• Always verify that your probe's request matches exactly what your application expects (path, host headers, etc.).
• Be patient with threshold settings—your Pod won't flip to unhealthy immediately after a single failure.

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