In this article, I will share my experiences with 3 major types of Kubernetes ingress solutions. Let’s go through their pros and cons and find out which one suits your needs. How does it work behind thescene?
First, Let’s deploy a hello-world service with 2 Pods running in demo namespace. Next, We apply the hello-world ingress resource file as below. Let’s take a look when an Ingress resource is deployed, how does the ingress controller translate it into Nginx configuration?For API path /api/hello-world, through an upstream directive as below, it will route incoming traffic to Service hello-world with 2 destination Pod IPs on container port 8080 in the namespace demo.
Pretty straightforward, right? It is very similar to our iptables or ipvs routing table. Nginx Ingress relies on a Classic Load Balancer(ELB)
Nginx ingress controller can be deployed anywhere, and when initialized in AWS, it will create a classic ELB to expose the Nginx Ingress controller behind a Service of Type=LoadBalancer. This may be an issue for some people since ELB is considered a legacy technology and AWS is recommending to migrate existing ELB to Network Load Balancer(NLB). However, under regular traffic volume, it never becomes a problem for us.
If NLB is preferred in your cluster, the good news is: it is supported since v1.10.0 as an ALPHA feature as below.
Source: itnext.io