VictoriaMetrics/operator v0.75.1

on GitHub

Dependency: vmoperator: Updated default versions for VM apps to v1.154.1.

Dependency: vmoperator: Updated default versions for VT apps to v0.12.0.

Dependency: vmoperator: Updated default version for VMAnomaly to v1.31.1.

FEATURE: vmuser, vmauth: allow VTAgent in targetRef.crd.kind, so vmauth can route to a VTAgent by name instead of a static URL. The CRDs must be updated to use it. See #2687.

FEATURE: vmanomaly, vmanomalyconfig: support the experimental peer_outlier model and its peer-group parameters in managed configuration, available since vmanomaly v1.31.0. See #2714.

FEATURE: vmcluster, vlcluster, vtcluster: with the default rollingUpdateStrategy: OnDelete, do not wait for storage pods listed in both maintenanceInsertNodeIDs and maintenanceSelectNodeIDs to become ready, and defer spec changes to these pods and their volumes until they leave maintenance. With RollingUpdate, Kubernetes still blocks pod updates while such a pod isn't ready. Previously, such a pod stuck Pending or Terminating (e.g. while its node is under maintenance and its volume is bound to that node) made every reconcile fail at the storage step, so changes to the insert and select components were not applied until the pod came back. See these docs and #2665.

BUGFIX: vmsingle, vmcluster, vlsingle, vlcluster, vtsingle, vtcluster: accept the months unit M in retentionPeriod and futureRetention. Previously, the CRD rejected values such as 3M, even though VictoriaMetrics, VictoriaLogs and VictoriaTraces accept them. The CRDs must be updated to get this fix. See #2693.

BUGFIX: vmanomaly: allow spec.configRawYaml and spec.configSecret without reader.queries when selected VMAnomalyConfig objects provide the queries. Previously, such a config failed reconciliation with reader.queries must be provided via configRawYaml or configSecret, so queries could not come from VMAnomalyConfig objects alone. A config with no queries from any source is still rejected. This bug was introduced in v0.69.0 with VMAnomalyConfig. See #2685.

BUGFIX: vmauth, vmuser: resolve each targetRef.crd reference with its own object. Previously, concurrent config builds for different VMAuth objects shared one object per kind, so a reference could resolve to another object of the same kind and url_prefix silently routed traffic to the wrong backend until the next reconcile. See #2690. Thanks to @lewis-treacy.

BUGFIX: vmauth, vmcluster, vlcluster, vtcluster: keep the replica count set by HPA when a Deployment or StatefulSet update is retried after a conflict. Previously, the retry used the replica count from the failed attempt, which could revert a newer value set by HPA. This bug was introduced in v0.73.0. See #2716.

BUGFIX: vmagent, vmsingle: respect spec.ignoreNamespaceSelectors. Previously, VMServiceScrape, VMPodScrape and VMProbe objects still discovered targets in the namespaces from their namespaceSelector, and any: true gave cluster-wide discovery. Targets outside the scrape object's own namespace are no longer discovered when the flag is set. This bug was introduced in v0.69.0, when scraping support was added to VMSingle. See #2684.

BUGFIX: vmuser: render tenant IDs explicitly set to 0 in spec.jwt.defaultVMAccessClaim. Previously, they were dropped from the generated vmauth config, so metricsAccountID: 0 rendered as the same default_vm_access_claim: {} as an empty object. Routing was not affected, since vmauth treats a missing ID as 0. This bug was introduced in v0.74.0, when defaultVMAccessClaim was added. See #2718.

BUGFIX: vmdistributed: fix reconcile of a VMDistributed with spec.license set and no spec.zoneCommon.vmsingle.spec. Previously, such objects failed to reconcile with a nil pointer error and their zones were neither created nor updated. This hit every licensed object with the default VMCluster backend. This bug was introduced in v0.73.0. See #2709 and #2712.

BUGFIX: vmdistributed, vldistributed: propagate spec.license to the VMSingle or VLSingle of each zone when spec.backendType is VMSingle or VLSingle. Previously, the license was copied into zoneCommon.vmcluster or zoneCommon.vlcluster instead, so every reconcile failed with backendType=VMSingle is incompatible with zoneCommon.vmcluster configuration (or its VLSingle variant) and no zone was created or updated. This bug was introduced in v0.73.0 for VMDistributed and in v0.74.0 for VLDistributed. See #2720.

BUGFIX: vmdistributed, vldistributed: stop forwarding the client Authorization header from the generated VMAuth to zone components. Previously, when a zone VMCluster or VLCluster had requestsLoadBalancer enabled, its vmauth treated the forwarded header as an invalid token. This could result in delays for every read request due to brute-force protection in vmauth v1.154.0. See VictoriaMetrics#11774 and #2742.

BUGFIX: vmalertmanager, vmcluster, vlcluster, vtcluster, vmagent, vlagent, vtagent, vmanomaly: fix reconcile failing when scaling up from 0 replicas. Previously, the operator could check PVCs before the StatefulSet controller had created them, so reconcile failed with got 0 pvcs, the object status was set to failed and a ReconciliationError event was emitted. The error went away on the next reconcile. This bug was introduced in v0.69.0. See #2694.

BUGFIX: vmalert: reload vmalert when the Secret referenced by spec.notifierConfigRef changes. Previously, the config-reloader did not watch the notifier config mount, so vmalert kept using the old notifier config until its pods were restarted. Pods with spec.notifierConfigRef will be rolled out once after the upgrade. See #2746.

BUGFIX: helm-converter: convert the victoria-metrics-alert chart's legacy values the same way the chart does: server.remote.read, server.remote.write, server.notifier.alertmanager, nested basicAuth/bearer auth keys and a list-valued server.notifier.url. Previously, they were silently dropped, so the generated VMAlert lost its remote storage, notifiers and credentials. Plaintext server.remoteWrite credentials, legacy or not, are now moved into a generated Secret like the other blocks; before, they were dropped too. The bug has existed since the converter was added in v0.69.0. See #2601.

BUGFIX: helm-converter: omit spec.notifier for the victoria-metrics-alert chart when no notifier URL is set. Previously, the converter generated spec.notifier: {}, which the operator webhook rejects, so the output could not be applied. The conversion now fails with an explicit error when the values contain alerting rules but no notifier, since the operator would silently ignore those rules, and when alertmanager.enabled: true would make the chart use its bundled Alertmanager, which has no CR equivalent. See #2601.

BUGFIX: helm-converter: convert the charts' license and global.license blocks into spec.license of VMSingle, VMCluster, VMAgent, VMAlert, VMAuth, VMAnomaly, VLCluster and VLAgent (from both victoria-logs-agent and victoria-logs-collector). Previously, they were dropped, so the generated CRs started without the enterprise license. The precedence matches the charts: a plaintext key (license.key, then global.license.key) wins over any Secret reference, which is taken from license.secret, global.license.secret, license.keyRef and global.license.keyRef, in that order. See #2601.