Review container readiness probes

Description

A readiness probe checks whether a container can handle requests. Relying on a running state without an appropriate check can send service traffic to containers that are still initializing or temporarily unable to serve.

Readiness failure removes the pod from ready endpoints in normal Service routing; it does not restart the container. Liveness decides when a restart is needed, while startup probes protect initialization time. Choose these controls according to workload needs.

Potential impact

Requests can fail when sent to instances that are not ready.
An inaccurate check can exclude healthy instances or continue routing traffic to unhealthy ones.

Remediation

Configure a readiness_probe that checks actual serving ability through a supported HTTP, TCP or exec mechanism.
Tune delays, periods and thresholds for initialization and temporary failures, and test rolling updates and recovery. Decide separately whether liveness is needed.

Examples

These examples require separate nginx configuration that actually serves /nginx_status on port 80. Do not assume the default image provides that path. Use a maintained image for deployment.

Before

hcl

resource "kubernetes_pod" "pod" {
  metadata {
    name = "terraform-example"
  }

  spec {
    container {
      image = "nginx:1.7.9"
      name  = "example"

      liveness_probe {
        http_get {
          path = "/nginx_status"
          port = 80
        }
      }
    }
  }
}

After

hcl

resource "kubernetes_pod" "pod" {
  metadata {
    name = "terraform-example"
  }

  spec {
    container {
      image = "nginx:1.7.9"
      name  = "example"

      readiness_probe {
        http_get {
          path = "/nginx_status"
          port = 80
        }

        initial_delay_seconds = 10
      }

      liveness_probe {
        http_get {
          path = "/nginx_status"
          port = 80
        }
      }
    }
  }
}

Explanation:

Before: Only liveness is configured; application readiness is not checked separately.
After: An HTTP readiness check is added. A delay alone does not check readiness.