Node.js Application Deployment

Node.js on Kubernetes

Deploying a Node.js application on Kubernetes requires careful attention to health check endpoints, environment variable management, and resource sizing. Node.js is single-threaded, so CPU limits have different implications compared to multi-threaded runtimes.

Key Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-app
  labels:
    app: "node-app"
    version: "v1"
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: node
          image: node:20-alpine
          ports:
            - name: http
              containerPort: 3000
          env:
            - name: NODE_ENV
              value: "production"
            - name: PORT
              value: "3000"
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 20
          readinessProbe:
            httpGet:
              path: /ready
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10

Health Endpoints

Your Node.js application should expose two distinct endpoints:

• /health (liveness): Returns 200 if the process is alive and not deadlocked. Keep this lightweight — no database checks.
• /ready (readiness): Returns 200 when the app is ready to handle traffic. This can include database connection checks, cache warmup, etc.

Memory Considerations

Node.js uses a garbage-collected heap. The default heap limit is ~1.5GB for 64-bit systems. Set the --max-old-space-size flag if your memory limit is lower. A container with a 512Mi memory limit should set --max-old-space-size=384 to leave room for non-heap memory.

Scaling

With replicas: 3, Kubernetes distributes traffic across three pods. Since Node.js is single-threaded, scaling horizontally (more pods) is more effective than vertical scaling (more CPU per pod). Consider adding a Horizontal Pod Autoscaler for dynamic scaling.