4 ms·

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 ot

by cmckn 6y ago

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 :)

bogomipz 6y ago
>"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?
- cmckn 6y ago
  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).
markdog12 6y ago
Didn't IngressClass change that? https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class https://kubernetes.io/docs/concepts/services-networking/ingr...
- cmckn 6y ago
  I think the result is still mostly the same, just a bit more organized. That's definitely progress though, thanks for pointing it out!
  - harpratap 6y ago
    The new Service APIs were supposed to solve it, but it's delayed I guess - https://kubernetes-sigs.github.io/service-apis/spec/ https://kubernetes-sigs.github.io/service-apis/spec/

by cmckn 6y ago

bogomipz 6y ago

>"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?

cmckn 6y ago
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).

markdog12 6y ago

Didn't IngressClass change that? https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class https://kubernetes.io/docs/concepts/services-networking/ingr...

cmckn 6y ago
I think the result is still mostly the same, just a bit more organized. That's definitely progress though, thanks for pointing it out!
- harpratap 6y ago
  The new Service APIs were supposed to solve it, but it's delayed I guess - https://kubernetes-sigs.github.io/service-apis/spec/ https://kubernetes-sigs.github.io/service-apis/spec/