loadbalancing for kubernetes in non-cloud environment
Asked Answered
T

3

20

I see that kubernetes can use ClusterIP and NodePort and LoadBalancing. For loadbalancing it requires cloud. If I do not have cloud provider how can I loadbalance traffic between nodes?! I know that HAProxy can loadbalance but I think this cloud loadbalancer is different from simple HAProxy

and I want to know what is different between HAProxy and IngressController such as HAProxy and Nginx

I want a loadbalancer to loadbalance traffic between my worker nodes. A service loadbalance traffic between pods.I think ingress controller is layer 7 loadbalancer. I want loadbalancing between my nodes

Thera answered 14/3, 2019 at 12:44 Comment(0)
E
16

I see that kubernetes can use ClusterIP and NodePort and LoadBalancing. For loadbalancing it requires cloud. If I do not have cloud provider how can I loadbalance traffic between nodes?!

The easiest way, as you probably know, would be to set the Service to type NodePort, this signals to kube-proxy to listen to a random port in the default range of 30000-32767 on every node. Under the hood this random port will be mapped (port-forwarded) to the Service port.

You can now send traffic, let's say to the random port of 30001, to any of the nodes and you'll be load balanced internally between the Pods. If you now spin up a e.g. VM in the same network as the nodes or in a network that could reach the nodes and setup load balancing across node-{a,b,c}:30001.

You could, although not recommeneded because of many good reasons, basically just send traffic to one of the nodes (node-a:30001) in a multi node cluster and the traffic would still be load balanced internally. This is possible due to the fact that all instances of kube-proxy knows where all the Pods (or Endpoints in the context of a Service) are located at any given time.

Note that the kube-proxy and iptables (may vary!) is the components that implements the Service object in all cases besides when the type is LoadBalancer. LoadBalancer requests will be dispatched to either the built-in or external cloud controller manager.

The Ingress object exists to add L7 logic in-front of one or more Service's, but as you've seen the Ingress is worthless if there's no Ingress Controller implementing it. HAProxy and Nginx Ingress controllers would more or less do the same thing for you but not solving your problem short-term. Yes, you'll have load balancing but not in the way you might think.

If you do not have any form of (private/public) cloud with k8s integration backing your k8s cluster up the Nginx and HAProxy Ingress controllers would only be another Service running in your cluster. You would of course be able to do smart things like proxying, URL routing, hostname matching etc.

One of the questions to answer if you're in a non-cloud provider environment (e.g. bare metal only) is: How do i get an IP-address in the EXTERNAL-IP field of a Service of type LoadBalancer? Note that i'm assuming the output of the kubectl get service command. One good answer is, as already stated in the comments here: MetalLB.

MetalLB will give you automation in regards to configuring the external IP(s) of your Service of type LoadBalancer. But you could also configure the externalIPs field of the Service object manually and set it to an IP address that would make sense in your environment. Thanks @danielrubambura for pointing this out!

Also see this page over at the official Nginx controller documentation that could shed some light on how and why to use MetalLB in some circumstances.

I'm leaving the comparison between Nginx and HAProxy controllers since i don't think that is important in this case. In the end they'll give you Nginx or HAProxy Pods configured as you want through the Ingress object, with e.g. routing to different Service's based on the Host header in the incoming requests.

Hopefully this clears things up a bit!

Eyeleen answered 21/6, 2020 at 21:27 Comment(2)
This is definitely clear enough. I have been able to set a service of type LoadBalancer in a non-cloud environment. Creating a service of type LoadBalancer in a non-cloud environment usually fail (let's say externalIP remains pending) because you are not provided automatically an externalIP for your loadbalancer, which is done in a cloud environment. To fix it, i manually defined exertnalIP in the service manifest Something like this : externalIPs: - 172.x.x.x - 172.x.x.xSolitude
@danielrubambura Yes, you're right, thanks for mentioning this. And it's important in the context of the Service of type LoadBalancer! MetalLB gives you an automated way (+ bunch of other features) of handing out IP addresses from e.g. a range and that makes sense in your environment. But you could of course manually configure this manually!Eyeleen
S
5

I am facing the same problem here. K8s is made for the cloud in mind, so on premises brings some trouble to setup. On the article below it gives a detailed explanation about this.

https://medium.com/@JockDaRock/metalloadbalancer-kubernetes-on-prem-baremetal-loadbalancing-101455c3ed48

In summary the solutions are to use a NodePort or external Name services. The approach that I will try here is to use metalLB (https://metallb.universe.tf/, https://github.com/google/metallb) .

Spinelli answered 14/3, 2019 at 13:11 Comment(3)
node port can load balance between nodes and their pods.why i should use metalLB?Thera
NodePort doesn't balance anything. That's ClusterIP. You should get these concepts more clear.Transpicuous
@suren, my understanding is that NodePort creates a ClusterIP service that the NodePort service routes to, so it should effectively provide the same load balancing as ClusterIP, no? See also #56159930. In the NodePort config, I believe ports.port specifies the ClusterIP/service/"load-balancing" port, as depicted in this picture under the NodePort section: learn.redhat.com/t5/DO280-Red-Hat-OpenShift/…Profluent
T
1

There should be no need in kubernetes to balance a load between nodes, because for kubernetes a backend is a pod, not a node.

So, you should consider an Ingress Controller, not a load balancer, since Kubernetes core controllers come without some controllers, and IC is one of them, and the ClusterIP type service already does basic load balancing.

Nginx IC is great. So as Istio (different concepts though). Traefik could be an option too. Check different IC options, and get the Ingress Controller concept clear.

Transpicuous answered 20/3, 2019 at 10:30 Comment(2)
In order to launch a ingress service you need a load balancer, in cloud the AWS provides one for you without friction, on premises you can use metalLB for it.Spinelli
Not really. Cloud providers set up load balancers to send the traffic to nodes. Then they rely on the ClusterIP load balancing, as mentioned before. That's a known issue that adds an extra hop. Some IC use one of the node external IP, as entry point.Transpicuous

© 2022 - 2024 — McMap. All rights reserved.