-
Notifications
You must be signed in to change notification settings - Fork 321
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
helm:support for sidecar containers & initContainers via extraContainers &extraInitContainers #682
Comments
I would like to chime in with my use case for sidecars. I am planning to use Vault PKI Secrets Engine (which does not depend on Consul) to generate unique TLS certificates for each Consul Server and agent. These certificates will be generated by Vault Agent (which will have Consul Template like rendering feature from Vault 1.3 cf. hashicorp/vault#7652). |
Hi there! It's been a while since this was filed so checking back in. @infa-bsurber and @lawliet89 it sounds like supporting extra init containers and extra containers would mainly help with TLS initialization for Consul K8s is that a fair statement? I assume @infa-bsurber that you are also utilizing Vault as well? |
Hey @david-yu. I am currently using the chart's auto TLS init for servers and auto encryption for clients, so my need for init containers to perform this has diminished. Also, Vault has a Kubernetes auto injector now too, so that use case can also be covered. |
Although we have not implemented support for extraInitContainers, we now have the ability to utilize extraContainers to deploy sidecars onto clients and servers: #749. I am closing now since this is a really old issue. Please file a new issue if extraContainers is still needed. Thank you! |
Right now there's no support for sidecar containers which forces certain processes to live outside of kubernetes, ie TLS cert initialization & refreshing.
The addition of a values extraContainers and extraInitContainers (matching the standard of stable helm charts) would ease this.
For the example of TLS certs, this would enable users to initialize and share certs via a shared emptyDir volume instead of being forced to persist certs in a (read-only from kubernetes jobs/containers) K8s Secret
The text was updated successfully, but these errors were encountered: