Kubernetes — Fundamentals

A Service gives you a stable network identity (a ClusterIP and DNS name like my-svc.my-namespace.svc.cluster.local) in front of a set of Pods selected by label. Pods are disposable — they're rescheduled, restarted, and replaced constantly by the Deployment controller, and each one gets a fresh IP every time. If clients talked to Pod IPs directly, every rollout or crash would break every existing connection reference. The Service's Endpoints/EndpointSlice controller watches matching Pods and keeps the routing table current, so kube-proxy (or a service mesh sidecar) can load balance across whatever Pods are healthy right now, without the caller ever needing to know.

(a sample shape to adapt to your real background, not a script to memorize) — "I ran three EKS clusters supporting about 40 microservices in production for two years. I owned the app-facing side: Helm charts, HPA tuning, and resource requests/limits for our team's services, and worked with the platform team on cluster upgrades. The most involved problem I solved was a noisy-neighbor issue where one service's memory leak was triggering OOM kills on unrelated pods sharing the node — I fixed it short-term with tighter resource limits and pod anti-affinity, then pushed for per-team node pools as the real fix."

kubectl get pods to confirm the exact failure mode and restart count → kubectl describe pod for events (OOMKilled, failed probe, wrong command) → kubectl logs <pod> --previous to see why the last attempt died, since the current container may already have restarted past the useful log output → check the new image/config diff introduced by this rollout (kubectl rollout history) since the old replicas are presumably still healthy → if it's a resource issue, check kubectl top pod and the deployment's requests/limits; if it's a config issue, check the ConfigMap/Secret the new pods mount.

"First I'd confirm it's actually CrashLoopBackOff and not Pending or ImagePullBackOff — kubectl get pods gives me that plus the restart count. Then kubectl describe pod for recent events, and kubectl logs <pod> --previous since the currently-running container might be mid-restart with no useful output yet. Since the old replicas are still up, I'd diff what actually changed in this rollout — new image tag, new env var, new ConfigMap — with kubectl rollout history and the deployment spec. If it turns out to be OOMKilled I'd check requests/limits against actual usage with kubectl top; if it's an app-level crash on startup, the previous logs almost always show a stack trace pointing at a missing config value or a bad migration. I'd also make sure I'm not making it worse — leave the stuck rollout paused rather than forcing a rollback mid-triage unless it's clearly customer-impacting."

"Three issues. First, image: payments-api:latest — floating tags mean you can't reliably reproduce what's running, and a rollback doesn't actually roll back the image; it should be pinned to an immutable tag or digest. Second, there's no resources.requests/limits at all, so the scheduler has no idea what this pod needs and it can starve or get evicted unpredictably under node pressure. Third, and the subtlest: initialDelaySeconds: 0 with periodSeconds: 2 on the liveness probe means Kubernetes starts checking health almost immediately and very frequently — if this app takes more than a couple seconds to actually be ready to serve /healthz, it'll get killed and restarted in a loop before it ever finishes booting. I'd also point out there's no readinessProbe at all, which means traffic can be routed to a pod before it's actually ready, not just before it's alive."

What's the actual availability target (99.9% vs 99.99% changes the answer a lot)? Is this active-active or active-passive across regions? What's the data layer doing — is there a database this API depends on, and is it also multi-region, or does that live outside this design's scope? What's the acceptable failover time (RTO)?

Within each region: multiple Availability Zones, a Deployment with podAntiAffinity to spread replicas across nodes/AZs, an HPA on CPU/latency, and a PodDisruptionBudget so voluntary disruptions (node drains, cluster upgrades) never take the whole service down at once. Across regions: two independent EKS clusters (not one cluster spanning regions — cross-region control-plane latency and split-brain risk make that a bad idea), each fronted by its own ALB/Ingress, with Route 53 latency-based or failover routing on top choosing between them, plus health checks so Route 53 stops sending traffic to a degraded region.

Active-active gets you better latency and no manual failover step, but only works cleanly if the API is stateless and any backing data store is also multi-region-consistent (or the API can tolerate eventual consistency) — otherwise you get split-brain writes. Active-passive is simpler and avoids that problem but wastes capacity sitting idle and has a real failover delay (DNS TTL + health-check interval) that active-active avoids. I'd also flag that "two regions" alone isn't automatically higher availability if a shared dependency (e.g., a single-region auth service) becomes the actual single point of failure.

"I'd run this as two independent EKS clusters, one per region, each with the Deployment spread across 3 AZs via pod anti-affinity, an HPA, and a PodDisruptionBudget so cluster maintenance never drops capacity below what's needed. Route 53 sits in front with health-checked latency-based routing, so users hit their nearest healthy region and we get automatic failover if a region's health checks start failing — no manual intervention needed. The one thing I'd push back on before finalizing this: if the API's backing database is single-region, this design gives false confidence — I'd want to know that before signing off on 'highly available,' since the API being up in two regions doesn't help if they're both blocked on one database region being down."