Skip to content
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

feat(platforms): Add helm chart for Vector installation #2232

Closed
wants to merge 2 commits into from

Conversation

alexgavrisco
Copy link
Contributor

This PR adds a helm chart for Vector installation in a K8S cluster.
It's inspired from other similar community helm charts and some ideas are taken from #1900

IMO a community helm chart must support 2 major use cases:

  • It should have quite reasonable defaults and allow flexible configuration via --set arguments (or a values file);
  • It should allow providing entirely custom configuration (e.g. a configmap created separately of this helm chart) - thus allowing such patterns as "umbrella" deployment with highly specific configuration;

This is why in this helm chart the only source enabled by default (and exposed as separate entity in the sources object) is the kubernetes source. All other components can be easily configuring without coupling helm chart to some specific transforms/sinks.

@alexgavrisco alexgavrisco requested a review from a user April 5, 2020 19:36
Signed-off-by: Alex Gavrisco <[email protected]>
@alexgavrisco
Copy link
Contributor Author

Hey @Hoverbear @binarylogic
As a result of discussion on #1900, I've checked that PR, some Vector use-cases (including our current setup) and created this helm chart.
It's flexible enough so I've been able to use it as drop-in replacement for our current Vector installation. And I've tested it with both helm2 and helm3, however only in AWS EKS flavor of Kubernetes.
Please let me know it this approach to the helm chart makes sense to you.

@binarylogic binarylogic requested review from LucioFranco and MOZGIII and removed request for a user April 5, 2020 21:38
@binarylogic
Copy link
Contributor

Thanks @Alexx-G! It's likely we'll want to finalize #2222 before merging this. This way we'll have consensus on our approach and can review it with that context. Also, feel free to weigh in on that RFC as we update it.

@alexgavrisco
Copy link
Contributor Author

This totally makes sense. I'll take a look at the RFC, thanks!

@MOZGIII
Copy link
Contributor

MOZGIII commented May 7, 2020

Hey! I just wanted to let you know I didn't forget about this PR. This looks great, and soon I'll finally get to reviewing it. We'll likely adopt it after some minor changes to conform to the RFC and our updated YAML configs.

---
{{- if .Values.rbac.psp.enabled }}
apiVersion: {{ default (include "psp.apiVersion" .) .Values.rbac.psp.apiVersion }}
kind: PodSecurityPolicy
Copy link
Contributor

@MOZGIII MOZGIII May 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nit: PodSecurityPolicy isn't really a part of RBAC, it should probably be in a separate file and manageable independently.

@binarylogic
Copy link
Contributor

@Alexx-G thank you for taking the time to submit this. I'm going to close this in favor of #2871. Please let us know if we're missing anything that isn't covered here. We're planning to release our official k8s support soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants