Prometheus High-Fanout Example

Generated at: 2026-07-30T12:38:02.000Z UTC · source: committed helm-expt evidence for this rendered repository document.

UNOFFICIAL/EXPERIMENTAL

prometheus-community/kube-prometheus-stack is a useful main-chart example because one Helm values choice changes a large operational surface.

Redis teaches the shortest happy path. NGINX is the simple web/live path. kube-prometheus-stack is the serious-chart proof path: it is popular, large, and full of the Helm behaviors that make production installs hard to reason about.

The catalog has two base variants:

Base	Use it when	What changes
`default`	This release should install the Prometheus Operator CRDs.	Renders 124 Helm objects, including 10 CRDs.
`no-crds`	The cluster already manages those CRDs elsewhere.	Renders 114 Helm objects and omits the 10 CRDs.

The important point is that no-crds still renders Prometheus custom resources. It only works when the target cluster already has the Prometheus Operator CRDs. That prerequisite is part of the deployable contract.

Why This Is The Serious Chart

Feature	Why it matters
Large object fanout	A small base choice affects more than 100 Kubernetes objects, so object-level review matters.
CRDs	The `default` base installs CRDs; the `no-crds` base requires the target cluster to provide them.
Custom resources	`no-crds` still renders Prometheus custom resources, so prerequisites must be checked before delivery.
Webhooks and controllers	Readiness and controller-populated state require live observation, not just render proof.
Cluster RBAC	Cluster-wide objects increase blast radius and need explicit scan/gate evidence.
Dependencies	Dependency locks matter because the umbrella chart contains many moving parts.
Generated facts and secrets	Generated material must be bound, externalized, or checked before the rendered object set is approved.
Extension slots	Raw snippets, rules, dashboards, or extra manifests can change the support boundary.
Lifecycle behavior	CRD upgrades, webhook readiness, and controller behavior need lifecycle routes and receipts.

The chart is valuable because it forces the model to separate the proof chain:

render parity
-> scan and gate
-> target prerequisites
-> delivery handoff
-> live observation
-> production support decision

It also shows the graph bridge. The chart now has a small value-source map for the two inputs users are most likely to ask about first:

Input	Output evidence
`grafana.adminPassword`	The Grafana admin Secret and the Deployment references that consume it.
`crds.enabled`	The 10 Prometheus Operator CRDs present in `default` and omitted from `no-crds`.

This is not a full inverse map for the whole chart. It is enough to show the model: important Helm choices should remain traceable after render.

User Flow

Choose the base:

kube-prometheus-stack/default
  install CRDs with the stack

kube-prometheus-stack/no-crds
  require CRDs to exist before delivery

Render one base:

New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.

What this command does. cub installer is a released, open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally. It does not apply those files to a cluster; use kubectl, Argo CD, or Flux for delivery. The generated scripts stop before doing any work when the plugin or kustomize is missing.

cub installer setup \
  --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:85.3.3 \
  --base no-crds \
  --work-dir .tmp/demo/kps-no-crds \
  --non-interactive \
  --namespace monitoring

Check the catalog and generated demo:

npm run high-fanout:verify

Read:

File	Shows
KPS catalog	The two bases, receipts, gates, and package links.
value source map	Which checked inputs currently map to rendered fields.
high-fanout summary	Object counts, removed CRDs, proof-chain status, the blocked prerequisite receipt, and the passing staged-prerequisite GitOps/OCI receipt.
operation preview	Pre-ship routing, blast-radius, guardrail, and next-proof view for mapped high-fanout inputs.
prometheus-kps.csv	Spreadsheet rows for the two bases, proof lanes, next hard work, and the base-to-base delta.

What The Current Evidence Says

default has render parity, local live evidence, and strict ConfigHub OCI/Argo evidence. no-crds has render parity, two-cluster parity, and strict ConfigHub OCI/Argo evidence when the target CRDs and admission Secret are staged.

The older blocked GitOps/OCI receipt is still useful. It shows the same base blocks when the target cluster does not have the required CRDs. Together, the blocked and passing receipts prove the real contract: no-crds is valid only when those prerequisites are supplied and observed.

Today this page proves the routing model and the high-fanout base difference. The default base also has a target-scoped support decision for the recorded vanilla kind, monitoring namespace, ConfigHub OCI, and Argo path. That is a narrow supported scope, not a claim that every kube-prometheus-stack topology, cluster, or values overlay is production-supported.

Production Support Checklist

The generated high-fanout summary has the current checklist. In short, production support for this chart is a target-scoped decision, not a blanket chart label.

Decision	`default`	`no-crds`
CRD ownership	The package owns the Prometheus Operator CRDs.	The target cluster owns compatible CRDs before apply.
Admission Secret	Stage or manage the webhook admission Secret before config-only delivery.	Stage the admission Secret and the external CRDs.
Webhook freshness	Observe webhook, operator, and caBundle readiness after apply.	Observe the same checks after CRDs are established.
RBAC and scrape scope	Approve the rendered cluster RBAC and monitoring blast radius.	Same RBAC family; external CRDs do not narrow scrape scope.
Scan and image posture	Accept findings for this infrastructure scope or create a hardened base.	Same, plus prerequisite evidence for external CRDs.
Final live evidence	Refresh target-scoped live parity, GitOps/OCI, and observation receipts.	Use the passing staged-prerequisite GitOps/OCI receipt as proof input, then record a target-scoped support decision for the chosen target.

Use default when the catalog package should own the CRDs. Use no-crds only when CRDs have their own owner, version, and fresh observation.

Current Production Proof Plan

The current target-scoped support decision covers the default base:

kube-prometheus-stack support decision

The generated human workdown is easier to use when assigning the remaining work:

kube-prometheus-stack production support workdown

The default base already has useful proof:

Boundary	Current status
Render parity	pass
ConfigHub proof	pass
Two-cluster kind parity	pass
Strict ConfigHub OCI/Argo live path	pass
Production support	supported for the declared target scope

To widen or refresh the default support scope, the remaining work is:

Choose the exact target scope: controller, namespace, cluster class, and OCI artifact digest.
Reuse the current mutable-image exception and security acceptance only if the new scope has the same posture; otherwise create a hardened or digest-pinned base.
Keep the selected hook/lifecycle route and live evidence fresh for the new scope.
Record a replacement support decision before calling the wider scope supported.

The no-crds base is a separate support decision. It now has both sides of the prerequisite story: one receipt blocks when required CRDs are absent, and one strict ConfigHub OCI/Argo receipt passes when compatible Prometheus Operator CRDs and the admission Secret are staged. The target-scoped support evidence is recorded in fresh-target-evidence-no-crds-2026-06-11.yaml. Production support for that base still needs a target-scoped decision for the chosen target.

Why This Matters

For high-fanout charts, a small Helm input can alter many Kubernetes objects and cluster prerequisites. ConfigHub should make that explicit:

base choice
-> rendered object set
-> prerequisites
-> scans and gates
-> delivery receipts
-> live observations

This is the same reason variants are more valuable than raw rendering. The user is not just asking "can Helm template this chart?" They are asking which deployable contract is safe for this target.