Hey everyone! I'm diving into Kubernetes and I'm a bit lost on how exposing services works in self-hosted clusters. In my courses, they usually mention Ingress as the primary way to expose services outside the cluster. However, it seems like I can't do that without a load balancer in front of the ingress controller. In cloud environments, it looks like a load balancer is mandatory for exposing services because of their API requirements. Why can't we just use an ingress by itself to expose services via hostname? It seems like I need MetalLB to make this work, but why can't K8s handle this natively? I've been scratching my head over this for a few days, so any clarity would be greatly appreciated! Thanks!
5 Answers
MetalLB essentially adds layer 2 networking to ensure that your services can be exposed across multiple nodes. If you only have a single node, you might think about using nodePort to handle exposure, but if that node fails, you lose access. MetalLB helps by distributing the traffic effectively across your cluster. So yes, it sounds like you're right about needing MetalLB to properly expose your ingress.
The reason K8s can’t handle this with its native resources is that you ask it to be aware of too many external factors. There are multiple strategies available for setting this up. You can use MetalLB for a virtual IP, or use BGP mode for more complex setups. Alternatively, you could implement a LoadBalancer in front of your cluster, using NodePort services. Cloud providers usually handle this load balancing automatically, but that’s not the case in on-prem setups.
That’s super helpful—it’s starting to make sense! Thanks for breaking it down!
Think of MetalLB as the traffic manager at layer 2. It assigns IP addresses for the ingress and services marked as LoadBalancer. Ingress is just one component that utilizes what MetalLB provides. So, when you're running a cluster, MetalLB is doing the heavy lifting so your Ingress can route external traffic properly.
Ah, so MetalLB does give an external IP to the ingress controller, right? That connection makes a lot more sense now!
Honestly, all the explanations just clicked when I set up MetalLB for myself. Same with ingress—doing it hands-on really helped clarify everything for me!
Absolutely! I learn so much better when I can just get my hands dirty. I’m planning on experimenting with this setup in my homelab soon.
Great discussion! Just adding a few thoughts for future readers: MetalLB is often more relevant in kubeadm clusters than in cloud-native K8s setups. Ingress is used for external access while services are for internal. In simple setups, using a LoadBalancer service might suffice, but ingress can offer more protocol control, like TLS handling, compared to a LoadBalancer. So, if you want more flexibility, go for Ingress with something like cert-manager for easier TLS management.
This summary is really useful—appreciate the insights!
So even with multiple nodes, a nodePort only works on the specific node it runs on? If that node goes down, that service is lost? I see now how MetalLB helps with traffic distribution!