Reinstate sidekiq-cluster wrapper script

What does this MR do?

While we do not run more than 1 Sidekiq worker process, we are moving the metrics server out of the Sidekiq worker processes and into a separate process, which in turn is supervised by sidekiq-cluster, just like any other worker.

For reasons of simplicity across all types of GitLab deployment mechanisms, we therefore prefer start a single-worker "cluster" in k8s.

Resource use

This raises the question of additional memory and CPU use. We think it is negligible.

CPU

The sidekiq-cluster parent process, after successfully spawning a worker, mostly sleeps. It will wake up every 5 seconds to kill -0 the single worker to determine if it's still alive. If not, it will restart it and go back to sleep. Moreover, since it is a separate process, there is GVL contention at the VM level i.e. we're not competing with sidekiq worker thread time here.

Memory

There is a slight increase in pod memory use due to the extra Ruby process we run. I looked at this in a local k8s kind cluster, and sidekiq-cluster RSS was under 20MB:

Unfortunately very little can be shared with the sidekiq process we spawn.

While this isn't nothing, it is marginal compared to the 1GB+ a sidekiq worker consumes. We also pay for this extra memory in other envs such as Omnibus and from-source, where memory is more precious than in an HA environment where we scale via pods, but it does of course multiply with the number of pods, so this is something to keep in mind.

Related issues

• Issue: gitlab-org/gitlab#345139 (closed)
• Epic: gitlab-org&6409 (closed)

Test plan

1. Install GitLab chart with global.gitlabVersion set to this branch: helm upgrade gitlab . --set certmanager-issuer.email=me@somewhere.com --set global.gitlabVersion=mk-reinstate-sidekiq-cluster-wrapper
2. Shell into sidekiq container
3. Convince yourself that sidekiq-cluster is running, with a single sidekiq worker underneath it, e.g. via pgrep -af sidekiq or top (see above)

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion

Required

• Merge Request Title, and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Integration tests added to GitLab QA
• The impact any change in container size has should be evaluated