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.

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

[bitnami/redis] Improve sentinel prestop hook to prevent service interruption #6080

Merged
merged 4 commits into from
Apr 23, 2021

Conversation

Gregy
Copy link
Contributor

@Gregy Gregy commented Apr 12, 2021

This improves on #5528 by checking and waiting until the failover is finished on both the redis and the sentinel container termination. This completely eliminates a momentary service interruption during rollouts that happens with just #5528 applied.

Benefits

This eliminates the few seconds of downtime that happen with v13.0.1 because the redis container terminates before the sentinel prestop hook finishes running (in k8s containers are being stopped concurrently)

I have also replaced a hard-coded masterSet config value in the prestop script with proper config reference. This problem was mentioned by @srueg in this comment: #5528 (comment)

Possible drawbacks

This code can make pod deletes (and rollouts) slower by a few seconds.

Applicable issues

Additional information

Checklist

  • Chart version bumped in Chart.yaml according to semver.
  • Variables are documented in the README.md
  • Title of the PR starts with chart name (e.g. [bitnami/chart])

Copy link
Contributor

@miguelaeh miguelaeh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much for the PR!
Please take a look at my comments

bitnami/redis/templates/configmap-scripts.yaml Outdated Show resolved Hide resolved
bitnami/redis/templates/configmap-scripts.yaml Outdated Show resolved Hide resolved
bitnami/redis/templates/configmap-scripts.yaml Outdated Show resolved Hide resolved
bitnami/redis/templates/configmap-scripts.yaml Outdated Show resolved Hide resolved
bitnami/redis/templates/configmap-scripts.yaml Outdated Show resolved Hide resolved
bitnami/redis/templates/configmap-scripts.yaml Outdated Show resolved Hide resolved
@Gregy
Copy link
Contributor Author

Gregy commented Apr 16, 2021

I have reworked the waiting logic to use retry_while instead of loops like you suggested @miguelaeh . Can you please check if the new approach is acceptable?

Copy link
Contributor

@miguelaeh miguelaeh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much for implementing the changes!

But if there is a way to get the current value of the termination grace period we could cap this process to that minus 5s or something like that. That would make sure we exit quickly enough even when someone changes the grace period (but I do not think this chart exposes the grace period as a variable to be changed)

About this, we could just add it. It is just needed to add it to the values.yaml, README.md and to the statefulset. Then you will be able to use it just like {{ .Values.terminationGracePeriodSeconds }}.
After that, the minor version must be bumped in a minor instead of a patch.

@Gregy
Copy link
Contributor Author

Gregy commented Apr 19, 2021

Thanks for the tip. Implemented.

@github-actions
Copy link

github-actions bot commented Apr 19, 2021

Great PR! Please pay attention to the following items before merging:

Files matching bitnami/*/values.yaml:

  • Is the PR adding a new container? Please reviewer, add it to the models (internal process)
  • Is the PR adding a new parameter? Please, ensure it’s documented in the README.md

This is an automatically generated QA checklist based on modified files

@Gregy
Copy link
Contributor Author

Gregy commented Apr 19, 2021

Another PR (#6146) containing the hard-coded masterset value fix has been merged. I will remove the first commit from this PR to resolve the conflicts. The rest of this PR should still get merged after successful review.

Copy link
Contributor

@juan131 juan131 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're doing a major refactoring of the chart at #6102
I will block this PR until the refactoring is completed.

@Gregy
Copy link
Contributor Author

Gregy commented Apr 19, 2021

Juan, could you please explain why a work on the next major version should prevent a bugfix PR like this from being merged? This PR doesn't bring any backward compatibility breaks and would be useful to people using v13 of this chart.

@juan131
Copy link
Contributor

juan131 commented Apr 20, 2021

Hi @Gregy

The major refactoring PR was merged, could you please rebase your branch from master and update the PR? Then, please pin me and I'll be glad to review it.

Thanks in advance.

@Gregy
Copy link
Contributor Author

Gregy commented Apr 20, 2021

Wow that was quick. Thanks for pinging me @juan131

Rebase done. Ready for review.

Copy link
Contributor

@juan131 juan131 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I won't have time to check this properly today
I'll check it tomorrow morning

Comment on lines 74 to 83
| Name | Description | Value |
|---------------------------------|----------------------------------------------------|-----------------|
| `kubeVersion` | Override Kubernetes version | `nil` |
| `nameOverride` | String to partially override common.names.fullname | `nil` |
| `fullnameOverride` | String to fully override common.names.fullname | `nil` |
| `commonLabels` | Labels to add to all deployed objects | `{}` |
| `commonAnnotations` | Annotations to add to all deployed objects | `{}` |
| `clusterDomain` | Kubernetes cluster domain name | `cluster.local` |
| `extraDeploy` | Array of extra objects to deploy with the release | `[]` |
| `terminationGracePeriodSeconds` | Define termination grace period for all pods | `30` |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we be able to define different grace periods depending on the component type?


Just curious, did you use readmenator to generate the tables automatically?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. The termination grace period is configured for the whole pod. Not the individual containers. We could theoreticaly make the setting seperate for sentinels, masters and replicas but if sentinels are used no masters and replicas are present and it doesn't make much sense to me to have a different grace period for master vs replica. So I am for keeping the setting global. But I can separate them if you wish.

No, I don't even have access to that repo. I have just modified the file with some help from a markdown table generator.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't make much sense to me to have a different grace period for master vs replica. So I am for keeping the setting global. But I can separate them if you wish.

I agree it's very unlikely you want to set a value for this setting on master nodes different from the one you set on replicas nodes. That said, it seems this is the approach we followed on other charts, and I'd follow it for consistency. See:

No, I don't even have access to that repo. I have just modified the file with some help from a markdown table generator.

Crap, i though this was already public. Sorry for the noise.

Copy link
Contributor Author

@Gregy Gregy Apr 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I have separated the configs.

This improves on bitnami#5528 by checking and waiting until the failover is
finished on both the redis and the sentinel container. This completely
eliminates momentary service interruption during rollouts.

As we cannot guarantee the failover will be successful the wait time
is capped by the termination grace period - 10s.
Comment on lines 74 to 83
| Name | Description | Value |
|---------------------------------|----------------------------------------------------|-----------------|
| `kubeVersion` | Override Kubernetes version | `nil` |
| `nameOverride` | String to partially override common.names.fullname | `nil` |
| `fullnameOverride` | String to fully override common.names.fullname | `nil` |
| `commonLabels` | Labels to add to all deployed objects | `{}` |
| `commonAnnotations` | Annotations to add to all deployed objects | `{}` |
| `clusterDomain` | Kubernetes cluster domain name | `cluster.local` |
| `extraDeploy` | Array of extra objects to deploy with the release | `[]` |
| `terminationGracePeriodSeconds` | Define termination grace period for all pods | `30` |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't make much sense to me to have a different grace period for master vs replica. So I am for keeping the setting global. But I can separate them if you wish.

I agree it's very unlikely you want to set a value for this setting on master nodes different from the one you set on replicas nodes. That said, it seems this is the approach we followed on other charts, and I'd follow it for consistency. See:

No, I don't even have access to that repo. I have just modified the file with some help from a markdown table generator.

Crap, i though this was already public. Sorry for the noise.

@Gregy Gregy requested a review from juan131 April 22, 2021 10:52
@Gregy
Copy link
Contributor Author

Gregy commented Apr 22, 2021

Ouch, thanks for catching that!

Copy link
Contributor

@miguelaeh miguelaeh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for all the changes @Gregy ,
LGTM!
We have to wait the internal CI to update the images tags

@bitnami-bot
Copy link
Contributor

I have just updated the bitnami images with the latest known immutable tags:

  • "docker.io/bitnami/redis:6.2.2-debian-10-r3"
  • "docker.io/bitnami/redis-exporter:1.22.0-debian-10-r0"
  • "docker.io/bitnami/redis-sentinel-exporter:1.7.1-debian-10-r122"
  • "docker.io/bitnami/redis-sentinel:6.2.2-debian-10-r2"
  • "docker.io/bitnami/bitnami-shell:10"
  • "docker.io/bitnami/bitnami-shell:10"

@bitnami-bot bitnami-bot merged commit 943c301 into bitnami:master Apr 23, 2021
@Gregy
Copy link
Contributor Author

Gregy commented Apr 26, 2021

Awesome. Thank you very much Miguelaeh.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants