-
Notifications
You must be signed in to change notification settings - Fork 729
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
Introduce Beat CRD #3041
Introduce Beat CRD #3041
Conversation
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 did a first review, I'll do some additional tests.
First pass at Beats in ECK, features include: - native support for Filebeat (daemonset only) - initial support for other Beats (deployment only) - RBAC for autodiscovery setup (can be disabled via operator flag) - providing Beat status - basic webhook/non-webhook validation - rollout for config/version changes - labelling for all created resources - support for pod template/config overriding - basic apm/events/logging
08c6598
to
d4c538e
Compare
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.
Great work! The code is very clean now with the recent refactoring 👍
I left some comments, mostly for minor cosmetic changes. I'm fine with merging early and creating follow-up issues where necessary.
- JSONPath: .status.expectedNodes | ||
description: Expected nodes | ||
name: expected | ||
type: integer |
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 we have a single nodes
(corresponding to available nodes) instead of expectedNodes
and availableNodes
in other CRDs. Let's be consistent?
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 we did want to change that in the past (#1786). I'd be for keeping both and improving the status on other resources. It's following the pattern of built-in resources, gives the users more information and it comes free. I'd leave it as is unless you feel strongly about it. (I'm open to naming changes.)
Just to track from our out of band conversation yesterday, I think we do want to release this as v1alpha1 at first |
This is to avoid needing more permissions than the pod has through autodiscovery Improve checks in e2e tests
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. Awesome work @david-kow!
I left a few comments again. I think I'd prefer we merge soon and build on top with smaller PRs, rather than iterate here for too long.
hosts: | ||
- https://${HOSTNAME}:10249 | ||
metricsets: | ||
- proxy |
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 you clarify why we remove those? Is it moving us away from https://raw.githubusercontent.com/elastic/beats/7.7/deploy/kubernetes/metricbeat-kubernetes.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.
Filebeat doesn't need any API permissions other than autodiscover provides, but Metricbeat does. Removing the modules/metricsets that need those permissions. This will be addressed by implementation of #3190, but not fixing it here to avoid solving the same problem twice. Those modules/metricsets will be brought back in another PR.
field.NewPath("spec").Child("image"), | ||
"Image is required if Beat type is not one of [filebeat, metricbeat]"), | ||
} | ||
} |
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.
Discussed on Slack: it's about what we support or not. If users specify type: packetbeat
they may feel like ECK supports running packetbeat, which is not true.
@@ -24,6 +24,8 @@ const ( | |||
ElasticsearchImage Image = "elasticsearch/elasticsearch" | |||
KibanaImage Image = "kibana/kibana" | |||
EnterpriseSearchImage Image = "enterprise-search/enterprise-search" | |||
FilebeatImage Image = "beats/filebeat" | |||
MetricbeatImage Image = "beats/metricbeat" |
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.
Discussed on Slack: it's about what we "support". If the user is allowed to specify type: packetbeat
they may feel like we officially support it, which isn't true.
Thanks for reviews everyone! |
This PR introduces first iteration of CRD for Beats and it's updated to reflect most recent changes.
Look & feel
Filebeat
Heartbeat
Features
Additional notes
State
This is the first pass, meta-issue was created (#3040) for additional context and work tracking. There is couple of open issues to discuss PSP/SCC treatment (#3133), default/merging config (#3042) and autodiscover RBAC (#3134).
Testing
I was able to run Filebeat, Metricbeat and Heartbeat successfully, change config, upgrade versions. Some E2E are added for couple basic scenarios and SmokeTest runs with Filebeat now. Tested on OpenShift as well. There is a facility introduced that helps with querying ES and checking whether Beats events really appear in ES. In E2E tests autodiscover RBAC is managed by the operator, while the correct PSP is granted to the operator similarly to other stack products. This will be improved to grant additional permissions only to Beat pods and avoid escalating operator privileges unnecessarily.
Also, at some point, tested manually with:
Beat support
Only filebeat and metricbeat are supported natively. Other beats can be deployed, but only when both
image
andconfig
are provided.Config handling
As this deserves an issue of it's own to discuss (#3042), I'll just sum up what is currently in the code: if no
spec.config
is provided we use a static, default config fromcontroller/common/beat/filebeat/config.go
, otherwise we use the provided config. The only merging we do is theoutput
ifelasticsearchRef
was provided.