-
|
I have a question about load balancing YARP itself. Our team is concerned about needing to restart YARP in production. One example is if/when we ever need to tie a new security policy to a route. We would need to create the new security policy (either in code or creatively build when configuring services from a custom appsettings section). The problem is when we would need to restart the YARP web for it to load the security policy. We don’t want the restart of our single YARP instance to affect users in production. We are wondering if can load balance YARP itself so we can stagger the restarting of each YARP instance. Are there any gotchas we should be aware of if we go with this? For example, does anybody see any issues with session affinity if YARP itself were balanced? Is there any risk that affinity keys might be duplicated between farmed instances? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Yes, it should work. You would need two affinity cookies with different names for each layer of proxying. You may also need to reconfigure the x-forwarded-* headers since they default to replace rather than append. You could also consider using an L4 (TCP) load balancer to re-route connections when one instance goes down. This wouldn't have as many configuration concerns. |
Beta Was this translation helpful? Give feedback.
-
|
Great, thank you for such a quick response! |
Beta Was this translation helpful? Give feedback.
Yes, it should work. You would need two affinity cookies with different names for each layer of proxying. You may also need to reconfigure the x-forwarded-* headers since they default to replace rather than append.
You could also consider using an L4 (TCP) load balancer to re-route connections when one instance goes down. This wouldn't have as many configuration concerns.