A pod is given `requests: { cpu: 500m }` with no CPU limit, and `limits: { memory: 512Mi }` with no memory request. Under a CPU burst with idle node capacity, and separately under a memory leak, what actually happens in each case — and what is the pod's effective memory request, given only a limit was written?

The CPU burst is simply served, untouched — with no CPU limit, there's no CFS quota configured at all, so the container's CPU usage is bounded only by its cpu.shares weight (from the 500m request) relative to other cgroups when CPUs are actually contended, and the scenario says the node has spare capacity, so nothing throttles it. The memory leak is fatal, not gradual: a memory limit is a hard ceiling with no soft mode, so the instant total usage would cross 512Mi the kernel's OOM killer sends SIGKILL — no warning, no throttling first, immediate. And the memory request isn't actually unset: Kubernetes' API defaulting sets it equal to the limit whenever a limit is given with no request, so this pod reserves the full 512Mi on its node the entire time it runs, regardless of how little it typically uses.