-
Notifications
You must be signed in to change notification settings - Fork 888
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NodePort value conflict between services #344
Comments
this is still the case and it's pretty inconvenient when trying to deploy vault in a HA setup with a static NodePort (for example to link vault using an existing load balancer in front) |
Agreed, I feel like this would be a very common practice for vault clusters. Anyone with a HA cluster in Kubernetes that also needs their company to access the UI via browser are stuck on vault-helm < |
Any update on this one? |
Just wondering - if one uses nodePort to access vault - the only service one should care about is vault-active isn't it? |
Hi @shayfisher , |
@pamiel |
Oh, yes sorry, my mistake !! This is a different value for this nodePort of the UI !! |
This doesn't work when deploying in HA mode since |
@mikearruda You are correct, this is why my PR picks a random port for the standby. |
I believe this was fixed in #610 |
Dear community,
On chart v0.6.0, when setting the
service.type
toNodePort
and specifying aservice.nodePort
value, then the following error is raised when trying to deploy using Helm:This is due to the fact that the single
service.nodePort
value is used in both thevault
(server-service.yaml
file),vault-active
(server-ha-active-service.yaml
file) andvault-standby
(server-ha-standby-service.yaml
file) services.We should rather have different
nodePort
values, one per service.Note that if
service.type
is set toNodePort
but noservice.nodePort
value is set, then things are working correctly and a random nodePort is allocated to each service.The text was updated successfully, but these errors were encountered: