A long-running service can be deployed without being ready to serve requests. A health check endpoint gives the running platform a way to ask whether the service is working. The platform can use a failed check to restart the application or mark a deployment as failed. This is more useful for a long-running service than for a function that is invoked and then shuts down. section 4.6
For a Go service with no external dependencies, a small HTTP handler is enough to start: register /health and return JSON containing {"status":"up"}. That response shows the server can answer the request; it does not test a database or another dependency. Add such checks when those dependencies matter to service health. section 4.6
Listing 4.6 health.go
package handlers
import (
"encoding/json"
"net/http"
)
func HealthCheck(w http.ResponseWriter, r *http.Request) {
enc := json.NewEncoder(w)
w.Header().Set("Content-Type", "application/json; charset=utf-8")
resp := map[string]string{"status": "up"} #1
if err := enc.Encode(resp); err != nil {
panic("unable to encode response")
}
}
The handler sets a JSON content type and encodes the status response. It is deliberately simple because this service has no external dependencies. section 4.6
Point the deployment platform at the endpoint, then decide what each check means:
- A liveness check asks whether the service is running; a failed check can lead the platform to replace it. section 4.6 section 10.4
- A readiness check asks whether the service can receive requests. Kubernetes uses it when directing traffic to a pod during a rolling deployment. section 10.4
- The same /health route can serve both checks when an HTTP response is enough to establish readiness. They may need different signals if, for example, an API starts before its cache is warmed. section 10.4
Listing 10.4 deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-api
spec:
replicas: 1
selector:
matchLabels:
app: hello-api
template:
metadata:
labels:
app: hello-api
spec:
containers:
- name: hello-api
imagePullPolicy: Always
image: gcr.io/PROJECT_NAME/hello-api:latest
ports:
- containerPort: 8080
name: hello-api-svc
livenessProbe:
httpGet:
path: /health #1
port: 8080
initialDelaySeconds: 3
periodSeconds: 3
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 3
periodSeconds: 3
The Kubernetes deployment sends both HTTP probes to /health on port 8080, with initial delays and repeat intervals configured for each. section 10.4
Keep the signal as specific as the service needs. A reachable HTTP server is a useful first check; a service that depends on other components may need its health response to reflect whether it can actually do its job. section 4.6 section 10.4
