Documentation
¶
Overview ¶
Package crdwatch reinitializes the controller when the CustomResourceDefinitions backing watched resources change.
The effective config (which API version each watched resource is watched at, and which optional features are active) is resolved from apiserver discovery once per iteration. This component is what makes that resolution LIVE: it watches CRDs in the API groups referenced by the configuration and funnels relevant changes — installation, in-place upgrade that changes served versions, removal — into the existing config-reload iteration restart. Late installation of an optional resource's CRD activates its features, and an upgrade that retires the watched version re-resolves to a served one, all without a helm operation or pod restart.
This is operational plumbing for the controller's own watch set (see the operational-identity exception in the root CLAUDE.md) and is fully generic: the group filter and the reload decision are derived entirely from the configuration's candidate lists, never from built-in resource knowledge.
Index ¶
Constants ¶
const ComponentName = "crdwatch"
ComponentName identifies this component in logs.
const DefaultDebounce = 2 * time.Second
DefaultDebounce batches bursts of CRD changes (an install applies many CRDs in quick succession) into one reload decision.
const DefaultMaxErrorStreak = 6
DefaultMaxErrorStreak bounds CONSECUTIVE failed re-resolutions before the component escalates by triggering the reload anyway. A persistently failing resolution (e.g. a required resource's CRD genuinely removed) must not idle in the recheck loop forever with only warnings: escalating hands the fault to the iteration restart path, where resolution failure fails fast and surfaces through /healthz and the iteration retry loop. Transient discovery blips settle long before this bound (~30s at the default cadence) fires.
const DefaultRecheckInterval = 5 * time.Second
DefaultRecheckInterval is the cadence at which an inconclusive re-resolution (no change yet, or a transient error) is re-checked after a CRD event burst. The apiserver's discovery endpoint propagates a CRD apply asynchronously: a re-resolution racing that lag still sees the OLD state, and the CRD's later Established condition flip bumps no metadata.generation — so no further informer event ever arrives to break the stall. The recheck timer is what closes that window.
const DefaultStableChecks = 3
DefaultStableChecks is how many CONSECUTIVE equal re-resolutions (since the last observed CRD event) it takes before the watch accepts "no effective change" as final and goes quiet. Errored re-resolutions reset the streak — an error confirms nothing.
Variables ¶
This section is empty.
Functions ¶
func RelevantGroups ¶
func RelevantGroups(cfg *coreconfig.Config) map[string]bool
RelevantGroups extracts the set of non-core API groups referenced by any watched resource's candidate versions. Core-group resources ("v1") are never CRDs and are skipped.
Types ¶
type Component ¶
type Component struct {
// contains filtered or unexported fields
}
Component watches CRDs in the configured API groups and triggers a reload when a change would alter the effective config.
func New ¶
func New(k8sClient *client.Client, groups map[string]bool, shouldReload func() (bool, error), trigger func(), logger *slog.Logger) *Component
New creates the CRD watch component.
- groups: from RelevantGroups(rawConfig) — the RAW config, not the effective one, so groups of currently-unavailable optional resources are watched too (their CRD appearing is exactly the event we want).
- shouldReload / trigger: see field docs.
Source Files