Help newcomers learn how Pods usually map to nodes

[sftim]

This is a Feature Request

What would you like to be added

• Add a good practice page about Pods and nodes and scheduling Explain that the most common way to place Pods is to have control plane nodes and general purpose (“worker”) nodes. Mix workload Pods so that they run on any worker nodes unless you have a good reason not to. Keep the control plane nodes just for running the control plane. (this is not the same as topology spread, which is about allowing different kinds of pod to mix, but keeping same pods apart to improve expected resilience)
• Add some visuals, such as a diagram or screenshot, that help newcomers appreciate that a single node may well run a large number of Pods, quite possibly from different namespaces.

Why is this needed Sometimes, people who use Kubernetes believe or suspect that the typical way to use Kubernetes is with a small number of Pods per node. Other people infer that the usual way people use Kubernetes is with each node only running Pods from one namespace.

Both of those things are common but they are not the norm. The changes proposed in this issue should that detail discoverable for newcomers, or at least help them correct a misapprehension early in their learning journey.

We have diagrams that show clusters and we often show only a few Pods per node to make the diagrams. That keeps the diagrams simple, but it might accidentally mislead some readers.

Comments /language en

[sftim]

Pages to consider changing:

• https://kubernetes.io/docs/concepts/scheduling-eviction/
• https://kubernetes.io/docs/concepts/workloads/pods/
• https://kubernetes.io/docs/concepts/overview/

[utkarsh-singh1]

Hi @sftim , should it include manual scheduling and littile details about scheduling algo?

/assign

[sftim]

The first key task for a contributor is to outline what kind of change could be the right thing to do (and to state that here, in a comment, as their proposed approach).

[sftim]

BTW I recommend that contributors avoid assigning themselves to any issue not triaged as accepted.

If you're going to pick up a package of work, it helps if you're willing to work on:

• accepted issues
• especially, accepted issues that have a high priority
• especially, accepted issues that have been open for a while and are prioritized above backlog

[Pradumnasaraf]

This will be a great addition and help new people.

/triage accepted

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted