Flux: No info about rolling update process

[Alphapage]

Hello,

I can't find anything about the rolling update process in the document or any blog.
For example, I would like to know how flux handles container shutdown: is it possible to increase timeout before the container is killed ?

Also, how does flux tells the load balancer to stop routing request to the container being shutting down ?

Does flux use Kubernetes rolling update in the background ?

Thank you in advance for your help.

[geoah]

Flux doesn't deal with upgrade strategies, it will update your deployment and kubernetes will pick it up from there.

Start with the kubernetes deployment docs, but the tldr is something like:

spec: replicas: 5 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1

[Alphapage]

I think this feature is disturbing me:

https://github.com/weaveworks/flux/blob/master/site/introduction.md#automated-deployment-of-new-container-images

For example, if I deploy a redis version 3.8 with sentinels for high availability. When redis version 3.9 will be available flux will automatically update to the new version.
Do I have to specify a rolling update strategy as you tell in your previous post ?

Sorry for being confused about Automated deployment of new container images.

For example, wouldn't it be possible to have a git deployment managed by redis which will provide redis core install or update, and a local git which will manage parameters or values to customize my own deployment by merging both repositories ?

[squaremo]

For example, if I deploy a redis version 3.8 with sentinels for high availability. When redis version 3.9 will be available flux will automatically update to the new version.

If you tell it to by using fluxctl automate ..., yes.

This works by fluxd updating the YAML files in the git repo with the new image ref, then committing that change. Because fluxd is constantly applying new commits, the changed YAML is then applied.

Do I have to specify a rolling update strategy as you tell in your previous post ?

Yes; you specify it in the deployment YAML -- Kubernetes takes care of the rolling upgrade (if that's what you tell it to do). See https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy

For example, wouldn't it be possible to have a git deployment managed by redis which will provide redis core install or update, and a local git which will manage parameters or values to customize my own deployment by merging both repositories ?

I'm not sure what you mean here. Are you still talking about automated updates?