Difference Between Kubernetes Ingress And Loadbalancer

Kubernetes is an enterprise-grade container orchestration technology. In many non-container contexts, load balancing is simple—for example, balancing across servers. However, load balancing across containers necessitates specialized management. The most fundamental kind of load balancing in Kubernetes is called load distribution. Implementing load distribution is simple at the dispatch level. The kube-proxy feature powers both of the load distribution techniques that Kubernetes offers. Kubernetes services make use of the virtual IPs that are maintained by the kube-proxy feature.

Kubernetes Ingress

Kubernetes Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource. An ingress is essentially a collection of rules sent to a controller that is listening for them. You can set up a plethora of ingress rules, but nothing will happen until you have a controller that can handle them. If set properly, a LoadBalancer service can listen for ingress rules.

Use Cases of Kubernetes Ingress

The most effective approach to get your services visible is most likely through ingress, but it may also be the most difficult. There are several varieties of ingress controllers, including Nginx, Contour, Istio, and the Google Cloud Load Balancer. Additionally, there are Ingress controller plugins like the cert manager that enable automated SSL certificate provisioning for your services. If you wish to offer several services under one IP address and they are all using the same L7 protocol (usually HTTP), then ingress is the most helpful option.

Example Of A Service With Kubernetes Ingress

apiVersion: networking.k8s.io/v1.5
kind: Ingress
metadata:
  name: ingress-example
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

Kubernetes Loadbalancer

Kubernetes load balancer uses the Kubernetes Endpoints API to track pod availability. When the Kubernetes load balancer gets a request for a specific Kubernetes service, it sorts or rounds robins the request among the service's relevant Kubernetes pods. They can work with your pods, provided they are externally routeable. Google and AWS both have this functionality built in.

In terms of Amazon, this corresponds precisely to ELB, and Kubernetes running on AWS can automatically launch and configure an ELB instance for each load balancer service deployed.

Use Cases Kubernetes Loadbalancer

This is the standard approach if you wish to expose a service directly. On the port you designate, the service will receive all incoming traffic. Filtering, routing, and other features are absent. It may therefore receive nearly any type of traffic, including HTTP, TCP, UDP, Websockets, gRPC, and so on.

However, the main drawback is that you have to pay for a load balancer for each exposed service, which may grow pricey! Every service you expose using a load balancer will receive its own IP address.

Example of a service with Kubernetes load balancer:

apiVersion: v1.5
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer

Difference Between kubernetes Ingress VS Loadbalancer