Topic outline

  • Ingress and Ingress Controllers

    Often we need to use an ingress object to provide path based or (sub-) domain based routing with TLS termination and other capabilities defined through annotations in the ingress resource.

    An ingress provides a mean to get an entry point to the services within a cluster, in other words an ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster, a service itself provides a cluster IP and does act as an internal LoadBalancer.

    An Ingress handles load balancing at Layer 7 and the Ingress Controller creates ingress objects which defines the routing rules for a particular application using a host, path or other rules to send traffic to service endpoints on to the Pods.

    Ingress is a separate declaration that does not depend on the Service type and with Ingress multiple Services and backends could be managed with a single load balancer ( → enjoy this article about Load Balancing and Reverse Proxying for Kubernetes Services).

    A service defined with the type LoadBalancer is exposed with an external IP to the outside of the cluster (in most cases to the internet), this IP is not bound to a physical interface and is usually handed out through a switch / router via DHCP.

    An Ingress without a load balancer service in the front is a Single Point of Failure, that’s why usually an ingress is combined with a Load Balancer in the front to provide High Availability with intelligent capabilities through the Ingress Controller such as path based or (sub-) domain based routing with TLS termination and other capabilities defined through annotations in the ingress resource.

    As already mentioned k3s comes with the Traefik Ingress Controller as the default Ingress Controller, which allows us to define an Ingress object for HTTP(S) traffic to be able to expose multiple services through a single IP.

    By creating an ingress for a service, the ingress controller will create a single entry-point to the defined service in the ingress resource on every node in the cluster.

    The ingress controller service itself on k3s is exposed with the type LoadBalancer by k3s traefik service load balancer implementation of k3s and it scans all ingress objects in the cluster and makes sure that the requested hostname or path is routed to the right service in our k8s cluster.

    With that said, k3s provides out-of-the-box ingress and in-cluster load balancing through built-in k8s services capabilities, since a service in k8s is an internal load balancer as well.

    Nice to know

    A k8s service provides internal load balancing capabilities to the end-points of a service (containers of a pod).

    An ingress provides an entry point to a service defined through the ingress definition to the out-side world of a cluster.

    A service defined with the type load balancer is exposed with an external IP and doesn’t provide any logic or rules for routing the client requests to a service.

    A load balancer implementation is up to us or the cloud service provider, on bare metal environments MetalLB is the (only?) software defined load balancer implementation which we can use.

    A MetalLB implementation without an ingress controller support doesn’t make sense in most cases, since MetalLB doesn’t provide any support to route client requests based on (sub-) domain name or path or provide TLS termination on the LB side out of the box.


    • Ingress with TLS

      In the follwoing we're using the traefik ingress controller and an ingress object to provide path based or (sub-) domain based routing with TLS termination with a valid mkcert made TLS certificate on our lab environment.

      ingress-controller-traefik.png

      The following works only on clusters which have a load balancer support.