traefik-helm-chart
traefik-helm-chart copied to clipboard
traefik
Support for service annotation customization by port type
Use case
Assign private and public Load Balancer to distinct ports / entrypoints.
Current limitation
The current chart provides good support for dynamic entrypoint customizations through values.ports. Individual services will effectively be created in Kubernetes for each individual ports. The service annotations will however be shared from service.annotations values. As a result, there is no way to have specific annotations for distinct ports.
Proposed solution
~~Add a second layer of service annotations by adding a new ports.<port>.service.annotations property namespace. A template helper could merge both source and apply them at~~ https://github.com/traefik/traefik-helm-chart/blob/db26e8e834c43d06e17bd68102a4095476147b7d/traefik/templates/service.yaml#L26
I came to realize that my proposed solution will not work since I wrongly interpreted that the chart would create a distinct service per port definition. The only option left would be to have a new level of configuration with dynamic services (just like ports). I'll try to see if I can come up with something.
I'm planing to contribute that change unless someone jumps in with a different solution to support my use case.
I came to realize that my proposed solution will not work since I wrongly interpreted that the chart would create a distinct service per port definition.
Turns out the only option would be to have a new level of configuration with dynamic services (just like ports). I'll try to see if I can come up with something.
@SantoDE I'm facing a dilema. Either I run two distinct traefik instance with different service annotations or I break the configuration values of service.xxxx. Supporting multiple services with an opt-in services.xxxx values would add a new dimension of configuration. To avoid breaking existing deployment, the template helper would have to support both service.* and services.*.
ports.* values would also be ignored as they would be expected to be found in services.xxxxx.ports.*. What do you think of this?
