Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Docs Fleet add section about RollingUpdate fields #1228

Merged
merged 2 commits into from
Jan 9, 2020
Merged

Docs Fleet add section about RollingUpdate fields #1228

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8c81cbb
Docs Fleet add section about RollingUpdate fields
aLekSer Dec 11, 2019
cd6d354
Merge branch 'master' into fix/rollingupdate
markmandel Jan 9, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 8 additions & 2 deletions site/content/en/docs/Getting Started/create-fleetautoscaler.md
View file
Open in desktop
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 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
Expand Down
17 changes: 14 additions & 3 deletions site/content/en/docs/Guides/fleet-updates.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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`
Expand Down Expand Up @@ -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"
Expand Down