mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-09 05:25:14 +09:00
Aleksei Sviridkin
b4c66f2b55
Enabling TLS swaps the published metrics port: the operator exposes either prometheus:15692 or prometheus-tls:15691 and never both, deliberately, so a scrape config selecting every port does not count each node twice. That choice keys off TLS alone rather than off disableNonTLSListeners, so a ServiceMonitor selecting the port by the name prometheus stops matching once TLS is on, even though the broker keeps listening on 15692. Since tls.enabled inherits external, this reaches existing instances on upgrade with no user action. Re-adding 15692 through spec.override.service looks like the fix and is not. updatePorts keeps only port NAMES the operator owns and carries their NodePort across, so every reconcile drops the re-added entry; the override then reinstates it with nodePort unset, which the apiserver reads as "allocate" on a LoadBalancer. The resulting write retriggers the operator's own Service watch and the NodePort is reallocated each round. ClusterIP escapes it only because Update zeroes every NodePort there, leaving the patched spec equal to the live one — and external:true, the configuration that turns TLS on by default, is precisely the one that would loop. Trading a renamed metrics port for continuous LoadBalancer and kube-proxy reprogramming is not a trade worth making. So the chart renders no service override at all. The README says what changed and how to retarget a scrape config, including that 15691 is HTTPS under the release CA and so needs the trust anchor to verify, and the template comment records why neither direction of override is used. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <f@lex.la>