The Kubernetes Ingress API is great for basic load balancing requirements, but over time I expect the industry to move on. Kubernetes Ingress objects will never become a universal abstraction for network load balancing.
The first warning signs came in the form of using annotations to represent complex load balancer configurations. People are attempting to abstract away complex Nginx configurations with a set of unstructured key/value pairs.
Why are people jamming all of this functionally into Kubernetes Ingress objects?
Because most load balancers lack the necessary APIs for end to end automation. Ingress controllers attempt to hide this fact. One exception being @envoyproxy.
Because most load balancers lack the necessary APIs for end to end automation. Ingress controllers attempt to hide this fact. One exception being @envoyproxy.
Some things are too complex to represent with a single YAML file. When it comes to load balancers the first point of integration should be syncing Kubernetes Pod endpoints with existing backend configurations. github.com/kelseyhightowe…
Istio, a control plane for @envoyproxy, has recently made a pivot away from Kubernetes Ingress objects and is now leveraging custom Gateway objects. istio.io/docs/concepts/…
Kubernetes Ingress objects provide a great day one experience, but as complexity grows, don't be afraid to think outside the YAML file.
