Ambassador: Feature request: Support kubernetes "Ingress" based definitions

[bitsofinfo]

Please describe your use case / problem.

Currently evaluating Ingress Controllers for k8 and Ambassador is often listed as a solution for this kind of thing alongside other implementations. (i.e. https://kubedex.com/ingress/)

When coming around to eval Ambassador after having tried a few others (i.e k8 ingress-nginx, Traefik etc). I noticed the biggest difference is that Ambassador is not configurable via (i.e does not consume/react to) k8 Ingress components like others but instead annotations on k8 Service objects.

It does not seem that far of a reach for Ambassador to also be able to consume configuration defined by a k8 Ingress

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

Describe the solution you'd like

Currently I define my mappings for Ambassador in an app's Service def like below.

apiVersion: v1
kind: Service
metadata:
  namespace: my-apps
  name: my-app-4-1-3-1--1-3
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind:  Mapping
      name:  my_app_mapping
      host: "^my-app-stage.local(:{1}\\d+)*$"
      host_regex: true
      prefix: /
      timeout_ms: 60000
      service: https://my-app-4-1-3-1--1-3:30000
spec:
  selector:
    app: my-app
    version: 4-1-3-1--1-3
    env: stage
  type: NodePort
  ports:
  - protocol: TCP
    port: 30000
    targetPort: app-port
    nodePort: 30000

Note the TLS certificate presented for the above "host" mapping currently has to be defined
in the Ambassador Deployment config...

...
---
apiVersion: ambassador/v1
kind: Module
name: tls
config:
  server:
    enabled: True
    secret: my-app-tls-cert
...

It would be nice to be able to alternatively define all of this configuration
in the standard kubernetes Ingress way of doing things, that still supports
annotations but is a bit more portable across "ingress" controller/gateway
implementations:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  namespace: my-apps
  name: my-app-ingress-1
  annotations:
    kubernetes.io/ingress.class: "ambassador"
    ingress.kubernetes.io/protocol: "https"
spec:
  tls:
  - hosts:
    - my-app-stage.local
    secretName: my-app-tls-cert
  rules:
  - host: my-app-stage.local
    http:
      paths:
      - backend:
          serviceName: my-app-4-1-3-1--1-3
          servicePort: 30000

For instance in the above, despite that kubernetes.io/ingress.class is optional,
you could change this to "ambassador", "traefik" or "nginx" and use this same exact config across
different providers.

Describe alternatives you've considered

Obviously the Service based annotations method works fine, I'm just advocating supporting Ingress abstraction might aid people hot swapping out their "Ingress" implementation in k8.

Additional context

https://datawire-oss.slack.com/archives/CAULN7S76/p1553277231024800?thread_ts=1553262170.995000&cid=CAULN7S76

[bitsofinfo]

Oh.. looks like you've already decided on this: https://blog.getambassador.io/takeways-from-the-2018-kubernetes-ingress-survey-baef2cc4afe3

[richarddli]

The problem is how to handle the full range of annotations that Ambassador has; Traefik and NGINX etc all extend the ingress spec anyway so if you're doing it for "real" workloads it's unlikely you're going to get portability. I agree for eval it might be somewhat convenient if you're literally comparing the exact same config side-by-side but in the real-world you need stuff like CORS, SNI, protocol config, rate limits, adding/removing HTTP headers, etc.

[bitsofinfo]

Yeah the usage of annotations on these definitely seems to be negating the "portability" of these definitions. Regardless, for simple setups I think it is still applicable. For one, being able to define the TLS cert along side the ingress and host mapping that needs it, rather than across two different configs is a plus.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bitsofinfo]

not stale

[kflynn]

We should also look at bugs on the default Ingress controller to see if we can fix some of those as we do this.

[flands]

Question: given Ambassador now supports CRDs, what value does Ingress provide?

[concaf]

@flands it's a good thing that Ambassador can read Kubernetes Ingress resources and configure itself without any extra configuration - making it an Ingress Controller. This makes it easier to evaluate Ambassador against other Ingress Controllers. Also, certain integrations with Ambassador configure themselves using Kubernetes Ingress resources as well, so this will help in that area as well.

[concaf]

Vanilla Ingress resources are now supported in #1836

[seh]

Question: given Ambassador now supports CRDs, what value does Ingress provide?

DNS records via External DNS (per #1057).