Skip to content

Allow scaleFromZero with a custom Envoy configuration - #90

Merged
kondratyevd merged 2 commits into
mainfrom
scale-from-zero-with-custom-envoy
Sep 8, 2026
Merged

kondratyevd merged 2 commits into
mainfrom
scale-from-zero-with-custom-envoy

Conversation

@kondratyevd

Copy link
Copy Markdown
Collaborator

Follow-up to #85: scaleFromZero.enabled no longer refuses to render together with envoy.external_config.load_from_configmap. A custom configuration is responsible for the clusters, Lua filter and routes that the generated one would have added; the chart does not check for them.

The Lua ConfigMap is now created for external configs as well, since the Envoy Deployment mounts it whenever the filter is enabled.

🤖 Generated with Claude Code

kondratyevd and others added 2 commits September 8, 2026 18:10
The chart no longer refuses scaleFromZero.enabled together with
envoy.external_config.load_from_configmap. A custom configuration is
responsible for the clusters, Lua filter and routes that the generated
one would have added.

The Lua ConfigMap is now created for external configs as well; the Envoy
Deployment mounts it whenever the filter is enabled, so without it the
pod could not start.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Prometheus Operator install floats on whatever
prometheus-community/kube-prometheus-stack is latest. 90.0.0, published
between 2026-09-05 and 2026-09-07, made the control-plane ServiceMonitors
authenticate via a Secret that is only rendered when prometheus.enabled
and prometheus.serviceAccount.create are both true. These call sites pass
prometheus.enabled=false -- they want the operator and its CRDs, nothing
else -- so templating now fails:

  The control-plane ServiceMonitors authenticate by default with the
  Secret created by prometheus.serviceAccount.createTokenSecret, which is
  only rendered when prometheus.enabled and prometheus.serviceAccount.create
  are also true.

Bisected: 89.2.4 and every earlier release template fine with these
flags; 90.0.0 is the first that does not. Pinning 89.2.4 keeps CI
reproducible and matches how the chart's own dependencies are pinned.
89.2.4 still ships the servicemonitors CRD and the operator Deployment,
which is all these steps need.

The alternative -- tracking latest and disabling every control-plane
exporter (kubelet, kubeApiServer, kubeControllerManager, kubeScheduler,
kubeProxy, kubeEtcd, coreDns) -- also works on 90.0.0 but adds seven
flags to each call site and would not protect against the next upstream
change.

This break is independent of this branch: it fails identically on main,
which has not run CI since 90.0.0 was published.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(cherry picked from commit 444bdc3)
@kondratyevd
kondratyevd merged commit fb6c526 into main Sep 8, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant