-
Notifications
You must be signed in to change notification settings - Fork 724
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
ECK resources Helm chart - Beats #5899
ECK resources Helm chart - Beats #5899
Conversation
…tly. adjust apiversion in template. adjust beat labels in template. add type of beat to the default values, along with a description.
Adjust examples to override the default values for those values.
renaming beats templates, as they're singular now. adding beats helm unit tests to eck-stack chart. adding beats to eck-stack values file. adding beats to eck-stack chart.yaml
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.
Disclaimer: I was feeling a bit out of sync with the recent effort on the Helm Charts, so I wanted to catch up by reviewing this PR 😄 I still however feel like a beginner when it comes to Helm, so apologies if some comments are irrelevant or have been already discussed.
@@ -0,0 +1,113 @@ | |||
name: auditbeat | |||
type: auditbeat | |||
version: 8.2.3 |
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.
There are a lot of references to what, I guess, should be a recent stack version. Should we try to use hack/update-stack-version.sh
to maintain them ?
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've updated this script, and made the appropriate changes to the versions in this PR, but am hesitant to update the other charts in this PR, as we'd need to bump the chart versions when this happens.
apiVersion: v2 | ||
name: eck-beats | ||
description: A Helm chart to deploy Elastic Beats managed by the ECK Operator. | ||
kubeVersion: ">= 1.20.0-0" |
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.
Same question here, how do maintain this version? (It is also mentioned in deploy/eck-stack/README.md
, I think it feels a bit redundant with what's in the main README.md
)
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 updated this to include the reasoning behind this requirement, as I think it's important. This would need to be updated during the normal release process for the eck-operator, when the requirement changes.
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.
If a user is using a version of the operator that still supports a previous k8s version (for example ECK 2.2
which still supports K8S 1.19
), but the user needs to update the Helm Chart: does it prevent the user to use that new version of the Chart on 1.19
? I'm just trying to understand how the min. k8s version supported by the operator and the min. k8s version supported by a Chart are tied.
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.
If a user was running eck 2.2
on K8S 1.19
and attempted to use these Helm Charts, they would fail (helm would throw a failure) because of this K8S version requirement in the Chart.yaml.
kibanaRef: | ||
name: kibana | ||
config: | ||
# Since filebeat is used in the default values, this needs to be removed with an empty list. |
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.
This is mentioned in several places, does it not feel a bit odd that the user must explicitly disable a Beat
to deploy another one?
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.
Over the course of the previous Helm Chart PRs, we've tried to maintain that installing with the default values gives some sort of useful "default" installation. Though just recently, in the agent Helm Charts PR, the config
section in the default values was removed, so maybe this makes sense here as well, but the default will not be useful, but will make the user experience for overrides much better. Thoughts?
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.
Sorry for the very late answer. I need to have a look at what is proposed for Agent. Defaulting to Filebeat
feels a bit "opinionated" to me. It means we assume that the "most useful" default is Filebeat, not Metricbeat, and I'm not sure I get the reason why.
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 see why defaulting to Filebeat
may not make the most sense here. I'll update this to useMetricbeat
by default.
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.
actually @barkbay, I remember why I defaulted to filebeat once I went back and looked at this. By defaulting to filebeat, we add the minimum amount to the default values and still have a useful "default" Beat install. If we move this to metricbeat, many more default values would be needed to be added to make a useful default Beat install. Let me know your thoughts here.
deploy/eck-beats/values.yaml
Outdated
- name: filebeat | ||
securityContext: | ||
runAsUser: 0 | ||
# If using Red Hat OpenShift uncomment this: |
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.
nit: this comment about OpenShift is not preserved in the resulting Beat resource, not sure if there is a way to keep comments.
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.
There is no way to keep comments from values.yaml file after helm renders them. Comments can be placed in templates/*.yaml
and are preserved, for example:
I updated templates/beats.yaml
to include this:
---
apiVersion: beat.k8s.elastic.co/v1beta1
kind: Beat
metadata:
# Name of the beat
name: {{ include "beat.fullname" . }}
labels:
{{- include "beat.labels" . | nindent 4 }}
---cut---
And ran
helm install eck-beats . --dry-run --debug
And can see in the output
---
# Source: eck-beats/templates/beats.yaml
apiVersion: beat.k8s.elastic.co/v1beta1
kind: Beat
metadata:
# Name of the beat
name: eck-beats
Update update-stack-version.sh to support updating helm chart stack versions as well Add notes about where the k8s version requirement comes from.
ensure cluster role binding ref exists before templating. Tests for clusterrolebinding/clusterrole/serviceaccount
We had some discussion around this, and will remove any default beat from the values, and require the user to set a value for type of beat to use to move this PR forward. |
newlines at end of all files remove plural from all beat names
This PR updated:
|
spec: | ||
type: auditbeat | ||
elasticsearchRef: | ||
name: elasticsearch |
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.
Should we use the default names Elasticsearch and Kibana get when using the corresponding Helm charts?
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've updated this per most comments, but want to check into this further tomorrow, as these names are dependent on the name of the chart itself, unless doing a full name override, so I'll want to ensure this is consistent with the other charts.
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.
@pebrc I've updated all values and all examples across all charts to be consistent for naming and updated all versions to latest stack 8.5.0, along with updating all tests to match/pass.
I've also bumped the versions of all charts where stack version changes were made, and updated the eck-stack Chart.yaml's dependency versions to match.
This should be ready for another set of 👀
subjects: | ||
- kind: ServiceAccount | ||
name: metricbeat | ||
namespace: default |
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 do something clever to get the release namespace 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.
We actually do default to the Release.Namespace
. This was an oversight keeping this in the example. It's ben removed.
namespace: {{ .namespace | default $.Release.Namespace | quote }}
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 it's still there. Forgot to push a commit?
Increment eck-stack chart version
Update tests for new stack vesrion, and consistent naming changes.
…e of stack version change.
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.
LGTM
@@ -45,7 +45,7 @@ spec: | |||
# Reference to ECK-managed Elasticsearch instance. | |||
# | |||
elasticsearchRefs: | |||
- name: elasticsearch | |||
- name: eck-elasticsearch |
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.
Is this a breaking change for users who already rely on the old names? Not sure what the expectations around Helm charts are when it comes to this.
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.
These are simply the default values, and are just placeholders for users to provide their own names, as the names of these follow these rules from the values files: (they, by default, are prefixed with the Release
name that the user provides, so there's no way to predict it)
# Overridable names of the Elasticsearch resource.
# By default, this is the Release name set for the chart,
# followed by 'eck-elasticsearch'.
#
# nameOverride will override the name of the Chart with the name set here,
# so nameOverride: quickstart, would convert to '{{ Release.name }}-quickstart'
#
# nameOverride: "quickstart"
#
# fullnameOverride will override both the release name, and the chart name,
# and will name the Elasticsearch resource exactly as specified.
#
# fullnameOverride: "quickstart"
Since we are also incrementing the semver already, it may make sense to indicate that these are breaking changes, if any users are using this default behavior. I'll do so.
hack/update-stack-version.sh
Outdated
@@ -34,7 +34,7 @@ for_all_yaml_do() { | |||
local function="$1" | |||
# Directories containing Yaml files with version references to replace | |||
# Note: hack/operatorhub/config.yaml will need to be updated manually | |||
local dirs=(config/samples config/recipes config/e2e test/e2e) | |||
local dirs=(config/samples config/recipes config/e2e test/e2e deploy/eck-stack deploy/eck-beats deploy/eck-kibana deploy/eck-elasticsearch) |
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.
Why not just deploy
? Assuming you want to exclude the operator Helm Chart why is are the Agent charts missing?
subjects: | ||
- kind: ServiceAccount | ||
name: metricbeat | ||
namespace: default |
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 it's still there. Forgot to push a commit?
…ault values change update the stack version update script to include agent/fleet-server-agent
@pebrc this namespace reference was also in an example in Also, to the |
@naemono Has this chart been pushed to the https://helm.elastic.co repository? |
* Add initial version of ECK-Managed Beats Helm Chart
@brsolomon-deloitte apologies for the delays in response. You should see the Helm chart within the repository in about 1 hour. |
related to #5505
This PR contains the 3rd version of the ECK-managed resources helm charts including
eck-beats chart for installing the different types of Beats
minor updates to the eck-stack chart.
cc @jmlrt @Kushmaro @framsouza