I guess you mean how Services do automatical load-balancing. Imagine you have a Deployment with 2 replicas on your one node and a Service. Traffic to the Pods goes through the Service so if that were not load-balancing then everything would go to just one Pod and the other Pod would get nothing. You could then handle more load by spreading evenly and still be confident that traffic will be served if one Pod dies.

You can also load-balance traffic coming into the cluster from outside so that the entrypoint to the cluster isn't always the same node. But that is a different level of load-balancing. Even with one node you can still want load-balancing for the Services within the cluster. See Clarify Ingress load balancer on load-balancing of external entrypoint.

If you can do it on one node , it doesn't mean that you should do it , specially in production environment.

• the production cluster will have least 3 or 5 nodes min
• kubernetes will spread the replicas across the cluster nodes in balancing node workload , pods ends up on different nodes
• you can also configure on which nodes your pods land
• use advanced scheduling , pod affinity and anti-affinity
• you can also plug you own schedular , that will not allow placing the replica pods of the same app on the same node
• then you define a service to loadbalance across pods on different nodes
• kube proxy will do the rest

here is a useful read:

https://itnext.io/keep-you-kubernetes-cluster-balanced-the-secret-to-high-availability-17edf60d9cb7

So you generally need to choose a level of availability you are comfortable with. For example, if you are running three nodes in three separate availability zones, you may choose to be resilient to a single node failure. Losing two nodes might bring your application down but the odds of loosing two data centres in separate availability zones are low.

The bottom line is that there is no universal approach; only you can know what works for your business and the level of risk you deem acceptable.