What s the difference between kubernetes load balancer and ingress controller

Question

I cannot seem to understand the difference between the two. Ingress maps the incoming traffic to the services in the cluster while load balancer forwards it to a host. Both seem to be doing the same thing. And how is kubernetes load balancer compared to Amazon ELB and ALB?

Answer 1

Load Balancer: So Kubernetes LoadBalancer just points to external load balancers which do not reside in your cluster. If your pods are externally routable, these load balancers can work with them. Google and AWS have native capability for this. When using amazon it by default maps it to ELB for load balancing.

Ingress: In Ingress on the other hand you can define a set of rules that your controller actively listens to. A load balancer service is something that could listen to these ingress rules. You can deploy ingress rules, but they will not work unless mapped to a controller. NodePort service can also be used for this provided it has an extrenal routable IP outside of the cluster.

Ingress controller simply just process and makes sense of ingress rules. One of the most common and widely used ingress controller is the nginx controller. Amazon ALB can also be used as an ingress controller.

For an example, this nginx controller is able to ingest ingress rules you have defined and translate them to an nginx.conf file that it loads and starts in its pod.

Let's for instance say you defined an ingress as follows:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
   ingress.kubernetes.io/rewrite-target: /
 name: web-ingress
spec:
  rules:
  - host: kubernetes.foo.bar
    http:
      paths:
      - backend:
          serviceName: appsvc
          servicePort: 80
        path: /app

If you then inspect your nginx controller pod you'll see the following rule defined in /etc/nginx.conf:

server {
    server_name kubernetes.foo.bar;
    listen 80;
    listen [::]:80;
    set $proxy_upstream_name "-";
    location ~* ^/web2\/?(?<baseuri>.*) {
        set $proxy_upstream_name "apps-web2svc-8080";
        port_in_redirect off;

        client_max_body_size                    "1m";

        proxy_set_header Host                   $best_http_host;

        # Pass the extracted client certificate to the backend

        # Allow websocket connections
        proxy_set_header                        Upgrade           $http_upgrade;
        proxy_set_header                        Connection        $connection_upgrade;

        proxy_set_header X-Real-IP              $the_real_ip;
        proxy_set_header X-Forwarded-For        $the_x_forwarded_for;
        proxy_set_header X-Forwarded-Host       $best_http_host;
        proxy_set_header X-Forwarded-Port       $pass_port;
        proxy_set_header X-Forwarded-Proto      $pass_access_scheme;
        proxy_set_header X-Original-URI         $request_uri;
        proxy_set_header X-Scheme               $pass_access_scheme;

        # mitigate HTTPoxy Vulnerability
        # https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
        proxy_set_header Proxy                  "";

        # Custom headers

        proxy_connect_timeout                   5s;
        proxy_send_timeout                      60s;
        proxy_read_timeout                      60s;

        proxy_redirect                          off;
        proxy_buffering                         off;
        proxy_buffer_size                       "4k";
        proxy_buffers                           4 "4k";

        proxy_http_version                      1.1;

        proxy_cookie_domain                     off;
        proxy_cookie_path                       off;

    rewrite /app/(.*) /$1 break;
    rewrite /app / break;
    proxy_pass http://apps-appsvc-8080;

    }

Nginx has just created a rule to route kubernetes app to point to the service appsvcin your cluster.

For further details, refer to the Kubernetes Course.

Hope this helps!

Comments

Awesome Explanation!! Keep up your great work!!