Storage, probes, and resource requests

Three different operating questions

Storage: if a database Pod is recreated, where do its files come from? A PVC requests storage from a configured provisioner. Bound means a volume was assigned, not that its contents are backed up. kind's node-local storage remains tied to that local cluster. Deleting the cluster can erase it.

Health: a startup probe gives a slow-starting process time to initialize. Readiness controls whether a Pod is a ready Service endpoint. Repeated liveness failures can restart a container. Do not make liveness depend on every downstream service: a database outage could otherwise trigger unnecessary API restarts.

Resources: requests influence scheduling; limits constrain consumption. CPU limiting can throttle. Memory pressure can kill processes or evict Pods. A request is not a measured capacity guarantee.

Work through a replacement and a readiness failure

Storage lifetime follows the storage mechanism. A container's writable layer is not a database backup. An emptyDir volume survives a container restart within its Pod but is lost with that Pod. A PersistentVolume (PV) represents supplied storage; a PersistentVolumeClaim (PVC) requests it. A StorageClass describes provisioning behavior. A StatefulSet can provide stable Pod identities and per-Pod claims, but it does not implement PostgreSQL replication or elect a database primary for you.

Return to the classroom Deployment from the previous bite. Its page is a ConfigMap mount, so replacement Pods receive the declared page again. Nothing wrote persistent business data. In .local/classroom.yaml, add this field to the web container beside resources, then apply the file and wait for the rollout:

readinessProbe:
  httpGet:
    path: /index.html
    port: 8080
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 2

Use the preceding bite's get pods, EndpointSlice, and in-cluster request commands. The expected healthy state is one Ready Pod and the same HTML. Next change only the readiness path to /not-present, apply, and inspect the new Pod with describe. The HTTP server should return 404 for that probe. The new Pod can be Running but not Ready, so its address is not a ready Service backend. An old ready Pod may remain during the rolling update; that is why you must inspect each revision rather than assume every request now fails. Restore /index.html in the file, apply, and wait for completion.

This failure should not restart the new container: readiness removes it from ready traffic, while liveness failures can cause restarts. A startup probe postpones readiness and liveness probing until startup succeeds. Use it for a measured initialization period, not to conceal an application that never becomes healthy.

Do the resource arithmetic

50m CPU means 0.05 of a CPU; 128Mi is 128 mebibytes. Requests describe the allocation Kubernetes uses when deciding whether Pods fit. For an illustrative node with 1,000m allocatable CPU and 700m already requested, another Pod requesting 400m cannot fit even if current CPU activity looks low. Limits have a different role: a CPU limit can throttle, and a memory limit can lead to an OOM kill. Raising a request does not repair a leak, and raising replicas adds more requests and potential database connections.

Small check: two Pods requesting 250m CPU and 128Mi memory each request 500m and 256Mi together. If each has a 512Mi memory limit, their combined limits are 1Gi; the request total is not their maximum possible usage. Keep both quantities in mind on a 16 GB host.

Apply this to MicroBank

Accounts /health currently returns a fixed healthy response. Ledger /v1/health is also a process check. Neither proves a completed transaction. Use these process checks for startup and readiness, and keep the transaction probe to verify the user journey. Adding a database-aware readiness endpoint is an application change requiring tests, not a manifest-only feature.

These commands inspect MicroBank after its module lab is running; the classroom fixture has no PVC.

kubectl --context kind-microbank-advanced -n microbank get pvc
kubectl --context kind-microbank-advanced -n microbank describe pod -l app=ledger
kubectl --context kind-microbank-advanced -n microbank get pods \
  -o custom-columns=NAME:.metadata.name,RESTARTS:.status.containerStatuses[*].restartCount

kubectl top needs Metrics Server; it is not guaranteed in a new kind cluster. Container-engine statistics and host memory pressure are useful initial observations.

Carry forward the database recovery plan and MicroBank schema inspection. A new database Pod must not accidentally invoke destructive schema initialization, and application surge replicas must fit the connection budget.

Checkpoint

Record startup duration before choosing probe windows. Measure memory use both at idle and during a transaction run before tuning the lab’s initial limits. Explain why increasing replicas does not replicate PostgreSQL safely, and why a retained PVC does not establish a tested recovery time.

Checkpoint reasoning: a PostgreSQL replica count is only a process count unless the database replication protocol and storage design are configured. A PVC's existence says nothing about whether a dump restores or how long recovery takes. Bring your measured probe behavior and PostgreSQL restore distinction into the node-administration bite. Keep the classroom file so you can return to kind after that separate VM exercise.

Sources

Probe behavior↗, resource management↗, and persistent volumes↗.