Most people prepare for Kubernetes interviews by memorizing definitions.
Real interviews are different.
Youโll be asked things like:
โข Why is a pod stuck in Pending?
โข Why did the app suddenly start returning 403?
โข How would you upgrade EKS without downtime?
โข Why is the deployment in CrashLoopBackOff?
โข How do you isolate traffic between namespaces?
Thatโs what actually tests DevOps engineers:
Debugging + production thinking.
This article covers 25 real Kubernetes interview scenarios every DevOps engineer should know.
Karpenter internals โ let's make it concrete.
Two core concepts:
NodePool:
Defines constraints for the nodes Karpenter can provision. Think of it as your "what am I allowed to create?" policy.
NodeClass (EC2NodeClass on AWS)
The cloud-specific config โ AMI, subnets, security groups, instance profile.
The genius bit: disruption + consolidation.
Karpenter doesn't just scale up. It continuously asks: "can I pack these workloads onto fewer, cheaper nodes?" If yes, it drains and replaces automatically.
That consolidation line alone can cut your EC2 bill by 20โ30%.
One noisy container can ruin performance for every other workload on the same node.
Containers are isolatedโฆ
but not as completely as many engineers assume.
The kernel still shares critical resources like:
โข disk I/O
โข network bandwidth
โข CPU caches
โข memory pressure
So one aggressive workload can create collateral damage across the node.
Typical example:
A heavy batch job starts massive disk writesโฆ
and suddenly your latency-sensitive API becomes slow for completely unrelated requests.
CPU and memory isolation via cgroups is reasonably mature.
I/O and network isolation are far weaker by default.
Thatโs why โneighbor noiseโ still exists heavily in Kubernetes environments.
If workloads have very different performance profiles:
โข isolate them with taints and tolerations
โข use node affinity
โข separate critical services onto dedicated nodes
The scheduler optimizes placement.
It does not guarantee peace between workloads.