As a frequent user of ingress, I agree that portability isn't useful in practice and that requirement is a hindrance on ingress evolution. A lot of work has been put into CRDs, yet parts of the community push for a "portable" ingress. With all the one-off features/settings, users will inevitably make substantial changes to their ingress object - might as well use CRDs with clear specs. The alternative is annotation hell or associated configmaps.
I've heard some say they want to be able to list out all external addresses exposed from the cluster, but that can be solved with a new resource more akin to endpoints.
At KubeCon Austin in December there was a lot of conversation about it. Some want portability, some want expressiveness, everyone agrees that current ingress isn't expressive enough.
In practice, everyone adds custom annotations one way or another (whether it's NGINX ingress, or Ambassador, or KongIngress). So at some level, the notion of Kube ingress is a moot point, since everyone has forked it :-).
Re:Kubernetes Ingress Controller for Kong
by smarterclayton on Tuesday May 08, 2018 @04:09PM
(#17024475)
I kind of agree. At this point it may just be better to write controllers that read generic policy from a different object and the base definition from the Kube object. But at that point, the extra ingress object is just a convenience.
> CDN toggle
Hmm, what would this do exactly?
Re:Kubernetes Ingress Controller for Kong
by lobster_johnson on Tuesday May 08, 2018 @03:31PM
(#17024029)
I'm referring to Cloud CDN [1], which is per-backend setting that is disabled by default.
Unlike some other offerings (like AWS CloudFront), the CDN is transparent and built into the GLBC. Just by turning on the CDN, your load balancer automatically gets a globally distributed cache.
My opinion is that ingress portability isn't really that useful in practice. You want implementation lock-in at the ingress level, since the implementation matters. If I need to target platforms in a generic way (e.g. make something that works on both AWS and GKE), I can use Helm or some other templating solution to generate the right manifests with the right settings.
So "KongIngress" isn't a problem for me, and rather than struggle with today's situation on GKE, I'd much rather have a "GoogleIngress" with all the GLBC bells and whistles (well, there aren't many, but at least timeouts and a CDN toggle!) and not care about it being portable.