Liveness and readiness probes in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Difference between liveness and readiness probes

Which statement correctly describes the difference between liveness and readiness probes in microservices?

A Liveness probes are used only during deployment; readiness probes are used only during runtime.

B Liveness probes check if the service is ready to accept traffic; readiness probes check if the service is alive and should be restarted if failed.

C Both probes check if the service is alive but readiness probes run more frequently.

D Liveness probes check if the service is alive and should be restarted if failed; readiness probes check if the service is ready to accept traffic.

💡 Hint

Think about what happens when a service is unhealthy versus when it is not ready to serve requests.

Liveness probes detect if a service is alive and restart it if it is not. Readiness probes check if the service is ready to receive traffic without restarting it.

❓ Architecture

intermediate

Choosing probe types for a microservice

You have a microservice that loads a large configuration file on startup and then serves requests. Which probe setup is best to ensure smooth traffic routing and automatic recovery?

A Use a readiness probe that checks if the configuration is loaded, and a liveness probe that checks if the service process is running.

B Use only a liveness probe that checks if the configuration is loaded.

C Use only a readiness probe that checks if the service process is running.

D Use a liveness probe that checks if the service is ready to accept traffic, and no readiness probe.

💡 Hint

Consider what happens if the service is running but not ready to serve requests.

The readiness probe ensures traffic is sent only after configuration is loaded. The liveness probe ensures the service is restarted if it crashes.

❓ scaling

advanced

Impact of probe misconfiguration on scaling

What is the likely impact if a readiness probe is misconfigured to always fail in a Kubernetes deployment with autoscaling?

A Pods will be restarted repeatedly, causing instability in the cluster.

B Pods will never receive traffic, causing autoscaler to create more pods unnecessarily.

C Pods will receive traffic even if unhealthy, causing errors for users.

D Autoscaler will scale down pods aggressively, reducing availability.

💡 Hint

Think about how readiness affects traffic routing and autoscaling decisions.

If readiness probe always fails, pods are marked not ready and do not receive traffic. Autoscaler may add more pods to handle traffic, causing resource waste.

❓ tradeoff

advanced

Tradeoffs in probe frequency settings

What is a tradeoff when setting very frequent liveness and readiness probe intervals in a microservice?

A Higher probe frequency improves failure detection speed but increases CPU and network overhead.

B Higher probe frequency reduces CPU usage but delays failure detection.

C Lower probe frequency causes more false positives but reduces network traffic.

D Lower probe frequency improves failure detection speed but increases memory usage.

💡 Hint

Consider what happens when probes run too often versus too rarely.

Frequent probes detect failures faster but consume more resources. Less frequent probes save resources but delay detection.

❓ estimation

expert

Estimating probe impact on cluster resource usage

A Kubernetes cluster runs 100 microservice pods. Each liveness probe sends a 1KB HTTP request every 10 seconds, and each readiness probe sends a 1KB HTTP request every 5 seconds. Estimate the total network bandwidth used by probes per minute.

A 3600 KB per minute

B 2400 KB per minute

C 1800 KB per minute

D 3000 KB per minute

💡 Hint

Calculate requests per pod per minute, multiply by request size and number of pods.

Each pod sends 6 liveness probes (60/10) and 12 readiness probes (60/5) per minute. Total requests per pod = 18. Total KB per pod = 18 KB. For 100 pods = 1800 KB per minute.