Commit's Chief Architect - formerly at Hootsuite - manages an open source project Zero (https://github.com/commitdev/zero). As part of regular maintenance, he was trying to make a switch to using Amazon Web Services’ Network Load Balancer from their “Classic” Elastic Load Balancer. NLB is billed as AWS’s next generation of load balancers. He was hoping for a better experience than he's had with ELB—although my experience with ELB has been mostly positive, as it tends to be fairly fast and stable. We’ve been using ELB with Kubernetes for quite some time, and he's fairly confident in how these technologies work together.
The goal was to be able to use Network Load Balancer stably as the load balancer on the edge of our infrastructure, sending traffic to an internal Elastic Kubernetes Service cluster running Nginx Ingress Controller. He wanted to be able to add and remove nodes, do a deploy rollout to the ingress controller without any disruption of traffic, and retain client IP information for logs and application functionality.
He found that in all three modes of operation—External Traffic Policy: Local, External Traffic Policy: Cluster, and NLB–IP—there were gotchas that would lead to traffic loss under not unrealistic conditions, such as nodes being added and removed and rollouts of the ingress controller. The ingress controller is a fairly stable piece of the setup and shouldn’t require many updates, restarts, etc., but he expects to be able to perform these operations when I need to, without any impact on users.
He wrote a piece about the planned transition, his blockers, and what he thinks stands in the way of broader adoption of Amazon Web Services’ Network Load Balancer.
Top comments (0)