Kubernetes Health Checks Node.js FAQ & Answers

Kubernetes probe types: (1) Liveness probe - kubelet uses to know when to restart container. Checks if app is alive (responds to requests). Kubernetes kills pod if liveness fails. Use for detecting deadlocks, infinite loops, process hanging, (2) Readiness probe - determines if container ready to receive traffic. Kubernetes removes from Service load balancers if readiness fails (temporarily, not restarted). Use during startup or temporary unavailability (DB connection lost), (3) Startup probe - while startup probe running, liveness and readiness probes disabled. Once startup succeeds, other probes activate. Addresses long startup times without making liveness overly lenient.

Node.js health check implementation (Red Hat/IBM official guidance): Use HTTP probe type (httpGet), 'z pages' pattern (/livez, /readyz). Liveness: app.get('/livez', (req, res) => { res.status(200).send('OK'); }); (lightweight, always passes unless process hung, no dependency checks). Readiness: app.get('/readyz', async (req, res) => { try { await db.query('SELECT 1'); await redis.ping(); res.status(200).send('OK'); } catch (err) { res.status(503).send('Not ready'); } }); (checks dependencies, safe because failure only removes from load balancer, doesn't restart).

Kubernetes probe configuration: livenessProbe: { httpGet: { path: /livez, port: 3000 }, initialDelaySeconds: 30, periodSeconds: 10 }; readinessProbe: { httpGet: { path: /readyz, port: 3000 }, initialDelaySeconds: 5, periodSeconds: 5 }. Startup probe for slow-starting apps: startupProbe: { httpGet: { path: /readyz, port: 3000 }, initialDelaySeconds: 0, periodSeconds: 10, failureThreshold: 30 } gives 300s startup time (10s × 30 attempts) before liveness/readiness activate. Response must be status 200/OK (body content not required).

Best practices (2025): (1) Liveness simple and fast (<100ms), no dependency checks (avoid restart loops when DB temporarily unavailable), (2) Readiness checks all dependencies (DB, Redis, downstream APIs) - failure removes from traffic but preserves container for debugging, (3) Different paths for liveness/readiness (avoid cascading failures where DB issue causes liveness failures across cluster), (4) Include startup probe for slow-starting apps, (5) Timeout: keep probe timeout < periodSeconds (prevents overlapping probes). Libraries: lightship (official Node.js Reference Architecture recommendation), terminus (HTTP-specific automatic checks).

Common mistakes: (1) Checking dependencies in liveness (DB down → liveness fails → pod restarts → still DB down → infinite restart loop, wastes resources and prevents debugging), (2) Probes too aggressive (periodSeconds too short causes false positives under load, kills healthy containers). Warning: For liveness probes particularly, additional internal state checks often do more harm than good - end result is container restart which may not fix actual problem, creates restart loops. Integration with graceful shutdown: readiness probe should fail immediately when shutdown signal (SIGTERM) received, allowing terminationGracePeriodSeconds (default 30s) for in-flight requests to complete.