Change:
[default CPU request and limit](/docs/tasks/administer-cluster/cpu-default-namespace/) from the LimitRange. <del> At this point, your Container might be running or it might not be running. Recall that a prerequisite for this task is that your Nodes have at least 1 CPU. If each of your Nodes has only 1 CPU, then there might not be enough allocatable CPU on any Node to accommodate a request of 800 millicpu. If you happen to be using Nodes with 2 CPU, then you probably have enough CPU to accommodate the 800 millicpu request. </del> <ins> At this point, your Container might be running or it might not be running. Recall that a prerequisite for this task is that your cluster must have at least 1 CPU available for use. If each of your Nodes has only 1 CPU, then there might not be enough allocatable CPU on any Node to accommodate a request of 800 millicpu. If you happen to be using Nodes with 2 CPU, then you probably have enough CPU to accommodate the 800 millicpu request. </ins> Delete your Pod:

Discussion:
A couple of pages: state that Based on what I know about nodes, this seems like something you could take for granted. Consider ~dropping~ revising that text.
/kind cleanup /priority backlog
Just realized this is talking about Kubernetes' count of CPUs, rather than what (say) the Linux kernel would see. That might not be obvious to every reader&mdash;I missed it, for example.
/language en
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/help
Happy to help with explanations for anyone who is picking this up.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/assign /remove-help
I was reviewing the docs and I think the statement is referring to the minimal requirements to execute the proposed tasks (and I think this is wrong, because some exercises goes up to 2 cores). Not sure if my understanding is the same as yours.
The “1 CPU” means 1.0 of Kubernetes CPU units. That's different from saying “there needs to be at least one physical CPU core available”. Readers new to Kubernetes might not grasp that Kubernetes has its own idea of CPU number and assume that a Node that runs the kubelet OK must have at least one installed core available to make code execution possible. For example: a node with 0.5 CPU doesn't meet the 1.0 CPU requirement.

If some exercises require more than 1.0 CPU then those pages should explain that. I think addressing that might be a different issue though.
Honestly, I still don't get it. I thought the Kubernetes CPU reflects what the operating system reports (ex.: ). I wasn't considering possible to have a Kubelet running on a node and reporting only 0.5 CPU (how do we do that? flags? cgroup via systemd?). Since the docs are not using term physical, I still think the original author was referring to minimum required resource for the task examples.
To be honest, I might have this wrong too. I do know that the existing text is not clear.
An example of an instance type with < 1.0 CPU:
Even those shared core instances will reports 1 vCPU, but I got your point. I'll try something here!