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 http://kubernetes.foo.bar/app to point to the service appsvcin your cluster.
Here is an example of how to implement a kubernetes cluster with an nginx ingress controller.
For further details, refer to the Kubernetes Course.
Hope this helps!