0

Have anybody ever tried to achieve GC HTTP(S) load balancer backend connection draining by either

  1. Setting the capacity of the respective instance groups inside the backend service to 0% (0 RPS)
  2. Removing the instance group(s) from the backend service
  3. Changing the backend service in the URL map to point to another backend service.

I would like to achieve A/B testing deployment with a GCLB in front of two GKE clusters. The docs only say connection draining is triggered for a specific instance when an instance is removed from the instance group (automatically or manually): https://cloud.google.com/load-balancing/docs/enabling-connection-draining

ebensom
  • 3
  • 2

1 Answers1

0

Those are very particular scenarios, however the expected behaviour is the following:

  1. Setting a max rate per instance or max rate (per instance group) to zero (when the balancing mode is rate), won't drain existing connections. Balancing mode simply helps the load balancer rank backends (instance groups in this situation) from most to least attractive to handle new connections. When the balancing mode is rate and the max RPS is zero, that just means that the backend is "not attractive" even when it is servicing zero requests. But if all backends have RPS set to zero, or if they don't but are near capacity, it's possible that a backend with RPS of zero is equally (as unattractive) as all the other backends.
  2. Removing the instance group as a backend from the backend service will most likely not respect any connection draining because that removes the load balancer from the equation.
  3. This scenario is pretty similar to the above statement, without the downside of removing the load balancer. However I think that pointing the URL map to different backend won't trigger connection draining since instances will be reachable, despite you are refering to a different backend. Downtime is expected, but draining shouldn't be activated.
Carlos Cuevas
  • 61
  • 2
  • In this case the best option to achieve "draining" seems to be setting the RPS capacity to 0% for instance groups belonging to one cluster while keeping the capacity on 100% with relatively high max RPS for the other cluster. – ebensom Jun 21 '19 at 06:30
  • Let's say yes. It is not a 'draining' action really, but the behaviour is close. Instance Groups that belongs to the cluster which capacity had been set to 0%, will be marked as 'not attractive', but they are all still 'active' and serving nothing. – Carlos Cuevas Jun 25 '19 at 14:50