Hi David,

On 18/03/2020 18:21, David Spitzer-Dulagan wrote:
> Hi,
> If this isn't the right place please let me know - after reading the
> "contributing" page that was linked in the readme of
> kubernetes-ingress I thought that this mailing list might be my best
> bet to ask for your input.
Thanks for you interest in the project.

This ML is the right place to contribute to the HAProxy software, but
for the ingress controller better do this by creating an issue in the
github project.

It isn't your fault anyway, we have updated the contribute/discussion
sections of the README in order to put clear information.

> I wanted to know if the following feature would be something you'd be
> interested in seeing in the official kubernetes-ingress controller:
> The ability to add an annotation to a pod that would translate into a
> weight in the backend wherever that pod is used.
We'd be interested to know more about the use case.

In a standard use case, pods are ephemeral and they are not expected to
carry specific information. Thus they can be easily replaceable,
scalable, etc

So typical questions:
- What kind of pods are these? static pods or created via Service ?
- How they are configured (annotation part in this case)?

So don't hesitate to give us more context about this in the github issue.

> Our company currently has the need for setting weights for specific
> pods and there is no way that I could find to achieve that with the
> current kubernetes-ingress controller.
> The implementation would be as follows:
>   * Cache all Pod objects and subscribe to changes on all namespaces
>     similar to the other observed k8s objects in the controller
>   * Extend EndpointIP in types.go to include the targetRef property of
>     the k8s object
>   * handleEndpointIP in controller.go would be extended to look up the
>     pod from the cache via the targetRef property and set the weight
>     if found
>   * Changes to the weight in the Pod would trigger a reload as well
> I've started working on a patch for kubernetes-ingress to implement
> that. I'd love your thoughts on this.
> David
The general idea makes sense, here are some notes:

- CachingĀ  pods objects, tracking them and syncing the corresponding
configuration is an important amount of work which for now seems to be
only useful for an edge case. That's why we would probably prefer having
CLI arg to activate this.
- No need for reload since we can set server weight via the Runtime API
(for example we do this already to change a server address via

My coworkers will probable have other thoughts to add once the github
issue is created.


Reply via email to