Most Kubernetes tutorials were written against a managed cloud cluster. There, a service of type LoadBalancer causes the cloud provider to provision a real load balancer and return its address. It feels like a built-in feature.
It is not a built-in feature. It is an integration with the cloud provider, and on your own hardware it does not exist. The service is created, the external address stays pending forever, and the tutorial has nothing to say about it.
This is the single most common place where an on-premises Kubernetes project stalls for a week.
What you actually need to decide
How traffic reaches the cluster from your network. Something must own an address that clients connect to, and route it to the right node.
How that address survives a node failure. If it is bound to one node, that node is a single point of failure.
Whether you terminate TLS at the edge or inside. Certificate lifecycle lives wherever you decide this.
Whether your existing load balancers are part of the answer. Frequently they should be, and frequently nobody asks the network team.
The realistic options
A software load balancer inside the cluster that claims addresses from a pool you give it and announces them on your network, either by ARP or by speaking BGP to your routers. The BGP mode is the better one where your network team will cooperate, because failover is handled by routing rather than by gratuitous ARP.
This is the most common on-premises answer and it works well. The cost is that your network team now has a peering relationship with a Kubernetes cluster, which is a conversation worth having early.
Your existing hardware load balancers in front, pointed at node ports. Less elegant, entirely functional, and it keeps the traffic-management conversation with the team that already owns it. Some vendors provide controllers that let Kubernetes configure them directly.
A dedicated ingress tier on nodes with a stable address, fronted by whatever you already use. Simple and explicit.
Ingress versus service
Worth separating these because they get conflated. A LoadBalancer service exposes one service at one address, at the transport layer. An ingress controller is an HTTP reverse proxy inside the cluster that routes many hostnames and paths to many services behind a single entry point.
Most clusters want one or two entry points into an ingress controller, not a load balancer per service. Getting this right early prevents a sprawl of addresses that becomes impossible to manage.
The newer gateway-oriented APIs are gradually replacing the original ingress resource, with a better model for splitting responsibility between platform and application teams. If you are starting now, look at where your distribution stands on that before building heavily on the older object.
Certificates
Decide who issues them and how they renew. An expired certificate is among the most common self-inflicted outages in any environment, and a cluster full of short-lived automatically-renewed certificates is much safer than one where somebody has a calendar reminder.
If you have an internal certificate authority, the integration work is worth doing properly once.
The point
The cloud tutorials skip this because in the cloud it is free. On your hardware it is a design decision with your network team in the room, and it should happen before you build the cluster rather than on the day somebody tries to reach an application.