feat(helm): Add health probes to bloom-gateway

[lindhe]

What this PR does / why we need it:

Adds configurable livenessProbe and startupProbe to the bloom-gateway container in the bloom-gateway pods.

Which issue(s) this PR fixes:

Partially addresses #13678

Special notes for your reviewer:

Partially replaces #15359

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• Title matches the required conventional commits format, see here
  • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[jkroepke]

CI:

Error from server (BadRequest): container "query-frontend" in pod "loki-oef3k0fujj-query-frontend-5665878895-5sgph" is waiting to start: ContainerCreating

[jkroepke]

The lines here are on each of your PRs. Keep in mind if one of them are merged, all other PRs will have a merge conflict then.

[lindhe]

Thanks for the heads-up. I intentionally based them all off of the same commit, to ensure there's no changes between them. I believe there will be no conflict since these are the exact same changes in each PR.

[lindhe]

In the changelog, on the other hand, there will be conflicts every time I fear. But no easy way around that, I think.

[lindhe]

CI:

Error from server (BadRequest): container "query-frontend" in pod "loki-oef3k0fujj-query-frontend-5665878895-5sgph" is waiting to start: ContainerCreating

Turns out that some components (at least templates/distributor/deployment-distributor.yaml) was already using .Values.loki.{livenessProbe,startupProbe} despite them being unset before. So when I introduced them and set them to {} by default, that broke the existing logic.

In commit abe8bc2 I set them to null instead of {}. That makes it backwards compatible, at the expense of not being so clear about the type of the fields. Do you prefer that, or should I instead set them to {} by default and instead try and hunt down all instances where they are used and change the templates to handle {} properly?

[jkroepke]

I personally would prefer {} by default. That indicate the type of the values as you already mentioned it.

[lindhe]

I think that's a good decision. But I also think that it belongs to a separate PR, since it refactors existing components rather than introduce new functionality.

I'll make a new PR for it, but just tell me if you much prefer it all to go here and I'll cherry-pick the relevant commits into this branch/PR instead.

[lindhe]

Created the new PR here: #18575

I'll rebase all other PRs once that has been merged.

[jkroepke]

I guess the CI will miss the new loki.startupProbe in the docs as well. or I'm wrong?

[lindhe]

I guess the CI will miss the new loki.startupProbe in the docs as well. or I'm wrong?

In README.md or in reference.md? How do I generate it?

[jkroepke]

No, CI is green. So LGTM.

[Jayclifford345]

LGTM