robintra/perf-sentinel chart-v0.10.0

perf-sentinel chart v0.10.0

on GitHub

What's new in chart-v0.10.0

One new template, off by default, and an appVersion move from 0.9.28 to 0.10.0. The Ingress is the first resource this chart renders that can publish the daemon beyond the cluster, so it ships disabled and says why. Everything under Behavior is what the new daemon image does differently once it rolls, and one of those things has a memory cost worth knowing before the rollout.

Added

• An optional Ingress, off by default because the API has no embedded IAM. ingress.enabled=true renders a networking.k8s.io/v1 Ingress in front of the Service, with className, per-controller annotations, hosts[].paths[] and tls[] passed through. servicePortName picks which published port the rules route to, otlp-http (4318: OTLP HTTP, query API, /metrics) by default or otlp-grpc (4317). Anything else fails the render rather than surfacing as a 503 at request time, since the Service publishes no other port. Off by default is a security decision rather than a packaging one: publishing the daemon exposes OTLP ingest, /api/findings with your SQL templates and endpoint names, and the ack write endpoints, to whoever reaches the host. helm install prints that warning when the Ingress is on. docs/HELM-DEPLOYMENT.md documents the two supported postures, internal-only where the boundary is the controller's own exposure plus the NetworkPolicy, and authenticated behind an SSO proxy once the host resolves beyond it.
• Enabling an Ingress does not relax the NetworkPolicy. With both on, the controller's pods must be allowed as a peer or every request times out with no useful error, because a NetworkPolicy denies silently. Allow the controller's namespace by the label Kubernetes sets on every namespace since 1.21, kubernetes.io/metadata.name, rather than by one the controller's own chart may or may not apply. The deployment guide carries the snippet and a way to confirm the peer is what is blocking.

Behavior

• The upgrade rolls the pods. The image tag falls back to .Chart.AppVersion when image.tag is empty, which is the default, so the pod spec moves from 0.9.28 to 0.10.0. The checksum/config annotation also changes, since the ConfigMap carries the chart version in its labels. Pinning image.tag explicitly keeps the old image and forgoes everything below.
• The daemon gains a second in-memory store, sized by [daemon] max_retained_traces (default 50). It keeps the masked span trees of the traces its retained findings point at, so a report exported from /api/export/report can still draw them. The cost scales with max_events_per_trace, which is why the default is small next to max_retained_findings. On a pod with a tight memory limit, size it deliberately or set it to 0. It is neutralised automatically, with a startup warning naming the cause, when api_enabled = false or max_retained_findings = 0, since only that one endpoint reads it. The value is exposed on /api/config and listed in perf-sentinel query monitor's Config tab.
• /api/export/report returns a larger body. The span trees ride in it, capped at half the shared client fetch limit so query monitor and the TUI keep working, but a scraper or a script that stores those snapshots should expect them to grow.
• A new bounded-cardinality metric. perf_sentinel_energy_backend_configured{backend} says which measured-energy backends are actually configured, which no existing gauge could express: every energy gauge is pre-registered at zero whether or not the backend exists, so a ServiceMonitor could not tell "not configured" from "configured and perfectly healthy". Five compile-time label values, published once at startup.
• Finding counts can drop on an OTLP ingest that emits blank statements. A span carrying db.statement with an empty value now counts as the instrumentation gap it always was, instead of producing an empty-template redundant_sql. If your collectors run a redacting layer that keeps the attribute, expect fewer findings and a matching rise in the filtered-span tally.
• No signature changes. No acknowledgment needs re-capturing, on either the TOML baseline or the daemon's runtime store. The per-window JSON the daemon archives stays byte-identical, so a disclosure content_hash computed under 0.9.28 still verifies.
• No other template, value or default moves. Rendering a values file with no ingress block gives you the same objects as 0.9.28 apart from the image tag, the chart version labels and the checksum they feed. Nothing about the Service, the probes, the ServiceMonitor, the PrometheusRule, the NetworkPolicy or the fragment mounts changes.

Install

The chart is published as an OCI artifact on GHCR, install it directly with no helm repo add step:

helm install perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.10.0

Upgrade an existing release:

helm upgrade perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.10.0

Verify that the rollout picked up the new image:

kubectl get pod -l app.kubernetes.io/name=perf-sentinel \
  -o jsonpath='{.items[*].spec.containers[*].image}'

Read docs/HELM-DEPLOYMENT.md for the sizing guidance, the Ingress postures and the NetworkPolicy peer an ingress controller needs.

Full Changelog: chart-v0.9.28...chart-v0.10.0