Change:
{{< note >}} Another possible explanation for the CPU use being below 1.0 is that the Node might not have <del> enough CPU resources available. Recall that the prerequisites for this exercise require each of your Nodes to have at least 1 CPU. If your Container runs on a Node that has only 1 CPU, the Container cannot use more than 1 CPU regardless of the CPU limit specified for the Container. </del> <ins> enough CPU resources available. Recall that the prerequisites for this exercise require your cluster to have at least 1 CPU available for use. If your Container runs on a Node that has only 1 CPU, the Container cannot use more than 1 CPU regardless of the CPU limit specified for the Container. </ins> {{< /note >}} ## CPU units

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!