Ingress to Mapping "best effort" conversion tooling
See original GitHub issuePlease describe your use case / problem.
I have several large clusters and dozens of applications (deployed with Helm) where Ingress
is heavily used and Traefik is the default ingress controller.
I would like to convert these clusters and their applications to Ambassador as the default to leverage the speed improvements of Envoy and utilize the Mapping
API for its robustness.
I need to minimize the upfront time it takes to migrate my apps and clusters and automate as much of the process as possible so that I can easily do this for my existing apps and any future apps I inherit.
Describe the solution you’d like
Right now I’m considering that a ingress to mapping conversion tool in the form of a Go library and accompanying CLI could be a good fit.
Since Mapping
is very different from Ingress
and exists because Ingress doesn’t have the same features it’s understood that inherently not all Ingress resources will actually convert cleanly to Mapping
. It is understood that this tool would be “best effort” and may either need to be flagged to allow for imperfect conversions and/or error out when the conversion can’t be done cleanly.
This would be helpful for automating the procedure and adding tests to cover converted apps.
Describe alternatives you’ve considered
I’ve considered doing the conversion by hand which wouldn’t be a big deal except that I expect to receive more apps and have to repeat this process continually over the coming years.
Additional context
At the time of writing this originally I’m not sure this is the best approach, I’m very open to alternative suggestions.
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (7 by maintainers)
Top GitHub Comments
@shaneutt Since you mention Traefik, one challenge that you might have to face is converting those annotations to proper
mapping
configuration@shaneutt, One thing I’ve discovered with Ingresses is that they are very namespace-restrictive. I think any kind of conversion tool should make sure that all generated config remains in and references the same namespace that the Ingress is set to be part of to make sure the resulting config exactly mimics the behavior of the Ingress.
Another thing is that I believe Ambassador already translates Ingress to Mapping+Host internally, so I think that type of code exists somewhere, @kflynn will probably be able to give you better guidance on where that code lives though.