1. Restart gate
livenessProbe checks if the container is alive; failing it makes the kubelet restart the container.
livenessProbe:
httpGet:
path: /healthz
port: 8080Typorithm · medium
Step 1 of 8 · intro card
Config & Scaling
livenessProbe restarts unhealthy containers and readinessProbe gates traffic; resources.requests drive scheduling while resources.limits cap usage.
Probes let Kubernetes act on container health: liveness restarts a hung container, readiness withholds traffic until the app is ready.
httpGet probes hit a path and port; initialDelaySeconds gives the app time to start before the first check.
requests reserve CPU/memory so the scheduler can place the pod, and limits cap usage to protect the node from noisy neighbors.
liveness restarts; readiness gates traffic.
initialDelaySeconds delays the first check.
requests schedule; limits cap usage.
containers:
- name: web
image: myweb:2.0
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
resources:
requests:
cpu: "250m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "256Mi"Connect each part of the code to the concept before you type.
livenessProbe checks if the container is alive; failing it makes the kubelet restart the container.
livenessProbe:
httpGet:
path: /healthz
port: 8080readinessProbe decides whether the pod receives traffic; failing it removes the pod from Service endpoints.
readinessProbe:
httpGet:
path: /ready
port: 8080requests are what the scheduler reserves on a node to place the pod.
requests:
cpu: "250m"
memory: "128Mi"limits cap usage; exceeding memory limits gets the container OOM-killed, CPU is throttled.
limits:
cpu: "500m"
memory: "256Mi"Read the concept map and follow the code breakdown.
Type the implementation, repair mistakes and work through every recall exercise.
Use the final check without hints; revisit weak concepts in short practice sessions.