Life of a Packet in Kubernetes — Part 4

Nginx Controller and LoadBalancer/Proxy

An ingress controller is usually an application that runs as a pod in a Kubernetes cluster and configures a load balancer according to Ingress Resources. The load balancer can be a software load balancer running in the cluster or hardware or cloud load balancer running externally. Different load balancers require different ingress controllers.

Configuration Options

The Kubernetes Ingress Controller uses ingress classes to filter Kubernetes Ingress objects and other resources before converting them into configuration. This allows it to coexist with other ingress controllers and/or other deployments of the Kubernetes Ingress Controller in the same cluster: a Kubernetes Ingress Controller will only process configuration marked for its use.

Prefix Based

Host-Based

Host + Prefix

Deployment options

Contour + Envoy

The Contour Ingress controller is a collaboration between:

  • Envoy, which provides the high-performance reverse proxy.
  • Contour, which acts as a management server for Envoy and provides it with configuration

Nginx

The goal of the Nginx Ingress controller is the assembly of a configuration file (nginx.conf). The main implication of this requirement is the need to reload NGINX after any change in the configuration file. Though it is important to note that we don’t reload Nginx on changes that impact only an upstream configuration (i.e Endpoints change when you deploy your app). We use lua-nginx-module to achieve this.

Nginx + Keepalived — High Availablity Deployment

The keepalived daemon can be used to monitor services or systems and to automatically failover to standby if problems occur. We configure a floating IP address that can be moved between worker nodes. If a worker goes down, the floating IP will be moved to another worker automatically, allowing nginx to bind to a new IP address.

MetalLB —Nginx with LoadBalancer Service (For the private clusters with a small Public IP address pool)

MetalLB hooks into your Kubernetes cluster, and provides a network load-balancer implementation. In short, it allows you to create Kubernetes services of type “LoadBalancer” in clusters that don’t run on a cloud provider. In a cloud-enabled Kubernetes cluster, you request a load-balancer, and your cloud platform assigns an IP address to you. In a bare-metal cluster, MetalLB is responsible for that allocation. Once MetalLB has assigned an external IP address to a service, it needs to make the network beyond the cluster-aware that the IP “lives” in the cluster. MetalLB uses standard routing protocols to achieve this: ARP, NDP, or BGP.

  • controller is the cluster-wide MetalLB controller, in charge of IP assignment (deployment)
  • speaker is the per-node daemon that advertises services with assigned IPs using various advertising strategies (daemonset)

References

  1. https://kubernetes.io/docs/concepts/services-networking/ingress/
  2. https://www.nginx.com/products/nginx-ingress-controller/
  3. https://www.keepalived.org/
  4. https://www.envoyproxy.io/
  5. https://projectcontour.io/
  6. https://metallb.universe.tf/

Disclaimer

This article does not provide any technical advice or recommendation; if you feel so, it is my personal view, not the company I work for.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store