Health checks in containers in Microservices - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the purpose of a health check in a containerized microservice?

A health check verifies if a containerized microservice is running correctly and ready to serve requests. It helps orchestrators decide if the container should keep running or be restarted.

beginner

Name the two common types of health checks used in containers.

Liveness check: Determines if the container is alive or stuck. Readiness check: Determines if the container is ready to accept traffic.

intermediate

Why should readiness checks be separate from liveness checks?

Readiness checks control traffic routing and prevent sending requests to containers not ready yet. Liveness checks detect if a container is broken and needs restart. Separating them avoids unnecessary restarts.

beginner

What happens if a liveness check fails in a container orchestrator like Kubernetes?

The orchestrator considers the container unhealthy and restarts it to recover from failure or stuck state.

beginner

Give an example of a simple readiness check for a web service container.

A readiness check can be an HTTP GET request to an endpoint like /health or /ready that returns status 200 if the service is ready to accept requests.

Which health check type ensures a container is ready to receive traffic?

A Readiness check

B Liveness check

C Startup check

D Performance check

Readiness checks confirm if the container is ready to accept requests, controlling traffic routing.

What action does Kubernetes take when a liveness check fails?

A Restarts the container

B Routes traffic away from the container

C Scales up the service

D Ignores the failure

Kubernetes restarts containers that fail liveness checks to recover from unhealthy states.

Why is it important to have separate readiness and liveness checks?

A To reduce network traffic

B To avoid restarting containers unnecessarily

C To improve logging

D To speed up container startup

Separating checks prevents restarting containers that are alive but not ready to serve traffic.

Which of these is a common method for implementing a readiness check?

A Checking CPU usage

B Monitoring memory leaks

C Sending an HTTP GET request to a health endpoint

D Verifying disk space

Readiness checks often use HTTP requests to specific endpoints that return status indicating readiness.

If a container is alive but not ready, what should happen?

A It should be deleted

B It should receive traffic normally

C It should be restarted immediately

D Traffic should be withheld until ready

Traffic should be withheld until the container signals readiness to avoid errors.

Explain the difference between liveness and readiness health checks in containers.

Think about when a container should be restarted versus when it should receive traffic.

Describe how health checks improve reliability in a microservices architecture using containers.

Consider what happens when a service fails or is not ready.

Practice

1. What is the main purpose of health checks in containers?

easy

A. To log all container network traffic

B. To increase the container's memory allocation

C. To update the container's software automatically

D. To verify if the container is running and responsive

Solution

1. Step 1: Understand container health checks

   Health checks are used to confirm if a container is alive and working properly.

2. Step 2: Identify the main goal

   The main goal is to detect if the container is responsive and healthy, so it can be restarted if needed.

3. Final Answer:

   To verify if the container is running and responsive -> Option D

4. Quick Check:

   Health checks = verify container health [OK]

Hint: Health checks confirm container responsiveness [OK]

Common Mistakes:

• Confusing health checks with resource allocation
• Thinking health checks update software
• Assuming health checks log network data

2. Which of the following is the correct syntax to define a simple HTTP health check in a Docker container?

easy

A. HEALTHCHECK EXECUTE curl -f http://localhost/

B. HEALTHCHECK RUN curl http://localhost/

C. HEALTHCHECK CMD curl -f http://localhost/ || exit 1

D. HEALTHCHECK CHECK curl http://localhost/

Solution

1. Step 1: Recall Docker health check syntax

   The correct Dockerfile syntax uses HEALTHCHECK CMD followed by a command that returns 0 on success.

2. Step 2: Identify the correct command

   HEALTHCHECK CMD curl -f http://localhost/ || exit 1 uses 'curl -f' which fails on HTTP errors and 'exit 1' on failure, matching best practice.

3. Final Answer:

   HEALTHCHECK CMD curl -f http://localhost/ || exit 1 -> Option C

4. Quick Check:

   Docker healthcheck syntax = HEALTHCHECK CMD [OK]

Hint: Docker healthchecks use 'HEALTHCHECK CMD' syntax [OK]

Common Mistakes:

• Using RUN instead of CMD in HEALTHCHECK
• Using EXECUTE or CHECK which are invalid keywords
• Not handling failure with exit codes

3. Consider this Kubernetes liveness probe configuration snippet:

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

What happens if the container's /health endpoint returns HTTP 500 continuously?

medium

A. Kubernetes restarts the container after failing the liveness probe

B. Kubernetes ignores the failure and keeps the container running

C. Kubernetes scales up the number of containers

D. Kubernetes shuts down the entire pod immediately

Solution

1. Step 1: Understand liveness probe behavior

   Liveness probes check if a container is alive; failure triggers a restart of that container.

2. Step 2: Analyze the HTTP 500 response effect

   HTTP 500 means the endpoint is unhealthy, so Kubernetes marks the probe as failed and restarts the container.

3. Final Answer:

   Kubernetes restarts the container after failing the liveness probe -> Option A

4. Quick Check:

   Liveness probe failure = container restart [OK]

Hint: Liveness failure triggers container restart [OK]

Common Mistakes:

• Thinking Kubernetes ignores liveness failures
• Confusing liveness probe with scaling behavior
• Assuming pod shutdown instead of container restart

4. You have this Dockerfile snippet:

HEALTHCHECK CMD curl -f http://localhost:5000/health || exit 1

But the container never restarts even when the service is down. What is the likely issue?

medium

A. The container restart policy is not set to restart on failure

B. The container does not expose port 5000

C. The health check command is missing the --interval option

D. The HEALTHCHECK CMD syntax is incorrect

Solution

1. Step 1: Check health check command correctness

   The command syntax is correct and uses curl -f with exit 1 on failure.

2. Step 2: Consider container restart policy

   If the container restart policy is not set to restart on failure, the container won't restart despite health check failures.

3. Final Answer:

   The container restart policy is not set to restart on failure -> Option A

4. Quick Check:

   Restart policy controls container restart on health failure [OK]

Hint: Check restart policy if container doesn't restart [OK]

Common Mistakes:

• Assuming health check command syntax is wrong
• Ignoring restart policy settings
• Thinking missing --interval causes no restart

5. You want to design a microservice container that uses both readiness and liveness probes. Which of the following best describes their combined use?

hard

A. Both probes only log health status without affecting container state

B. Liveness probe restarts unhealthy containers; readiness probe controls traffic routing to only ready containers

C. Both probes restart containers on failure

D. Readiness probe restarts containers; liveness probe controls traffic routing

Solution

1. Step 1: Understand liveness probe role

   Liveness probes detect if a container is alive; failure triggers container restart.

2. Step 2: Understand readiness probe role

   Readiness probes check if a container is ready to serve traffic; failure removes it from load balancer routing.

3. Step 3: Combine their functions

   Liveness restarts unhealthy containers; readiness controls traffic flow to only healthy containers.

4. Final Answer:

   Liveness probe restarts unhealthy containers; readiness probe controls traffic routing to only ready containers -> Option B

5. Quick Check:

   Liveness = restart, Readiness = traffic control [OK]

Hint: Liveness restarts; readiness controls traffic [OK]

Common Mistakes:

• Mixing up readiness and liveness roles
• Thinking readiness probe restarts containers
• Assuming probes only log status without action