The Big Idea

Reliability in Kubernetes usually comes down to four questions:

• Is the container still alive?
• Is the container ready to receive traffic?
• Does the workload have enough CPU and memory?
• Can we update it without breaking availability?

Kubernetes gives you built-in tools for all four.

Probes: How Kubernetes Checks Application Health

A probe is a health check performed by Kubernetes on a running container.

Probes help Kubernetes decide whether to restart a container or whether to send traffic to it.

There are three probe types you must know:

• Liveness probe: asks, “Should this container be restarted?”
• Readiness probe: asks, “Is this container ready to receive traffic?”
• Startup probe: asks, “Has this slow-starting app finished starting yet?”

Liveness Probe: Is the App Still Healthy?

A liveness probe is for applications that can become stuck or unhealthy while still technically running.

If the liveness probe keeps failing, Kubernetes restarts the container.

This is useful when a process hangs, deadlocks, or stops responding correctly.

A liveness probe is not about traffic. It is about recovery.

Readiness Probe: Should This Pod Receive Traffic?

A readiness probe tells Kubernetes whether the application is ready to serve requests.

If readiness fails, the Pod is not killed. It is simply removed from Service traffic until it becomes ready again.

This is very important during startup, overload, dependency failures, and rolling updates.

A simple mental model helps:

Liveness is about restart. Readiness is about traffic.

Startup Probe: Protect Slow-Starting Applications

Some applications take a long time to start.

If you use only liveness and readiness probes, Kubernetes might think the app is broken before it finishes starting.

That is where a startup probe helps.

While the startup probe is failing, Kubernetes waits and does not run liveness or readiness checks yet.

This is a great fit for JVM apps, large frameworks, and applications with heavy initialization.

How Probes Can Be Implemented

Kubernetes supports several ways to run a probe:

• HTTP: call an HTTP endpoint such as /health
• TCP: check whether a port is accepting connections
• exec: run a command inside the container
• gRPC: use a gRPC health check when supported

For most web applications, HTTP probes are the easiest place to start.

A Simple Deployment Example with Probes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-api
  template:
    metadata:
      labels:
        app: demo-api
    spec:
      containers:
        - name: api
          image: nginx:stable
          ports:
            - containerPort: 80
          startupProbe:
            httpGet:
              path: /
              port: 80
            failureThreshold: 30
            periodSeconds: 2
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 10
            periodSeconds: 10

This example is intentionally simple.

The startup probe gives the app time to initialize. The readiness probe controls whether traffic should reach the Pod. The liveness probe restarts the container if it becomes unhealthy.

Resource Requests and Limits: CPU and Memory Basics

Reliability is not only about health checks. It is also about giving workloads the right amount of resources.

In Kubernetes, the two most common resources are CPU and memory.

You usually define two values:

• request: the minimum resource amount Kubernetes should plan for
• limit: the maximum amount the container is allowed to use

What Requests Actually Do

Resource requests help the scheduler decide where a Pod can run.

If a Pod requests more CPU or memory than a node can reasonably offer, that Pod will not be scheduled there.

A simple way to think about it is:

Request = what Kubernetes reserves room for

What Limits Actually Do

Resource limits control how much a running container is allowed to consume.

CPU limits cap CPU usage.

Memory limits are stricter: if a container keeps using too much memory, it can be terminated.

A simple rule:

Too little memory limit can crash a healthy app. Too little CPU can make it slow.

A Simple Resource Example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-api
  template:
    metadata:
      labels:
        app: demo-api
    spec:
      containers:
        - name: api
          image: nginx:stable
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

This means the scheduler should plan for at least 100 millicpu and 128 MiB of memory, while the container should not go above 500 millicpu and 256 MiB of memory.

Why Missing Resource Settings Cause Problems

When requests and limits are missing, workloads become harder to reason about.

One application may consume more than expected, scheduling becomes less predictable, and noisy-neighbor problems become more likely.

Good resource settings are not perfect guesses. They are informed starting points that you improve over time with metrics.

Restarts: When Kubernetes Tries Again

Kubernetes is designed to recover from failure, not to pretend failure never happens.

If a container exits unexpectedly or fails its liveness check, Kubernetes can restart it.

This is normal for long-running application Pods.

But repeated restarts are a symptom, not a success story. They usually mean the app is unhealthy, misconfigured, or starved of resources.

Rolling Updates: Safer Changes With Less Downtime

A Deployment updates Pods gradually instead of replacing everything at once.

This is called a rolling update.

The main goal is to keep the application available while a new version is being rolled out.

Readiness probes matter a lot here because Kubernetes should send traffic only to Pods that are actually ready.

Useful Commands

kubectl apply -f deployment.yaml
kubectl rollout status deployment/demo-api
kubectl rollout history deployment/demo-api
kubectl rollout undo deployment/demo-api

A Practical Reliability Starter Pattern

For many normal web applications, a good beginner pattern looks like this:

• use a Deployment with at least 2 replicas
• add a readiness probe
• add a liveness probe only if you understand what “unhealthy” means for the app
• use a startup probe for slow-starting apps
• set reasonable CPU and memory requests and limits
• watch rollout status during changes

That alone gets you much closer to production-safe behavior.

Common Beginner Mistakes

Using Only Liveness and No Readiness

That can cause traffic to hit a Pod before it is actually ready to serve requests.

Making the Liveness Probe Too Aggressive

If the probe fails too quickly, Kubernetes can keep restarting a slow but healthy application.

Skipping the Startup Probe for Slow Apps

Slow-starting applications often need extra time before normal health checks begin.

Setting No Resource Requests

That makes scheduling less predictable and capacity planning weaker.

Setting Unrealistic Limits

A memory limit that is too low can cause repeated crashes.

Updating Without Watching Readiness

A rollout is only safe if the new Pods become healthy and ready in time.

What a DevOps Engineer Must Remember

• Liveness probes are about restart.
• Readiness probes are about traffic.
• Startup probes protect slow-starting applications from premature failure checks.
• Resource requests help Kubernetes schedule Pods onto suitable nodes.
• Resource limits control how much CPU and memory a container can use.
• Rolling updates are safer when readiness checks are correct.
• Reliability starts with simple habits, not with complex tooling.

Final Thought

Kubernetes does not make applications reliable by magic.

It gives you the controls to describe what “healthy,” “ready,” and “safely resourced” should mean.

If you use probes and resource settings well, your workloads become much easier to operate and much safer to update.