Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Rewrite translation of Ingress spec to Kong resources #241

Closed
hbagdi opened this issue Mar 8, 2019 · 5 comments
Closed

Rewrite translation of Ingress spec to Kong resources #241

hbagdi opened this issue Mar 8, 2019 · 5 comments
Assignees
@hbagdi
Labels
work in progress Work In Progress

Comments

@hbagdi
Copy link
Member

hbagdi commented Mar 8, 2019

Problem

Currently, Ingress Controller takes in all the Ingress rules and translates them into Server and Location blocks, very similar to how Nginx is configured. This is the case because this controller was forked from the nginx ingress controller and then updated to get it to work with Kong.

This results in a few problem

  • Kong is much more dynamic in nature and has different proxying capabilities than Nginx. Translating Ingress rules into Server, Upstream, Location block limits us in using all features of Kong, like method based routing (Routes with the same path but different methods are not being created #202)
  • Kong not only has proxying capabilities but lets you runs custom code in form of plugins, which can be configured on various routing levels. We run into problem when we store this meta into coarse Server and Location blocks.

Solution

Translate Ingress rules, along with associated KongIngress objects directly into Kong resources.
This can capture all Kong specific configuration properties and leverage Kong's declarative configuration capabilities.
This was referenced Mar 8, 2019
Closed
Closed
Closed
@hbagdi hbagdi self-assigned this Mar 27, 2019
@arbiter34 arbiter34 mentioned this issue Mar 29, 2019
Closed
hbagdi added a commit that referenced this issue Apr 1, 2019
@hbagdi
feat(*) refactor and simplify parsing of ingress rules to kong config
1c45744 
Breaking changes
-  KongIngress overrides for Service and Upstream will now be picked up
  from annotation on the service and not the route.

Changelog:
- Directly translate to Kong configuration objects
  Previously, the Ingress rules were parsed into Nginx Server and
  Location blocks, and then translated to Kong configuration. This was
  more complicated and information was lost during translation.
- Translation is now done to an intermediate Kong state and then further
  translated to the final format. The final format will differ, based on
  if Kong is running in a db or a db-less mode.
- Method based routes are now supported (#202)
- Default backend in Ingress rules is now respected and a default
  fallback route in Kong will be created if a default backend exists in
  one of the Ingress objects. If multiple Ingress objects have a default
  backed, the Ingress created first will be respected.

Fix #202
Fix #241
@hbagdi hbagdi mentioned this issue Apr 1, 2019
Merged
@hbagdi hbagdi added the work in progress Work In Progress label Apr 6, 2019
@eshepelyuk
Copy link

Is this issue released ? since I can see the corresponding PR is already closed

@hbagdi
Copy link
Member Author

hbagdi commented Apr 23, 2019

@eshepelyuk 0.4.0 release coming up soon (a few days) which will include these changes.

@eshepelyuk
Copy link

@hbagdi does this mean #244 will be closed too ?

@hbagdi
Copy link
Member Author

hbagdi commented Apr 23, 2019

@eshepelyuk Yes, the support for it is already landed in next branch.
There is a Docker image for the Ingress controller tagged 0.4.0-rc0 published if you would like to give it a go.

@eshepelyuk
Copy link

Thanks for reply, will wait until features will be closed :)

@hbagdi hbagdi closed this as completed in 09fb67c Apr 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hbagdi hbagdi

Labels
work in progress Work In Progress
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@eshepelyuk @hbagdi