Skip to content

Commit

Permalink
Docs Fleet add section about RollingUpdate fields
Browse files Browse the repository at this point in the history
RollingUpdate is not working when replicas number is updated.
  • Loading branch information
aLekSer committed Dec 20, 2019
1 parent 1161b40 commit afaa2c1
Show file tree
Hide file tree
Showing 2 changed files with 23 additions and 3 deletions.
10 changes: 8 additions & 2 deletions site/content/en/docs/Getting Started/create-fleetautoscaler.md
Original file line number Diff line number Diff line change
Expand Up @@ -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 first apply of the `Fleet` configuration. Check that no replicas parameter defined in a file.
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
Expand Down
16 changes: 15 additions & 1 deletion site/content/en/docs/Guides/fleet-updates.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,12 +26,26 @@ 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`.

For the case when you want to be flexible on Fleet size, Fleetautoscaler and your prefer `kubectl apply` Fleet config with omitted `replicas` parameter should be used.
Do not change the `replicas` field manually when you use `kubectl edit fleet` for a fleet which is controlled by a Fleetautoscaler.

[Read Fleetautoscaler guide]({{< relref "../Getting Started/create-fleetautoscaler.md#7-change-autoscaling-parameters" >}}) for more details.

You could also check the behaviour of the Fleet with 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`
Expand Down

0 comments on commit afaa2c1

Please sign in to comment.