Skip to content

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

Closed
alexgavrisco wants to merge 2 commits into
vectordotdev:masterfrom
alexgavrisco:add-helm-chart
Closed

feat(platforms): Add helm chart for Vector installation#2232
alexgavrisco wants to merge 2 commits into
vectordotdev:masterfrom
alexgavrisco:add-helm-chart

Conversation

@alexgavrisco

Copy link
Copy Markdown
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.

Signed-off-by: Alex Gavrisco <alexandr@gavrisco.com>
@alexgavrisco alexgavrisco requested a review from a user April 5, 2020 19:36
Signed-off-by: Alex Gavrisco <alexandr@gavrisco.com>
@alexgavrisco

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
Contributor Author

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

@MOZGIII

MOZGIII commented May 7, 2020

Copy link
Copy Markdown
Contributor

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

@MOZGIII MOZGIII May 7, 2020

Copy link
Copy Markdown
Contributor

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
Copy Markdown
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