consul-k8s
consul-k8s copied to clipboard
Setting External Server CONSUL_HTTP_ADDR
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
- Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
- If you are interested in working on this issue or have submitted a pull request, please leave a comment.
Is your feature request related to a problem? Please describe.
When using external server the CONSUL_HTTP_ADDR environment value cannot be set via the Values file, since the template uses instead the HOST_IP
{{- if .Values.client.enabled }}
- name: CONSUL_HTTP_ADDR
value: http://$(HOST_IP):8500
{{- else }}
- name: CONSUL_HTTP_ADDR
value: http://{{ template "consul.fullname" . }}-server:8500
{{- end }}
It would be useful to be able to set this value, when using externalServers, in this case our CONSUL_HTTP_ADDR will point to the external server.
When deploying the following Values file
global:
enabled: false
client:
enabled: false
externalServers:
enabled: true
hosts:
- '1.1.1.1'
syncCatalog:
enabled: true
k8sDenyNamespaces: ["kube-system", "kube-public"]
Feature Description
Enable CONSUL_HTTP_ADDR to be set via the Values file when externalServers are being used.
Use Case(s)
Catalog Sync feature. When it is deployed as the single feature of the helm chart, uses the host_ip:8500 value, but in this case there is no consul HTTP API running on the host.
Contributions
Let me know if this use case is accepted i can make the changes to the sync-catalog-deployment.yaml template.
I think we'll have to have a separate value for HTTP address for sync catalog:
syncCatalog:
consulAPIHTTPAddress: ""
Because externalServers.hosts
accepts a cloud auto-join string so we can't assume that we can use an element from that array.
Configuring CONSUL_HTTP_ADDR directly using Helm Values would be very useful for me too! I sync k8s workload with the external Consul cluster. And right now, I have to extract templates from Chart, do some manual changes (using Kustomize), and apply "raw" manifests to the cluster.
I've just found out the concept of Post Rendering. It looks doable to change CONSUL_HTTP_ADDR using kustomize before installing the chart to the cluster. I'll let you know if it works for my case. Despite that, configuring that via Values is much more straightforward.
Hi @gdud if you have a PR with some tests that run for what was described we'd be happy to take a look. We have not planned any enhancements to Sync Catalog in quite some time.
Anything new on this? Thanks
@psyhomb I think we're open to community PRs to implement this as per https://github.com/hashicorp/consul-k8s/issues/819#issuecomment-961652426
Closing as https://github.com/hashicorp/consul-k8s/pull/1659 should address this by leveraging a new component to discover servers and externalServers.hosts
will accept a DNS name starting with Consul K8s 1.0.
Hi @david-yu is there some place we can read what will change for 1.0 ? I understand from the code comments that there are some breaking changes expected that could perhaps help solve some of the issues we faced with the health checks and externalServers being used. In particular it seems that the service registration API has been now unified for all services.
We are currently using a custom component to overcome this and a few other issues we encountered with consul-k8s, perhaps we can re-evaluate using it, if 1.0 will fix most of the issues.
@webmutation There should be release notes for 1.0 on consul.io which will happen in the latter half of this month roughly. You can also see what's in the changelog to get a sneak peek. As far as health check support for catalog sync that is not supported at the moment. Do you have a PR that can show us how you enabled them?