Feature request: Support kubernetes "Ingress" based definitions
See original GitHub issuePlease 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
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:10 (5 by maintainers)
@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.
Question: given Ambassador now supports CRDs, what value does Ingress provide?