What happens if I skip the readiness probe?

Kubernetes assumes a Pod is ready as soon as its container starts, so it may send traffic to an app that is still starting, causing errors during deployments.

Why is my HPA showing unknown for CPU usage?

Usually the metrics server is missing or not ready, or the Pods have no CPU requests defined. Check both, and wait a minute for metrics to appear.

Kubernetes Health Probes, Resource Limits, and Autoscaling

Introduction

Running a container is not the same as running a healthy service. Kubernetes can check whether your app is alive and ready for traffic, reserve and cap the resources it uses, and add or remove Pods as load changes. These three features separate a toy deployment from one you can trust.

Prerequisites

Deployments and Services from the earlier lessons

Step-by-Step Guide

Step 1: Add readiness and liveness probes

A readiness probe decides whether a Pod should receive traffic, which is what makes rolling updates safe. A liveness probe decides whether the container is stuck and should be restarted. Point both at lightweight health endpoints in your app, and be careful not to make liveness checks depend on slow downstream services.

containers:
- name: app
  image: my-app:1.0
  readinessProbe:
    httpGet:
      path: /ready
      port: 8080
    initialDelaySeconds: 5
    periodSeconds: 5
  livenessProbe:
    httpGet:
      path: /healthz
      port: 8080
    initialDelaySeconds: 10
    periodSeconds: 10

Step 2: Protect slow starters with a startup probe

If your app takes a long time to start, a startup probe gives it a generous window before liveness checks begin, so it is not killed while still booting. This example allows up to 30 checks, 10 seconds apart, so 300 seconds.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Step 3: Set resource requests and limits

Requests are what the scheduler reserves for the container, and they determine where it can be placed. Limits are the maximum it may use: exceeding a CPU limit throttles the container, while exceeding a memory limit gets it killed. Watch the units: 250m is a quarter of a CPU core, and memory suffixes are case-sensitive, so use Mi, not m.

resources:
  requests:
    cpu: "250m"
    memory: "64Mi"
  limits:
    cpu: "500m"
    memory: "128Mi"

Step 4: Scale automatically with the HPA

The Horizontal Pod Autoscaler adds or removes Pods to keep a metric, such as average CPU utilization, near a target. It needs the metrics server running in the cluster, and it needs CPU requests set on your containers because utilization is measured against them. On minikube you can enable the metrics server as an addon; for other clusters follow the metrics server installation instructions.

kubectl autoscale deployment web --cpu=50% --min=1 --max=10
kubectl get hpa
kubectl get hpa web --watch

# minikube only:
# minikube addons enable metrics-server

Step 5: Define the HPA as YAML

In real projects, keep the autoscaler in a file under version control. The stable API version is autoscaling/v2.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

FAQs

What happens if I skip the readiness probe?: Kubernetes assumes a Pod is ready as soon as its container starts, so it may send traffic to an app that is still starting, causing errors during deployments.
Why is my HPA showing unknown for CPU usage?: Usually the metrics server is missing or not ready, or the Pods have no CPU requests defined. Check both, and wait a minute for metrics to appear.

Summary

Use readiness probes to gate traffic, liveness probes to restart stuck containers, and startup probes for slow starters. Set requests and limits, and let the HPA scale on metrics, provided the metrics server and CPU requests are in place.