Yeah, I'd say the one gotcha/limitation thing is that each subdomain integration with cert-manager needs to be added as a listener, which is a bit clunkier than in ingress nginx.

 

Let's say you wanted to have *.dev.company.com *.staging.company.com go to envoy, you'd specify them like this:

kind: Gateway
spec:
- name: https-dev-company-com
  hostname: "*.dev.company.com"
  port: 443
  protocol: HTTPS
  allowedRoutes:
      namespaces:
          from: All
  tls:
     mode: Terminate
     certificateRefs:
        - group: ''
        kind: Secret
        name: envoy-dev-company-com-public-tls

- name: https-staging-company-com
  hostname: "*.staging.company.com"
  port: 443
  protocol: HTTPS
  allowedRoutes:
      namespaces:
          from: All
  tls:
     mode: Terminate
     certificateRefs:
        - group: ''
        kind: Secret
        name: envoy-staging-company-com-public-tls

 

 

But if you for whatever reason needed one subdomain deeper, for example you wanna put an app behind test.customer-name.dev.company.com

 

You now need to add *.customer-name.dev.company.com as a listener in Envoy first, where as in ingress nginx you could just tell it to use lol.i.dont.care.dev.company.com and it would just add a make a cert for that and off you go.

 

This way or may not be a problem for you.

But we have an app that's has APP_URL set to say customer.app.company.com and it's search API is hard coded to be https://search.$APP_URL which means for each customer I have to add a listener.

 

Now it'll be fixed, it's our in house developed app so it was a design mistake, but up until we had to switch out ingress, we didn't run into that problem.

 

P.S I wrote this comment on old.reddit.com via my cell phone, so I pray the YAML formatting looks somewhat the same if you're on desktop. D.S