Best Practice for Vector Hot-Reload in Kubernetes with ConfigMap-mounted Config?

[AdwaitKulkarni58]

Question

Hello!

I was wondering what the best practice is for Vector hot-reload in K8s with a ConfigMap-mounted config?

We are running Vector 0.53.0 in OpenShift/Kubernetes, with the config mounted from a ConfigMap. Trying to get hot-reload working without restarting the pod.

1. --watch-config (default inotify method) doesn't work here - ConfigMap volume updates replace the mount via a symlink swap (kubelet writes a new timestamped directory and swaps the ..data symlink), and Vector's inotify watcher is bound to the old inode, so it never fires.
2. We then switched to --watch-config-method poll with a 5s interval, which seems to work since it reloads the file path instead of watching the inode. A few things we couldn't find documented and wanted to check with the community:

• Is hot-reload even the recommended approach in Kubernetes, or is a rolling pod restart on config change the intended pattern? Curious whether the Vector team actually recommends live-reloading config in K8s environments, or whether restart-on-change (with proper readiness probes protecting against a bad rollout) is considered the safer/preferred default, given restarts get you a clean process start and full config re-validation from scratch.
• If hot-reload is recommended, is poll the right approach for K8s, or is there a better-supported pattern we are missing (/reload endpoint, or a sidecar)?
• If a reload is triggered with an invalid config, does Vector guarantee the previous topology keeps running untouched, or are there edge cases where a partially-valid config could apply? Trying to understand the actual reload-safety contract.
• Is there a metric that reflects a successful reload (not just reload_errors_total) on failure? Want to monitor reload health via Prometheus without tailing logs
• "vector validate" catches syntax errors and unknown component types, but not things like empty inputs. Does reload have the same blind spot?

Thank you!!

Vector Config

No response

Vector Logs

No response

[pront]

Hi @AdwaitKulkarni58,

--watch-config-method poll seems like an appropriate workaround when filesystem events are unreliable. There is no separate /reload endpoint; the watcher and SIGHUP use Vector’s normal reload path.

Invalid configs abort the reload. If building the new topology fails, Vector attempts to restore the previous one; if restoration fails, Vector exits rather than continuing in a partial state. For monitoring, reloaded_total records successful reloads. Failures are exposed through component_errors_total.

"vector validate" catches syntax errors and unknown component types, but not things like empty inputs. Does reload have the same blind spot?

This is unexpected. Can you provide the config and the validate command?

[AdwaitKulkarni58]

Hi!

Thanks for the reply and thanks for checking too - I was mistaken on my initial analysis. I hadn't verified the claim beforehand, just carried it forward as assumed knowledge from some testing I had done previously on a different matter. Ran some bad configs just now against Vector 0.53.0 via "vector validate":

Empty inputs:

sinks:
  bad_sink:
    type: "elasticsearch"
    inputs: []

-> Sink "bad_sink" has no inputs

Dangling input reference:

sinks:
  bad_sink:
    type: "blackhole"
    inputs: ["this_source_does_not_exist"]

-> Input "this_source_does_not_exist" for sink "bad_sink" doesn't match any components.

Both are caught cleanly. I was wrong - "vector validate" does not have the blind spot I described. Appreciate you asking me to check!!

[pront]

Thank you for checking and happy that validation works as expected!