current Ingress specification, what would that be? (90 responses) I am curious to learn if we can standardize all these annotations. If we are using them, why not graduate them. Especailly, I noticed there is a storageClass for PV&PVC which allows users to configure their backend storages, e.g. API parameters, Qos levels etc. Can we do the same for Ingress? We also need a way to configure our Ingress providers. And, a single ingress is not ALWAYS enough for a production cluster. Expose all underlying provide configuration Allow which protocol will be used in the upstream. For example to configure envoy with grpc-web. - Routing weights Make ingress more like a complete API gateway solution , with support for Auth, throttling, canary , etc Dynamic path segment routing with prefix replacement, e.g. it should be easy to configure `/api/<scv>/<resource>` for any set of services (matching `<svc>` segment), and strip URL path prefix leaving just the `/<resource>` segment. More authentication mechanisms Better overview with kubectl or dashboard. regex support in teh nginx ingress. make ingress class (which controller should handle this?) a first-class attribute Exponential traffic ramp-up during a deploy. Better debugging for when the controller does not respond or misdirects a request. Enrich regex path support. arbitrary (url)path rewrites I know it's not what ingresses are for, but defining TCP routing would be very helpful. In TCP mode any specified paths should be ignored, but what I would really want to have is port based routing. regex/wildcard for domain and path routing Proxy settings