Kubernetes Ops: Scheduling & Resources
Control what gets deployed and where. Master resource requests and QoS, scheduling, network policies, admission control and autoscaling — the operational core of running Kubernetes — with spaced repetition.
- practice cards
- 115
- practice cards
- per day
- ~10 min
- per day
- level
- Intermediate → Advanced
- level
- modules
- 6
- modules
Where workloads actually land
Running Kubernetes well is mostly about deciding what runs and where. Resource requests and limits set a Pod's quality of service and decide who gets evicted under pressure. The scheduler places Pods using affinity, taints and tolerations. Network policies isolate traffic, admission controllers gate every API request, and autoscalers add or remove capacity as load changes.
This track covers those operational levers in depth — resource management and QoS classes, Pod scheduling, network policies, admission control, and horizontal and vertical autoscaling — grounded in real troubleshooting situations.
Spaced repetition keeps these details sharp, because in operations the difference between a smooth cluster and a 2 a.m. page is often one resource setting.
6 modules, seed to bloom
Each module is a set of practice cards — 115 in total. Answer, review, and watch your knowledge grow from seed to full bloom.
Resource Management
QoS deep dives, eviction mechanics, LimitRange gotchas, cgroup enforcement, and production resource patterns
22 cardsPod Scheduling
Affinity gotchas, taint mechanics, topology spread edge cases, preemption, PDB interaction, and priority classes
20 cardsNetwork Policies
Isolation mechanics, AND vs OR selectors, ipBlock exceptions, DNS gotchas, CNI enforcement, and AdminNetworkPolicy
16 cardsAdmission Controllers
Webhook chain mechanics, Pod Security Standards, built-in controllers, failure policies, and production gotchas
20 cardsAutoscaling
HPA algorithm and behavior policies, VPA modes and coexistence, KEDA scale-to-zero, in-place resize, and autoscaler lag reality
22 cardsPractical Tips
Real-world what-if scenarios — diagnose why Pods stay Pending, get OOMKilled, throttle, leak traffic, or refuse to scale
15 cardsSample questions
A taste of the real cards. Pick an answer, then reveal the explanation.
Memory is called an incompressible resource. What does this mean in practice?
- AOnce allocated, the kernel cannot reclaim memory gradually — it must kill the process to free the resource
- BThe kernel compresses memory pages when usage is high, trading CPU time for reduced memory footprint
- CMemory limits are enforced at allocation time — the kernel blocks new allocations before they exceed the limit
- DMemory is pinned to a single CPU socket and cannot be moved between NUMA nodes under pressure
In node affinity, multiple nodeSelectorTerms are ORed. Multiple matchExpressions within one term are ANDed. What does this mean in practice?
- AA Pod schedules if ANY term matches, but within one term ALL expressions must match simultaneously
- BEvery term and every expression across all terms must match for the Pod to schedule on a node
- CTerms are evaluated in order and the first matching term wins, causing later terms to be skipped
- DExpressions within a term are ORed and the terms themselves are ANDed for stricter filtering
A Pod becomes 'isolated for ingress' when a NetworkPolicy selects it. What does this actually mean?
- AAll ingress not explicitly allowed by any selecting policy is denied — the Pod switches from default-allow to default-deny
- BThe Pod is moved into an isolated network namespace where it can only receive traffic from policy-matched sources
- CThe Pod's network interface is reconfigured by the CNI to accept connections only on ports listed in the policy
- DThe Pod still receives all traffic, but connections from non-matching sources are logged to the audit subsystem
What is the primary function of the Horizontal Pod Autoscaler (HPA)?
- AAdjusts the number of Pod replicas — scales out or in based on observed metrics like CPU utilization
- BAdjusts CPU and memory requests — right-sizes resource allocations based on historical usage patterns
- CAdds or removes cluster nodes — provisions infrastructure when Pods cannot be scheduled on existing capacity
- DRestarts unhealthy Pod containers — replaces failing instances based on observed health probe failures
Learn it once, keep it for good
Answer a question
Each card is one practical concept with multiple options. Pick what you think is right.
Get the full answer
See the correct option plus a clear explanation, and a link to deeper docs when one is available.
Review at the right time
A spaced-repetition engine (SM-2 or FSRS) resurfaces each card just before you would forget it.
Why operations knowledge pays off
Right-size your workloads
Requests, limits and QoS decide stability and cost — get them right and the cluster stops surprising you.
Control placement
Scheduling, affinity and taints put the right Pods on the right nodes instead of leaving it to chance.
Scale on purpose
Autoscaling that you actually understand handles traffic spikes without over-provisioning.
Production-grade
This is the day-to-day knowledge that separates running Kubernetes from operating it.
Common questions
Do I need the basics first? +
Yes — this is operational depth. If Pods, Deployments and Services are new, start with the Kubernetes Fundamentals track.
How long does it take? +
About 10 minutes a day. Spaced repetition means short, frequent sessions beat long cramming, so the operational details stick.
Is it free? +
Yes, completely free. No registration or credit card is required, and all your progress is stored locally in your browser.
Ready to operate Kubernetes?
Plant your first seed today. Ten minutes a day is all it takes to grow real operational expertise.