Ingress vs Load Balancer

Question

I am new to kubernetes and I am trying to expose an application publicly. I am using Scaleway as the cloud provider (if it matters).

From what I understand, there are multiple ways of doing this.

1. Create an Ingress Controller

   By doing this, the ingress exposes a nodes IP address and port and forwards all requests to the attached service.

   I pointed the DNS record to the publicly exposed IP.

   SSL certificate is created using cert-manager and it seems to work great with the ingress controller meaning that the certificate is automatically created and attached to the ingress resource.

   How do you manage DNS records when the cluster has multiple nodes which can be deleted / created automatically?

2. Create a Load Balancer type service

   This creates a cloud provided Load Balancer which internally is configured to route all traffic to all nodes from the cluster.

   With this approach I can point the DNS records to the Load Balancer IP which in turn can be configured to preserve the public IP, meaning that cluster nodes can be attached / removed and it will not affect the DNS records.

   But I do not know how to add a SSL certificate using this approach. Any thoughts?

Which of the two approaches is best suited for exposing an application keeping in mind the DNS management and SSL certificates?

Answer 1

After talking with the support staff from the cloud provider, reading through the docs and looking at how other cloud providers do it, I believe that both of them are needed.

In order to have a simple DNS zone management, you need to expose all your cluster nodes in some way and that way is with an external LoadBalancer.

The LoadBalancer makes sure to always point to all the cluster nodes even when there are changes to the nodes themselves (add / remove). This way you can update the DNS zone for the domain you want by pointing to the LoadBalancer IP. Of course, you will need to make sure that this IP will not change.

Since now there is a way to route external traffic from your custom domain to the kubernetes cluster, you need to know where to redirect that traffic.

Here comes the Ingress Controller.

With it you can forward traffic based on host name, for example, in order to reach your desired Service.

Comparing two cloud providers and their approach for publicly exposing an application, I found that both of them are using an external LoadBalancer together with an IngressController:

1. Scaleway

   In order to expose all cluster nodes through a LoadBalancer you need to create a Service with the following:

spec:
  type: LoadBalancer
  ports:
    - port: 80
      name: http
      targetPort: 80
    - port: 443
      name: https
      targetPort: 443

targetPort is required to be those exact ports.

After LoadBalancer is created you can use its IP address for the DNS Records.

Now, you can create the Ingress Controller to forward traffic to Services.

2. AWS

   You can create an Ingress Controller which itself creates an AWS Application Load Balancer.

   The ALB does not have an IP, instead it relies on a CNAME Record.

Both of them are using an external LoadBalancer to forward traffic to the cluster and both of them are using IngressController to redirect traffic to Services.

I believe this is the way of publicly expose an application behind a kubernetes cluster.

Answer 2

A LoadBalancer is a cloud specific resource, you wouldn't have a LoadBalancer if you had kubernetes running on a raspberrypi, for example. Instead you would have to provision your own using something like metalLB.

When you create a LoadBalancer in aws, it creates a NLBenter link description here, a resource external to the cluster.

An Ingress type is a way of routing requests to the correct services.

So, your request would go through:

1. Internet - going all the way from your browser to your cloud provider
2. NLB (LoadBalancer) - on your cloud provider network
3. VM (ec2) - routed from the NLB
4. Ingress - finds the correct service to proxy the request to
5. Service - Also a load balancer, but internal to the cluster, find the deployment/statefulset, etc and gets the replicaset and picks a pod to route the request to
6. Pod - receives the request
7. Container - processes the request

And that's not even the most complex setup. You can add ambassadors, sidecars, MTLs, VPNs. Things can go crazy.

Here's a meme for clarification: