Render sourcegraph.labels on every object, and add storage and ServiceAccount labels - #1008

Services, ConfigMaps, Secrets, the Ingress, PodDisruptionBudgets,
PriorityClasses, and extraResources of the sourcegraph chart did not render
sourcegraph.labels. Neither did any object of the sourcegraph-executor-k8s
chart, nor the docker-config ConfigMap and private-docker-registry Service of
the sourcegraph-executor-dind chart.

Prometheus copies Service labels to the metrics it scrapes, so its bundled
configuration now drops the chart's standard labels: helm.sh/chart and
app.kubernetes.io/version change on every upgrade.

Each chart gets a test that renders every template and checks the labels, so
a template added later is covered too.

Amp-Thread-ID: https://ampcode.com/threads/T-c7c725c9-ed68-48e2-9f2d-0b8c31e76050
Co-authored-by: Amp <amp@ampcode.com>

The redis-store ServiceAccount was the only one that did not include the
annotations helper, so redisStore.serviceAccount.annotations was silently
dropped.

Amp-Thread-ID: https://ampcode.com/threads/T-c7c725c9-ed68-48e2-9f2d-0b8c31e76050
Co-authored-by: Amp <amp@ampcode.com>

PodDisruptionBudgets, PriorityClasses, the StorageClass, the test Pod, and
the k8s executor Secret now have deploy and app.kubernetes.io/component
labels, and the jaeger objects have app.kubernetes.io/instance.
<serviceName>.labels and executor.labels are also rendered on a component's
ConfigMaps, Secrets, and PodDisruptionBudget. Adds storageClass.labels,
priorityClasses[].labels, and privateDockerRegistry.serviceLabels (dind).

Amp-Thread-ID: https://ampcode.com/threads/T-c7c725c9-ed68-48e2-9f2d-0b8c31e76050
Co-authored-by: Amp <amp@ampcode.com>

…ice with its app

The bundled Prometheus copies Service labels to the metrics it scrapes. Now
that every Service has sourcegraph.labels, the labeldrop rule also drops
those keys, so the labels of Service-scraped metrics stay as they are on main.

The rule no longer drops app.kubernetes.io/managed-by: Helm adds that label
to every object it installs, so the metrics already had it.

The otel-collector Service had no app label, unlike every other scraped
Service, so its metrics had no app and job labels and the dashboard's
up{app=~".*otel-collector"} panel and alert had no data.

Amp-Thread-ID: https://ampcode.com/threads/T-c7c725c9-ed68-48e2-9f2d-0b8c31e76050
Co-authored-by: Amp <amp@ampcode.com>

The image's logging.yaml, and the ConfigMap the chart renders for custom
exporters, left the collector's metrics on 127.0.0.1:8888, where Prometheus
cannot scrape them. With the app label the Service gained, up was 0 and the
pods available alert fired instead of showing no data.

Pass the telemetry readers setting as a second --config to the default
command, and add it to the rendered ConfigMap. jaeger.yaml already has it.

Amp-Thread-ID: https://ampcode.com/threads/T-c7c725c9-ed68-48e2-9f2d-0b8c31e76050
Co-authored-by: Amp <amp@ampcode.com>

…rics to be scraped

openTelemetry.gateway.command replaces the default command, so it does not get
the argument that serves the collector's metrics on all interfaces.

Amp-Thread-ID: https://ampcode.com/threads/T-c7c725c9-ed68-48e2-9f2d-0b8c31e76050
Co-authored-by: Amp <amp@ampcode.com>

Pod templates now get `sourcegraph.labels`, the chart's standard labels,
and `app.kubernetes.io/component`, as every other object does. One helper,
`sourcegraph.podLabels`, merges them with `sourcegraph.podLabels`, the
component's `podLabels`, and the selector labels, so each key is rendered
once and a selector label always wins.

The Prometheus `labeldrop` rule now also drops
`app.kubernetes.io/managed-by` and also applies to the `kubernetes-pods`
job, so Helm and `helm template | kubectl apply` installs get the same
metric labels. No bundled dashboard or alert queries the dropped labels.

The changelog no longer asks for a manual Prometheus restart: the
`checksum/prometheus-config` annotation restarts it.

Amp-Thread-ID: https://ampcode.com/threads/T-01a1cc03-93a7-7445-8f1f-3dd7123272bf
Co-authored-by: Amp <amp@ampcode.com>

The setting that serves the collector's own metrics on all interfaces was
part of the default command, so a command set in
`openTelemetry.gateway.command` did not get it, and Prometheus could not
scrape the collector. It is now always the last container argument, after
`openTelemetry.gateway.args`, so a replacement command gets it too. Last,
so that it is `$0` of a `sh -c` command whose script is the first argument.

Amp-Thread-ID: https://ampcode.com/threads/T-01a1cc03-93a7-7445-8f1f-3dd7123272bf
Co-authored-by: Amp <amp@ampcode.com>

The collector does not reload a changed ConfigMap by itself, so a change to openTelemetry.gateway.config.traces took effect only at the pod's next restart. The pod template now has a checksum/otel-collector-config annotation over those values, which are all the ConfigMap's data is rendered from. It is set only when the chart renders the ConfigMap, so the default install does not change.

Amp-Thread-ID: https://ampcode.com/threads/T-01a1cc03-93a7-7445-8f1f-3dd7123272bf
Co-authored-by: Amp <amp@ampcode.com>

helm.sh/chart and app.kubernetes.io/version change with every chart version. As pod labels they changed every pod template, so every pod restarted whenever the chart version changed, even when nothing else did. On main no pod template depends on the chart version.

Pod templates in all four charts now get the common labels without these two. The other objects keep them.

This also updates the pod label snapshots of the selector labels golden test: every pod gains app.kubernetes.io/managed-by and app.kubernetes.io/component, and no selector, volume claim template, or existing pod label changes.

Amp-Thread-ID: https://ampcode.com/threads/T-01a1cc03-93a7-7445-8f1f-3dd7123272bf
Co-authored-by: Amp <amp@ampcode.com>

The jaeger pod's prometheus.io/port annotation named port 16686, the
query UI, which has no /metrics, so the scrape target was down. Jaeger
v2 serves its own metrics on localhost:8888 unless its configuration
says otherwise.

The chart's Jaeger configuration now serves them on all interfaces,
port 8888, as Jaeger's own all-in-one configuration does, and the
annotation names that port.

Amp-Thread-ID: https://ampcode.com/threads/T-01a1cc03-93a7-7445-8f1f-3dd7123272bf
Co-authored-by: Amp <amp@ampcode.com>

…does

#1016 deletes the executor-<queueName>
Service, which fronts a port the executor has not served since 4.1, and
the kubernetes-services scrape job, which probes through a blackbox
exporter the chart does not ship. Making the same deletions here keeps
this PR and #1016 from conflicting in those files.

Amp-Thread-ID: https://ampcode.com/threads/T-01a1d269-2788-7075-b66b-b87e3087047d
Co-authored-by: Amp <amp@ampcode.com>

This replaces 4dc65cf, which served Jaeger's metrics on 0.0.0.0:8888 and
pointed the pod's prometheus.io/port annotation there.
#1016 removes the scrape annotations
instead: they pointed at port 16686, which has no /metrics, and Jaeger's
own otelcol_* metrics would otherwise mix into the OpenTelemetry Collector
dashboards. Making the same change here keeps this PR and #1016 from
conflicting in the Jaeger Deployment and the README.

Amp-Thread-ID: https://ampcode.com/threads/T-01a1d269-2788-7075-b66b-b87e3087047d
Co-authored-by: Amp <amp@ampcode.com>