Hacker News Reader

Comment by cmckn | Hacker News Reader

Ingress is still a bit of a mess, IMO. The reliance on annotations to ensure functionality with a specific ingress controller feels strange in the context of other k8s API objects. I understand why Ingress works this way, but it doesn't live up to the portability expectation. I know there is a "v2" coming for Services, and I'm hopeful that Ingress continues to get love. Networking in k8s is a big problem to solve :)

View on HN

Didn't IngressClass change that?

https://kubernetes.io/docs/concepts/services-networking/ingr...

I think the result is still mostly the same, just a bit more organized. That's definitely progress though, thanks for pointing it out!

The new Service APIs were supposed to solve it, but it's delayed I guess - https://kubernetes-sigs.github.io/service-apis/spec/

>"The reliance on annotations to ensure functionality with a specific ingress controller feels strange in the context of other k8s API objects. I understand why Ingress works this way, but it doesn't live up to the portability expectation."

I'm curious what are the reasons for the reliance on annotations for this object type?

The core Ingress object is super minimal, basically just "listen on ABC host+path and forward requests to XYZ service". But Ingress controllers can do all types of things, and might need more context to properly route the traffic. For example, you might want HTTP requests to be automatically upgraded to HTTPS. Or your ingress controller might need specific instructions if it's handling something like a gRPC connection. You might want one Ingress object handled by Traefik and another by nginx. These types of things have been addressed by adding annotations to the Ingress object. It's honestly a pretty elegant solution to a pretty hairy problem, but it ties your YAML to a specific cluster incarnation. Of course, if you use CRD's, you're in the same situation; but the dream of k8s is portability (for me).

Reply on news.ycombinator.com