Kubernetes and Container Orchestration Fundamentals Questions

Core knowledge of container orchestration with a focus on Kubernetes fundamentals and everyday operations. Candidates should understand the role of orchestration and why it is used at scale, and be familiar with core Kubernetes objects including pods as the smallest deployable unit, deployments and replica management, replica sets, services for inter pod communication and service discovery, config maps and secrets for configuration and secret management, and the basic lifecycle of containerized applications. Coverage includes deployment and scaling workflows, rolling update and rollout strategies including rollbacks, common deployment patterns such as blue green and canary, and basic health checks and probe concepts. Practical operational skills include common kubectl commands for deploying, inspecting, scaling and debugging applications, reading pod logs and events, describing resources, port forwarding, and diagnosing common failure modes. Candidates should also understand high level trade offs between using managed cloud provider Kubernetes services and operating self managed clusters including operational overhead, upgrades, cost, and reliability considerations. The scope focuses on fundamentals and day to day operations and excludes advanced cluster administration topics such as custom operators, admission controllers, control plane internals, and deep platform level configuration.

EasyTechnical

72 practiced

Explain the relationship between a Deployment and its ReplicaSet in Kubernetes. What responsibilities does each object have regarding desired state, reconciliation, scaling, and rollouts, and why should teams typically operate against Deployments instead of directly manipulating ReplicaSets?

HardTechnical

75 practiced

A production pod is being OOMKilled intermittently. Walk through diagnostics to determine whether this is caused by a memory leak, misconfigured limits, or node-level memory pressure. Include commands, metrics to observe, and how you would implement and roll out a fix with minimal customer impact.

Sample Answer

Approach / framework:1) Quickly triage to classify cause (app leak vs misconfig vs node pressure).2) Collect pod/node evidence (metrics, logs, cgroup).3) Reproduce / instrument if needed.4) Implement minimal-impact fix (safety nets + targeted change).5) Monitor and roll out permanently with rollback plan.

Immediate diagnostics (commands & what to look for):- Check pod status + recent events: kubectl get pod -n app -o wide kubectl describe pod/<pod> -n app Look for OOMKilled reason, container restart count, eviction events.

- Inspect kubelet/node events: kubectl describe node/<node> journalctl -u kubelet -f dmesg | grep -i -E 'oom|killed' Look for node OOM killer messages (process names, oom_score_adj).

- Check resource usage (live): kubectl top pod -n app kubectl top node <node> Compare pod RSS vs container memory limit; if pod RSS approaches limit before kill, likely container limit issue or leak. If node memory near 100% and many pods below limits, likely node-level pressure.

- Inspect cgroup usage from node for the container: # on node docker/podman/crictl inspect <container-id> | jq . (or crictl stats) cat /sys/fs/cgroup/memory/kubepods/.../<container>/memory.max_usage_in_bytes

- Historical metrics (Prometheus/Grafana): PromQL examples: container_memory_working_set_bytes{pod="app-xx"} — trend for leak container_memory_rss_bytes / container_spec_memory_limit_bytes — % of limit node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes — node pressure kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} node:container_memory_failures_total (if available)

- App-level traces / heap: For JVM: jmap/jstack or heap dump on high memory; for Go: pprof endpoint; for Python: tracemalloc or guppy. Capture heap/profile when memory near peak for diagnosis.

How to distinguish causes (rules of thumb):- Memory leak: single pod’s memory shows monotonically increasing working_set over time across restarts; percentage of limit grows and OOM occurs consistently for that pod, independent of node.- Misconfigured limits: app RSS < node memory available but > container limit at kill; set too-low limit relative to app footprint or bursts. Also if limit << historical usage.- Node-level pressure: many pods evicted or node OOM logs; node memory near full while individual pods under limits; kernel OOM kills processes unrelated to container limit.

Immediate mitigations to reduce customer impact:- Add a short-term safety buffer: scale horizontally (kubectl scale deployment --replicas +1) to reduce load per instance.- Increase container memory limit cautiously for affected deployment (edit deployment, use canary): create a canary deployment with +30% memory to observe.- If node pressure: cordon node, drain with --ignore-daemonsets --delete-local-data to stop new pods landing and move load; add capacity (scale nodes) or restart kubelet if leaking.- Add OOMGuard patterns: set proper requests (guarantee scheduling) and limits; consider eviction thresholds.

Fix rollout plan (minimal customer impact):1. Canary: create new ReplicaSet with updated memory limit/profiled config and 1–2% traffic (service weight or use feature flag / ingress weight).2. Monitor key metrics for 30–60 minutes: OOMKilled count, latency, error rates, memory working_set, GC pressure.3. If stable, progressively roll out (30% → 60% → 100%) via rolling update with maxUnavailable set to small value and PodDisruptionBudget to protect minimum capacity.4. If root cause is leak in code, fix in branch, include unit/integration tests, add heap/pprof endpoints, deploy fix behind canary, monitor longer-term (days).5. If node-level, increase cluster autoscaling or replace faulty node type; if kernel OOM due to host process, remediate host-level service or OS config.

Postmortem + prevention:- Add alerts: container_memory_working_set_bytes / container_spec_memory_limit_bytes > 0.8 for 5m; node memory available < 15% for 5m.- Add heap/pprof scraping, periodic memory regression tests in CI, and a runbook for OOMKill incidents.- Adjust SLOs / error budgets if needed and document chosen memory limits and rationale.

Edge considerations:- Avoid blanket limit increases without profiling.- Use graded rollout to avoid mass failures.- Keep rollback simple: revert to previous ReplicaSet or scale back limits and traffic weight.

This diagnostic and rollout sequence lets you identify leak vs config vs node pressure, apply a low-risk mitigation (canary/increase capacity), and implement a tracked permanent fix.

HardSystem Design

84 practiced

Design a safe upgrade process for both application images and node software such as OS patches and kubelet upgrades in a production Kubernetes environment. Explain sequencing, how to canary upgrades on a subset of nodes or pods, cordon and drain procedures, validation steps, and rollback options if upgraded nodes or pods exhibit regressions.

Sample Answer

Requirements & constraints:- Zero/low downtime for critical services, preserve SLOs, support canary testing, safe rollback, automated but auditable, support heterogeneous node pools.

High-level approach:1. Plan & prechecks - Inventory node pools, labels, workloads (PDBs, DaemonSets), capacity buffer (N+1), health checks, backup ETCD and control-plane. - Define canary fraction (e.g., 5% nodes / 1–2 pods per service), success criteria (health endpoints, latency, error rate, resource usage), rollout window, and maintenance windows.

2. Sequencing - Application image canaries first on new nodes or pods; node (OS/kubelet) upgrades after app stability. - Sequence: canary pods → validate → gradual fleet rollout of pods → cordon+drain nodes → upgrade node OS/kubelet → uncordon → validate on node → continue.

3. Canary strategy - Create a canary release by: - Deploying a duplicate ReplicaSet/Deployment with image tag canary and limited replica count, or - Using traffic-splitting (Istio/Ingress) to route a small % to canary pods. - Monitor canary against control: error rate, latency, traces, logs, and resource metrics for a minimum observation period. - Automated promotion if metrics pass; else rollback canary image.

4. Cordon & drain procedure (automated) - For each node in upgrade batch: - kubectl cordon <node> - kubectl drain <node> --ignore-daemonsets --delete-emptydir-data --pod-selector="upgrade-safe!=false" (respect PDBs) - Verify pods scheduled elsewhere and service endpoints healthy before proceeding. - If drain blocks due to PDBs, skip node or schedule maintenance with owners.

5. Node upgrade steps - Batch size = small (1 for control-plane, small % for workers) - Upgrade OS patches, reboot if needed, update kubelet + kube-proxy; ensure versions compatible (kubelet skew policy). - Run kubelet health checks, kube-proxy, container runtime, and kubelet logs. - Run smoke tests: kube-system pods, cAdvisor, kubelet metrics, and sample application pods.

6. Validation & observability - Predefined health gates: pod readiness, service-level metrics (latency, error-rate), Prometheus alerts, synthetic checks, distributed traces for regressions. - Automated gating: CI/CD pipeline or operator enforces gates before next batch. - Duration: minimum steady-state observation window (e.g., 15–60 minutes) per batch.

7. Rollback options - Application image rollback: revert Deployment/VirtualService traffic immediately to previous stable tag or scale down canary and scale stable back up; automated rollback if alerts trigger. - Node rollback: if node-regression evident post-upgrade, cordon node, drain new node (if possible), reboot into previous OS kernel or reimage with golden AMI, reinstall prior kubelet version; remove from rotation only after validation. - Fleet rollback: stop rollout, mark release as failed, trigger incident runbook, notify stakeholders, escalate to emergency patch window if widespread.

8. Automation & safety - Use an operator (Flux/ArgoCD + Argo Rollouts) or cluster management tool (kured, MCO, Cluster API) to automate cordon/drain/upgrade with canary hooks. - Keep audit logs and runbooks. Use feature flags and AB testing for risky features.

Trade-offs: - Smaller batches = safer but slower. Automated gating reduces human error but requires robust monitoring. Always test procedure in staging and on a dedicated canary node pool before production.

This process prioritizes controlled exposure, automated validation gates, safe cordon/drain respecting PDBs, and clear rollback paths to maintain availability and SLOs.

MediumTechnical

78 practiced

Write a basic Kubernetes Ingress description in words for nginx-ingress that routes path /api to service api-svc port 80 and / to frontend-svc port 80. Additionally, discuss when to use Ingress versus using Service type LoadBalancer in cloud environments and the pros and cons of each approach.

Sample Answer

Ingress description (nginx-ingress controller):Create an Ingress resource that uses the nginx-ingress controller as the backend. Define two HTTP path rules under the same host (or for all hosts): requests with path prefix /api are forwarded to the Kubernetes Service named api-svc on port 80; requests to the root path / (or path prefix /) are forwarded to frontend-svc on port 80. Configure sensible annotations for nginx (e.g., rewrite-target if needed, proxy-buffering, timeouts) and attach TLS secrets if you require HTTPS termination at the ingress.

When to use Ingress vs Service type=LoadBalancer (cloud):

Use Ingress when:- You need HTTP(S) routing: path- or host-based routing, rewriting, LB rules, TLS termination, rate limiting, auth, or central TLS cert management.- You want a single external IP / hostname to serve many services (consolidated egress).- You want ingress controller features (WAF, annotations, custom NGINX config snippets).

Pros:- Consolidates routing and TLS management.- Cheaper: single cloud LB for many services.- Rich HTTP controls (routing, rewrites, auth, observability).Cons:- Adds another component to manage (ingress controller).- Potential performance limits depending on controller.- More complex debugging for L4 behaviors.

Use Service type=LoadBalancer when:- You need a dedicated external L4 load balancer per service (non-HTTP protocols like TCP/UDP, or when you need source IP preservation).- Simpler setup for one service needing direct external exposure or very high throughput/low latency.

Pros:- Simpler, cloud-managed LB with SLA, often high performance.- Native support for non-HTTP protocols and easier source-IP handling.Cons:- Each LB costs money and consumes quota/IPs.- Lacks HTTP routing features (no path/host routing or TLS management across services).

SRE guidance:- Prefer Ingress (nginx) for most web traffic to centralize TLS and routing; use LoadBalancer for non-HTTP services, high-throughput/low-latency endpoints, or when you need cloud LB features (global LB, internal LBs) per service. Monitor ingress controller health, set resource limits, and slowly roll config changes to avoid outage.

EasyTechnical

102 practiced

Describe what a Pod is in Kubernetes and why it is considered the smallest deployable unit. Explain when you would run multiple containers in a single pod, how containers inside a pod share network and volumes, and trade-offs of co-locating containers such as sidecar patterns versus separate pods.

Unlock Full Question Bank

Get access to hundreds of Kubernetes and Container Orchestration Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.