Docs Fleet add section about RollingUpdate fields (#1228)

RollingUpdate is not working when replicas number is updated.

Co-authored-by: Mark Mandel <[email protected]>

site/content/en/docs/Getting Started/create-fleetautoscaler.md

@@ -256,8 +256,14 @@ simple-udp-mzhrl-zg9rq   Ready     10.30.64.99    7745    minikube     5m
 ```
 
 {{< alert title="Note" color="info">}}
-If you want to update a `Fleet`, which has `RollingUpdate` replacement strategy and is controlled by a `FleetAutoscaler`, you could omit `Replicas` parameter in a `Fleet` Spec.
-Otherwise fleet would be scaled according to Fleet `Replicas` parameter first and only after certain amount of time it would be rescaled to fit `FleetAutoscaler` `BufferSize` parameter.
+If you want to update a `Fleet` which has `RollingUpdate` replacement strategy and is controlled by a `FleetAutoscaler`:
+1. With `kubectl apply`: you should omit `replicas` parameter in a `Fleet` Spec before re-applying the `Fleet` configuration.
+1. With `kubectl edit`: you should not change the `replicas` parameter in the `Fleet` Spec when updating other field parameters.
+
+If you follow the rules above, then `maxSurge` and `maxUnavaiable` parameters will be used as the RollingUpdate strategy updates your Fleet.
+Otherwise the Fleet would be scaled according to Fleet `replicas` parameter first and only after certain amount of time it would be rescaled to fit `FleetAutoscaler` `BufferSize` parameter.
+
+You could also check the behaviour of the Fleet with Fleetautoscaler on a test `Fleet` to preview what would occur on your production environment.
 {{< /alert >}}
 
 ## Next Steps

site/content/en/docs/Guides/fleet-updates.md

@@ -26,12 +26,23 @@ much of the `Fleet` is  incremented and decremented at one time:
       maxUnavailable: 25%
 ```
 
-So when a Fleet is edited, either through `kubectl` `edit`/`apply` or via the Kubernetes API, this performs the following operations:
+So when a Fleet is edited (any field other than `replicas`, see note below), either through `kubectl` `edit`/`apply` or via the Kubernetes API, this performs the following operations:
 
 1. Adds the `maxSurge` number of `GameServers` to the Fleet.
 1. Shutdown the `maxUnavailable` number of `GameServers` in the Fleet, skipping `Allocated` `GameServers`.
 1. Repeat above steps until all the previous `GameServer` configurations have been `Shutdown` and deleted.
 
+{{< alert title="Note" color="info">}}
+When `Fleet` update contains only changes to the `replicas` parameter, then new GameServers will be created/deleted straight away,
+which means in that case `maxSurge` and `maxUnavailable` parameters for a RollingUpdate will not be used.
+The RollingUpdate strategy takes place when you update `spec` parameters other than `replicas`.
+
+If you are using a Fleet which is scaled by a FleetAutoscaler, [read the Fleetautoscaler guide]({{< relref "../Getting Started/create-fleetautoscaler.md#7-change-autoscaling-parameters" >}}) for more details on how RollingUpdates with FleetAutoscalers need to be implemented.
+
+You could also check the behaviour of the Fleet with a RollingUpdate strategy on a test `Fleet` to preview your upcoming updates.
+Use `kubectl describe fleet` to track scaling events in a Fleet.
+{{< /alert >}}
+
 ## Recreate Strategy
 
 This is an optimal `Fleet` update strategy if you want to replace all `GameServers` that are not `Allocated`
@@ -74,8 +85,8 @@ give preference to particular sets of `GameServers` over others. You can see det
 the `GameServerAllocation` [reference]({{< ref "/docs/Reference/gameserverallocation.md" >}}).
 
 In a scenario where a new `v2` version of a `Fleet` is being slowly scaled up in a separate Fleet from the previous `v1`
-Fleet, we can specify that we `prefer` allocation to occur from the `v2` fleet, and if none are available, fallback to
-the `v1` fleet, like so:
+Fleet, we can specify that we `prefer` allocation to occur from the `v2` Fleet, and if none are available, fallback to
+the `v1` Fleet, like so:
 
 ```yaml
 apiVersion: "allocation.agones.dev/v1"