-
Notifications
You must be signed in to change notification settings - Fork 152
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
Use Kustomize to build elastic-agent manifests for both managed and standalone more #2104
Conversation
This pull request does not have a backport label. Could you fix it @gsantoro? 🙏
NOTE: |
requests: | ||
cpu: 100m | ||
memory: 200Mi | ||
volumeMounts: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think following part can also be splitted to multilple overalys.
We want to have needed mounts for observability and extra ones that imposed from security
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you mind elaborate a bit more on the topic. I vaguely recollect some suggestions from the security team but I wouldn't know how to change this part of the manifest
@@ -0,0 +1,3 @@ | |||
ES_USERNAME=elastic | |||
ES_PASSWORD=changeme | |||
ES_HOST=https://elasticsearch:9200 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest to put namespace as variable here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you can use a variable from an .env file in the kustomization.yml file (which is where I set the namespace for all the resources)
@@ -0,0 +1,3 @@ | |||
ES_USERNAME=elastic | |||
ES_PASSWORD=changeme | |||
ES_HOST=https://elasticsearch:9200 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have as boolean on/off options the ability to install kube state metrics here?
By default to be on
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so. This env file is only used to create a configmap and I don't think we can use an env variable from a configmap to decide if we want to add a manifest based on that. We could use an overlay with an extra resource to install or not the kube-state-metrics
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But then we will need to edit the kustomize.yaml.
Maybe we can think that we can provide diffrent kustomzation files ?
eg kustomize-ksmenabled, kustomize-ksmdisabled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, I believe we have to go that way. Different overlays for different behaviours
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1st Option:
A tool worth looking:
https://carvel.dev/ytt/
So we would like to provide some basic YAML templating and then kustomize installation.
2nd Option:
Maybe our new MAKEFILE that we can run and produce specific kustomize folders and run as oneliner command?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I heard about ytt but it seemed way too complicated compared to kustomize. Should we create another issue with the list of requirements before diving into ytt?
Summarising some small comments from relevant slack commnication: For first iteration of this effort:
Extra stories:
|
🌐 Coverage report
|
…c-agent labels, namespace and other changes from the various kustomizations.yaml
…ther kustomization and overlays
- configMapRef: | ||
# Fleet Server URL to enroll the Elastic Agent into | ||
# FLEET_URL can be found in Kibana, go to Management > Fleet > Settings | ||
# - name: FLEET_URL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just out of curiosity, why all these settings are commented out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
they are mostly left there for documentation. We should address them (one way or another) in the next update about on this topic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But when those vars should be uncommented?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have created this PR to fix this
What does this PR do?
Use Kustomize to simplify building manifest for elastic-agent both for managed and standalone mode.
Why is it important?
This PR reduces the amount of boiler plate code needed to build manifests for elastic-agent. Some enhancements:
github.com/kubernetes/kube-state-metrics?ref=main
to common/kustomization.ymlelastic-agent-standalone-
orelastic-agent-managed
). This enables to deploy standalone and managed agents side by side.Checklist
./changelog/fragments
using the changelog toolAuthor's Checklist
How to test this PR locally
Related issues
Use cases
Screenshots
Logs