Around Go: Kubernetes · 3 MIN READ

Readiness, liveness and graceful shutdown

Give each health signal one purpose and arrange a bounded stop that drains owned work.

A process being alive does not mean it can accept useful work. Readiness controls whether a Pod receives normal Service traffic. Liveness can trigger a restart. A startup probe can allow initialization before the other probes take effect. Choose each signal according to the failure it should detect.

Give each probe one action

Merge this fragment into the api container only if the Go server implements these endpoints. Readiness gates normal Service traffic; liveness should detect a condition a restart can repair. A startup probe delays the other probes until startup succeeds.

yaml

startupProbe:
  httpGet: {path: /healthz, port: 8080}
  periodSeconds: 2
  failureThreshold: 30
readinessProbe:
  httpGet: {path: /readyz, port: 8080}
  periodSeconds: 5
livenessProbe:
  httpGet: {path: /healthz, port: 8080}
  periodSeconds: 10

Read the code

The intervals are examples, not universal budgets. A shared Redis outage should not make every liveness endpoint fail and restart all replicas. Readiness should reflect the service degraded-mode contract; test the actual handler behavior.

Drain requests within a finite deadline

This native Go fragment assumes srv is already serving in another goroutine. The signal context requests shutdown; a separate context bounds draining so an already-canceled signal context does not abort it immediately.

stopCtx, stop := signal.NotifyContext(context.Background(),
    os.Interrupt, syscall.SIGTERM)
defer stop()
<-stopCtx.Done()

drainCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
if err := srv.Shutdown(drainCtx); err != nil {
    return fmt.Errorf("drain HTTP: %w", err)
}

Read the code

Ten seconds is illustrative and must fit the platform termination grace period. Shutdown does not automatically wait for every background worker or hijacked connection. Stop accepting work, signal owned workers, join them, and close shared clients in a deliberate order.

Test the termination path under traffic

Readiness changes and endpoint propagation take time; applications can still see late requests. Make handlers safe during draining, choose how to reject new work, and verify existing requests finish or fail predictably. Persist required background work before exit. Probe intervals and thresholds should fit startup and recovery behavior instead of creating a rapid restart loop.

TAKE THIS WITH YOU

A health check needs an action model: route traffic, wait for startup, or restart. Graceful shutdown requires explicit ownership, deadlines and a tested drain path.

Check your understanding

Which statement is correct about readiness and liveness?

Go to the source

Progress stays in this browser. No account needed.