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

ECK resources Helm chart - Beats #5899

Merged
merged 28 commits into from
Nov 23, 2022

Conversation

naemono
Copy link
Contributor

@naemono naemono commented Jul 28, 2022

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

naemono added 7 commits July 28, 2022 08:41
…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
@naemono naemono added the >enhancement Enhancement of existing functionality label Jul 28, 2022
@naemono naemono marked this pull request as ready for review July 28, 2022 16:49
@barkbay barkbay self-assigned this Aug 9, 2022
Copy link
Contributor

@barkbay barkbay left a 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.

deploy/eck-stack/Chart.yaml Show resolved Hide resolved
deploy/eck-beats/examples/heartbeat_es_kb_health.yaml Outdated Show resolved Hide resolved
deploy/eck-beats/Chart.yaml Show resolved Hide resolved
deploy/eck-beats/examples/auditbeat_hosts.yaml Outdated Show resolved Hide resolved
@@ -0,0 +1,113 @@
name: auditbeat
type: auditbeat
version: 8.2.3
Copy link
Contributor

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 ?

Copy link
Contributor Author

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"
Copy link
Contributor

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)

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

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?

Copy link
Contributor Author

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?

Copy link
Contributor

@barkbay barkbay Sep 5, 2022

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

- name: filebeat
securityContext:
runAsUser: 0
# If using Red Hat OpenShift uncomment this:
Copy link
Contributor

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.

Copy link
Contributor Author

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.
@barkbay barkbay removed their assignment Sep 13, 2022
@naemono
Copy link
Contributor Author

naemono commented Oct 27, 2022

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

naemono commented Oct 31, 2022

This PR updated:

  • No beat type, or config set in default values
  • Will fail if no beat type is set.
  • Added examples, and tests for all currently supported beat types (IIUC journalbeat is deprecated)

spec:
type: auditbeat
elasticsearchRef:
name: elasticsearch
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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 👀

deploy/eck-beats/examples/metricbeat_hosts.yaml Outdated Show resolved Hide resolved
deploy/eck-beats/examples/metricbeat_hosts.yaml Outdated Show resolved Hide resolved
deploy/eck-stack/examples/metricbeat_hosts.yaml Outdated Show resolved Hide resolved
subjects:
- kind: ServiceAccount
name: metricbeat
namespace: default
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

https://github.com/elastic/cloud-on-k8s/pull/5899/files#diff-7a54af9bb234c05618afe6d34207f8931b534d186a560cebe506c9584414fb3fR26

    namespace: {{ .namespace | default $.Release.Namespace | quote }}

Copy link
Collaborator

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?

Copy link
Collaborator

@pebrc pebrc left a 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
Copy link
Collaborator

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.

Copy link
Contributor Author

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.

@@ -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)
Copy link
Collaborator

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
Copy link
Collaborator

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

naemono commented Nov 21, 2022

I think it's still there. Forgot to push a commit?

@pebrc this namespace reference was also in an example in eck-beats/examples/*, which is where I removed the previous one from. I've removed this one as well. Ty

Also, to the hack/update-stack-version.sh comment, I believe the initial intent was to not include the operator chart. I've updated this to include agent/fleet.

@naemono naemono added the v2.6.0 label Nov 22, 2022
@naemono naemono merged commit 170ebe7 into elastic:main Nov 23, 2022
@brsolomon-deloitte
Copy link

@naemono Has this chart been pushed to the https://helm.elastic.co repository?

@thbkrkr thbkrkr added >feature Adds or discusses adding a feature to the product and removed >enhancement Enhancement of existing functionality labels Jan 5, 2023
naemono added a commit to naemono/cloud-on-k8s that referenced this pull request Jan 9, 2023
* Add initial version of ECK-Managed Beats Helm Chart
naemono added a commit that referenced this pull request Jan 9, 2023
* Add initial version of ECK-Managed Beats Helm Chart
@naemono
Copy link
Contributor Author

naemono commented Jan 12, 2023

@naemono Has this chart been pushed to the https://helm.elastic.co repository?

@brsolomon-deloitte apologies for the delays in response. You should see the Helm chart within the repository in about 1 hour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>feature Adds or discusses adding a feature to the product v2.6.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants