You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
. This is not consistent with how MaxSurge works in other k8s entities such as Deployment, since in the latter the number of replicas can scale up while the redeployment is happening. Also, not being able to scale up the replica count during the rolling update implies that, if all the GameServers are in allocated mode, the RollingUpdate will not happen until at least one of the GameServers dies or transitions back into Ready state. In cases in which the users of Agones need to use the overflow event during the RollingUpdate to control the allocations based on certain labels, the allocations will constantly fail since the RollingUpdate is not capable of creating more replicas and the overflow event has been processed by the GameServers.
Adding a flag to allow scaling up the fleet replica count would not be a lot of work (since I guess we do not want to change the meaning of the RollingUpdate parameters for backwards compatibility reasons). That said, I'm not familiar enough with the codebase to understand the consequences of the the fleet replica count increasing above the specified count. This could also impact the FleetAutoscaler.
The text was updated successfully, but these errors were encountered:
'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '
Within the agones
Fleet
controller logic, we do not allow scaling the replica count above the specified amount of replicas. Seeagones/pkg/fleets/controller.go
Line 501 in 3e18f4f
MaxSurge
works in other k8s entities such asDeployment
, since in the latter the number of replicas can scale up while the redeployment is happening. Also, not being able to scale up the replica count during the rolling update implies that, if all theGameServer
s are in allocated mode, theRollingUpdate
will not happen until at least one of theGameServer
s dies or transitions back intoReady
state. In cases in which the users of Agones need to use theoverflow
event during theRollingUpdate
to control the allocations based on certain labels, the allocations will constantly fail since theRollingUpdate
is not capable of creating more replicas and theoverflow
event has been processed by theGameServer
s.Adding a flag to allow scaling up the fleet replica count would not be a lot of work (since I guess we do not want to change the meaning of the
RollingUpdate
parameters for backwards compatibility reasons). That said, I'm not familiar enough with the codebase to understand the consequences of the the fleet replica count increasing above the specified count. This could also impact theFleetAutoscaler
.The text was updated successfully, but these errors were encountered: