CFG-07 · Containers

Kubernetes manifest generator

A Deployment, a matching Service, and an optional Ingress — one form, one YAML file with all three documents.

Deployment

Service

Ingress

manifest.yaml


  

Validate locally with kubectl apply --dry-run=client -f manifest.yaml before applying to a real cluster.

Why requests and limits are two different numbers

The request is what the scheduler reserves for your pod when deciding which node to place it on — set it too high and pods sit unschedulable on a full cluster; too low and the scheduler over-packs nodes. The limit is the hard ceiling the container is killed or throttled at. A pod with no limit at all can starve its neighbours on the same node during a spike, which is why both matter even for small deployments.

Liveness vs. readiness: two probes doing different jobs

A failing liveness probe gets the container restarted — use it for "this process is stuck and needs a fresh start." A failing readiness probe just pulls the pod out of Service load-balancing without restarting anything — use it for "still starting up" or "temporarily overloaded." Wiring both to the same endpoint is fine for a simple app, but a slow-starting one usually needs them to diverge.

What's the difference between ClusterIP, NodePort, and LoadBalancer?

ClusterIP (default) is only reachable from inside the cluster — the normal choice when an Ingress or another in-cluster service is the only thing that needs to reach it. NodePort opens a port on every node directly. LoadBalancer asks the cloud provider to provision an external load balancer — it does nothing on a bare-metal or local cluster without a load-balancer controller installed.

Do I need cert-manager for the TLS block to work?

Not strictly — TLS in an Ingress just references a Secret containing a certificate and key. cert-manager is the common way to have that Secret created and renewed automatically; without it, you'd need to create the TLS Secret yourself ahead of time.

Why did my pod get OOMKilled even though it fit the memory request?

The request only affects scheduling — the container is killed the moment it exceeds its memory limit, regardless of the request. If a pod is repeatedly OOMKilled, the limit is too low for what the app actually needs, not the request.