Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

VMAuth: config-reloader host port conflict between multiple hostNetwork instances

Open
  • Is something wrong?
#2,766 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go, kubernetes
Domain
devops, infrastructure

Research direction

Start by tracing how VMAuth's config reloader arguments, container ports, probes, and Operator requests are generated; the issue identifies configReloaderExtraArgs and related behavior in #2584 but names no source files or tests. Check whether one configured listen port is applied consistently across those entry points, then add or update coverage for the generated Pod configuration. Done means distinct reloader ports work with host networking and automatic reloads.

Written by the indexing model from the issue text.

Description

Problem

We run two Operator-managed VMAuth instances on the same nodes with hostNetwork: true. Each instance selects a separate set of VMUser resources and uses a different application HTTP port.

The application ports are configured correctly, but the generated config-reloader sidecars both declare port 8435. The second VMAuth instance remains Pending because the scheduler reports unavailable host ports.

This is a real deployment issue related to #2584.

Versions

Observed container images:

  • VMAuth: victoriametrics/vmauth:v1.145.0
  • Config reloader: victoriametrics/operator:config-reloader-v0.72.0

The Operator controller version has not been independently confirmed.

Configuration

Both VMAuth instances target the same nodes, with separate matching VMUser resources.

apiVersion: operator.victoriametrics.com/v1beta1
kind: VMAuth
metadata:
  name: example-auth-a
  namespace: example-monitoring
spec:
  replicaCount: 1
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet
  nodeSelector:
    example.com/vmauth-test: "true"
  userSelector:
    matchLabels:
      example-auth: a
  port: "8427"
---
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMAuth
metadata:
  name: example-auth-b
  namespace: example-monitoring
spec:
  replicaCount: 1
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet
  nodeSelector:
    example.com/vmauth-test: "true"
  userSelector:
    matchLabels:
      example-auth: b
  port: "18428"

Observed behavior

In the affected deployment:

  • The second VMAuth container uses its configured application port.
  • The config-reloader's --reload-url points to the correct application port.
  • The config-reloader still declares container port and host port 8435.
  • Its liveness and readiness probes both target port 8435.
  • The Pod remains unscheduled.

config-reloader:
  Port:       8435/TCP (reloader-http)
  Host Port:  8435/TCP (reloader-http)
  Liveness:   http-get http://:8435/health
  Readiness:  http-get http://:8435/health

Scheduler event:
node(s) didn't have free ports for the requested pod ports


The shared reloader host port is the suspected conflict. The scheduler event itself does not identify the conflicting port.

## Expected behavior

We would like to configure a distinct reloader port for each VMAuth instance, for example:

```yaml
spec:
  configReloaderExtraArgs:
    http.listenAddr: ":18435"

The configured port should be used consistently for:

  • The reloader's actual listening address.
  • Container port declarations and resulting host ports.
  • Liveness and readiness probes.
  • Any Operator-side requests to the reloader.

Issue #2584 reports that changing the listen argument alone does not update all of these. We have not yet tested that override in the affected cluster.

Question

Is there a supported workaround that allows these VMAuth instances to share nodes with host networking while retaining VMUser-based configuration generation and automatic reloads?

We would prefer to preserve Operator-managed configuration rather than switch to externally maintained authentication configuration.

Dominant language
Go
Stars
595
Forks
242
Avg merge
1d 11h
Merged PRs (30d)
58

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from VictoriaMetrics/operator

All issues in VictoriaMetrics/operator

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.