Exercises — Kubernetes — pods, deployments, services, ingress (concepts)

(a) Service — stable virtual IP + load balancing across matching Pods. (b) Ingress — L7 HTTP(S) router by host/path with TLS termination. (c) Pod — smallest deployable unit, where the container actually runs. (d) Deployment — controller keeping a replica count and doing rolling updates.

(a) False. Pods are ephemeral; a new Pod with a new IP appears — never the same identity. (b) False. ClusterIP is reachable only inside the cluster; expose it via NodePort, LoadBalancer, or an Ingress. (c) False. An Ingress is only a rule-set. Rules do nothing unless an Ingress Controller (nginx, Traefik, …) is running to enforce them.

Each new Pod is created from the same template, so it also carries app=cart. The Service's label selector automatically picks up all matching healthy Pods. Endpoints = 8. Clients to reconfigure = 0 — the Service IP and DNS name never change. That zero is the whole payoff of indirection.

(a) Minimum available $=R-\text{maxUnavailable}=10-2=\boxed{8}$. (b) Maximum total $=R+\text{maxSurge}=10+3=\boxed{13}$. So capacity never dips below 8 (zero-downtime), while up to 13 Pods can co-exist for a moment. Look at the bar in s01: the shaded floor is the "min available" line.

$\text{maxUnavailable}=\lfloor 0.25\times 10\rfloor =\lfloor 2.5\rfloor =2$. $\text{maxSurge}=\lceil 0.50\times 10\rceil =\lceil 5\rceil =5$. Min available $=10-2=8$. Max total $=10+5=15$.

Pods are mortal. Nightly node maintenance / autoscaling reschedules the payments Pod; the replacement gets a new IP (e.g. 10.1.9.2). The clients still dial the dead 10.1.4.7 → connection refused. Fix: put a Service (ClusterIP) in front. Clients dial the stable Service DNS name; the Service's Endpoints list is auto-updated to the current Pod IP. This is the classic "add a layer of indirection over a moving target."

A Service selector is an AND of all its key/value pairs. A Pod joins the Endpoints only if it matches every pair. The Pods match app=web but are missing tier=frontend, so none match → 0 endpoints → all traffic fails. Minimal fix: add tier: frontend to the Pod template's labels (or drop tier: frontend from the selector). Match the sets exactly.

With $\text{maxSurge}=0$: total Pods can never exceed $R=4$, so no new Pod can be created without first removing an old one. With $\text{maxUnavailable}=0$: available must stay $\ge R-0=4$, so no old Pod may be removed either. The two knobs together forbid both adding and removing → the rollout deadlocks. Fix: set at least one knob to $\ge 1$ (commonly maxSurge: 1).

(a) 6 LoadBalancers → 6 LBs, 6 public IPs, cost = 6 \times 18 = \108/\text{month}$.\ast \ast (b)\ast \ast 1IngressLB,6internal‘ClusterIP‘Services\to 1LB,1publicIP,cost$= 1 \times 18 = $18/\text{month}$.\ast \ast Saving$= 108 - 18 = $90/\text{month}$** (and 5 fewer public IPs). This is exactly why Ingress exists: one L7 entry point routing by URL beats one dumb L4 LB per service.

1. DNS resolves shop.example.com → the Ingress Controller's external IP (the internet only knows public DNS).
2. Ingress matches host + path /cart, terminates TLS, forwards to cart-service (L7 routing).
3. Service (ClusterIP) load-balances via selector app=cart to one healthy Pod (stable target, Load Balancing).
4. Pod runs the container and replies. If the serving Pod dies: the Deployment keeps replicas: 3, so a new Pod is created; the Service's readiness checks drop the dead Pod from Endpoints and route the client's retry to a live one — hence no permanent outage.

SLA: $R-\text{maxUnavailable}\ge 12\Rightarrow 15-\text{maxUnavailable}\ge 12\Rightarrow \text{maxUnavailable}\le 3$. Largest $=3$. Capacity: $R+\text{maxSurge}\le 20\Rightarrow 15+\text{maxSurge}\le 20\Rightarrow \text{maxSurge}\le 5$. Largest $=5$. Check: min available $=15-3=12\ge 12$ ✓ (SLA exactly met); max total $=15+5=20\le 20$ ✓ (capacity exactly met). See s02.

Objects:

• Deployment api — replicas: 4, Pod label app: api, strategy e.g. maxSurge: 1, maxUnavailable: 0 (strict zero-downtime).
• Service api-svc — type ClusterIP, selector app: api.
• Deployment shop — replicas: 2, Pod label app: shop.
• Service shop-svc — type ClusterIP, selector app: shop.
• One Ingress — rule host: api.site.com → api-svc; rule host: site.com, path: /shop → shop-svc; TLS termination for both.
• Ingress Controller running (nginx/Traefik) exposed via one LoadBalancer. Public IPs used: 1 (the Ingress LB). CI/CD updates the image tag in a Deployment; the reconciliation loop rolls Pods within the knobs → no client touches the change.

Available Pods satisfy $P_{\text{available}}\ge R-\text{maxUnavailable}$ at every instant (the update controller never removes a Pod that would violate this). Dividing by the promised count $R$: $\frac{P_{\text{available}}}{R}\ge \frac{R-\text{maxUnavailable}}{R}=1-\frac{\text{maxUnavailable}}{R}.$ For $R=15$, $\text{maxUnavailable}=3$: fraction $\ge 1-\frac{3}{15}=1-0.2=0.8$, i.e. at least 80% capacity throughout — the guaranteed floor.