Kubernetes — pods, deployments, services, ingress (concepts): Question bank

True or false — justify

A Pod is the same thing as a container.

False. A Pod is a wrapper holding one or more containers that share one IP and localhost; a single-container Pod is common but the Pod is still the scheduling atom, not the container.

Two containers in the same Pod can reach each other on localhost.

True. Containers in one Pod share the same network namespace, so they see each other on localhost and different ports — that is the whole point of co-locating them.

Two containers in different Pods can reach each other on localhost.

False. Each Pod has its own network namespace and IP; different Pods are separate hosts to each other and must talk via Pod IP or (properly) a Service.

If a Pod dies and restarts, it keeps its old IP.

False. A dead Pod is replaced by a new Pod with a new IP and identity — Pods are ephemeral. This is why you front them with a Service.

A Deployment guarantees a fixed set of Pod IPs.

False. It guarantees a fixed count of healthy Pods (replicas: N); the actual IPs churn as Pods are recreated. Count is stable, identity is not.

Deleting a Pod managed by a Deployment destroys it permanently.

False. The Deployment's reconciliation loop sees the count drop below desired and creates a replacement. Only a bare Pod (no manager) is gone forever.

A Service picks its backend Pods by their names or IPs listed in its config.

False. A Service selects by label selector (e.g. app=cart); any Pod that carries the matching label joins automatically. No IP is ever listed by hand.

A ClusterIP Service is reachable from the public internet.

False. ClusterIP is reachable only inside the cluster; external users need NodePort, LoadBalancer, or (best) an Ingress in front.

An Ingress can route traffic without an Ingress Controller running.

False. Ingress is only a rule-set; an Ingress Controller (nginx, Traefik, ...) must actually run to read and enforce those rules, or nothing happens.

Kubernetes is imperative — you tell it each step to run.

False. It is declarative: you state desired state, and controllers close the gap

act = f (desired - observed)

. You describe what, not how.

A Service performs Layer-7 (HTTP path) routing.

False. A standard Service is L4 (IP/port) — it cannot see URLs. Path/host routing is L7 and is the Ingress's job.

Scaling a Deployment from 3 to 8 replicas requires clients to be reconfigured.

False. New Pods inherit the label, so the Service's Endpoints list grows automatically and the same Service IP now spreads traffic over 8 Pods. That is the payoff of indirection.

Spot the error

"For reliability I hardcoded my client to connect to the Pod IP 10.1.2.7."

The Pod IP is temporary; on restart/reschedule/scale it changes and the client breaks. Point the client at a stable Service DNS name instead.

"Every microservice gets its own LoadBalancer Service so users can reach it."

One cloud LB (and public IP) per Service is expensive and crude. Keep internal services as ClusterIP and expose many of them through one Ingress backed by a single LB.

"My Service has selector app=web but sends no traffic — I'll restart the Service."

Restarting won't help; the likely cause is a label mismatch — the Pods are probably labelled app=webapp or similar, so the selector matches nothing. Fix the selector↔label pairing.

"I set maxUnavailable: 100% for a zero-downtime rolling update."

maxUnavailable is how many Pods may be down at once; 100% permits all Pods down simultaneously — the opposite of zero downtime. Keep it low (or 0) and rely on maxSurge.

"The Deployment and its Pod are one object, so deleting the Pod deletes the Deployment."

They are separate: the Deployment is the manager, the Pod the worker. Deleting the Pod just triggers a replacement; the Deployment survives and re-reconciles.

"I put my app container and its database in the same Pod so they scale together."

Co-locating stateful DB and stateless app in one Pod means they can't scale independently and the DB is recreated on any Pod restart. Databases belong in their own managed workload; only tightly-coupled sidecars (log-shipper, proxy) share a Pod.

"NodePort is fine for production public traffic — it opens a port on every node."

NodePort exposes a raw high port on every node IP with no HTTP awareness, TLS, or clean DNS; it's crude. Production external HTTP should go through an Ingress (or a LoadBalancer feeding one).

Why questions

Why is there a layer (Deployment) above the Pod at all?

A bare Pod has no self-healing of count — if a node dies its Pods vanish. The Deployment holds the policy "keep N healthy and roll updates safely," so the count and upgrade behaviour survive failures.

Why does a Service select by labels rather than a fixed list of Pods?

Because Pods are ephemeral and their count changes with scaling/healing. Label selection makes membership automatic: any Pod that gains the label joins, any that dies leaves — no manual list to maintain.

Why is "add a layer of indirection" the core CS trick here?

The real backends (Pods) are a moving target with changing IPs. A stable Service in front lets clients depend on one fixed address while the Service silently tracks whichever Pods are currently alive.

Why does a rolling update give zero downtime?

maxSurge lets new Pods spin up before old ones are killed, and maxUnavailable bounds how many may be down, so available capacity never falls below

R - maxUnavailable

. Traffic always has healthy Pods to hit.

Why default to ClusterIP for internal microservice-to-microservice calls?

Internal calls never leave the cluster, so ClusterIP is private, cheap, and needs no cloud LB. Reserve external exposure for the one edge entry point.

Why does DNS resolve the public hostname to the Ingress Controller, not to a Pod?

The public internet only knows public DNS and public IPs, not internal cluster names or churning Pod IPs. The Ingress Controller is the one stable public entry point that then routes inward.

Why is Kubernetes described as a "robot comparing desired vs observed state"?

Controllers run a continuous reconciliation loop, watching the gap between what you declared and what exists, and acting until the gap is zero — so the system self-corrects after crashes without you issuing step-by-step commands.

Edge cases

What happens if you create a Deployment with replicas: 0?

It is valid: the Deployment reconciles to zero Pods, so nothing runs but the object stays, ready to scale back up. Useful for pausing a workload without deleting its config.

A Pod matches a Service's selector but its container is failing health checks — does it receive traffic?

No. A Service only routes to healthy (ready) endpoints, so an unready Pod is dropped from the Endpoints list until it passes again. Matching the label is necessary but not sufficient.

Two Deployments both use the label app=web; what does a Service with selector app=web do?

It happily load-balances across Pods from both Deployments, since it selects purely on the label. This is a classic accidental-overlap bug — use distinct, specific labels.

An Ingress rule points to a Service that has zero matching Pods — what does the user see?

The Ingress and Service exist but there are no healthy endpoints, so the request fails (typically a 502/503). The rule being present does not conjure a backend.

You scale a Deployment to 8 replicas but the cluster has no room to schedule them; what happens?

The extra Pods stay in a Pending state until resources free up; desired count is 8 but observed stays lower. The reconciliation loop keeps trying rather than failing outright.

A single node hosting several Pods crashes; what does the Deployment do?

It observes the count dropped below replicas, and schedules replacement Pods on other healthy nodes. Meanwhile the Service simply stops routing to the dead Pods' endpoints.

Recall One-line self-test

Say why hardcoding a Pod IP, using one LoadBalancer per service, and selecting Pods by IP are all the same underlying mistake. Answer ::: All three ignore that Pods are a moving target and that Kubernetes solves it with stable indirection (Service/Ingress + label selection) rather than fixed addresses.