Hubble: Emit v1.Event on packet drop#29565
Hubble: Emit v1.Event on packet drop#29565rolinh merged 3 commits intocilium:mainfrom robinelfrink:drop-event-emitter
Conversation
|
TODO:
|
|
Hello @robinelfrink 👋 and thank you for the PR! I've marked it as Draft since you have some TODO left. Feel free to make it ready to review once you've completed them and rebased on top of |
|
Commit b57d999 does not match "(?m)^Signed-off-by:". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
|
Commit b57d999 does not match "(?m)^Signed-off-by:". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
|
Commit d27e288 does not match "(?m)^Signed-off-by:". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
|
Commits 4cb3eca, 999189a do not match "(?m)^Signed-off-by:". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
|
CI failure seems legit, PR lgtm otherwise |
Ah, yes, fix is coming up. |
rolinh
left a comment
There was a problem hiding this comment.
LGTM, thanks for your contribution Robin!
|
/test |
kaworu
left a comment
There was a problem hiding this comment.
Thanks @robinelfrink, couple of nitpicking about the Helm values but the patch LGTM now.
|
Rebased on a more recent |
|
/test |
This adds the option to hubble to emit v1.Events related to v1.Pods when a packet drop to or from that pod is detected. By default a packet drop with the same source/destination IP address results in an Event only once per two minutes. Fixes: #29399 Events will not currently show with `kubectl describe pod ...`; that requires the event emitter to add the pod's `metadata.uid` which is unknown at the time of emitting. Retrieving `metadata.uid` is considered a too expensive call at this moment. Signed-off-by: Robin Elfrink <robin@15augustus.nl>
Signed-off-by: Robin Elfrink <robin@15augustus.nl>
Signed-off-by: Robin Elfrink <robin.elfrink@eu.equinix.com>
|
/test |
|
Hi @rolinh, Is it safe to assume that the 3 failing checks are not related to my changes? |
|
Hi @robinelfrink, it seems unlikely that these failures are related to your changes in this PR. I've re-triggered some tests to see if they reliably fail or are just flaky. |
|
I've re-triggered ci-e2e again, hit a failure on an ingress test. |
|
@danehans could you please give this PR a review? EDIT: nevermind, someone else from sig-agent already gave a review so the PR is mergeable. |
This commit introduce a new Hubble cell. It is the first of a series of refactoring patches gradually transitioning Hubble configuration and startup code away from the Cilium daemon. Currently, all the Hubble configuration and initialization is implemented in the Cilium daemon. Hubble related flags (e.g. --enable-hubble) are member of the DaemonConfig struct, and the Hubble startup code is under daemon/cmd/hubble.go. Most notably the launchHubble() func which handle all the Hubble component startup is called from cmd.newDaemon(). Over time, launchHubble() has become increasingly complex, initializing more and more Hubble subsystems while bailing out if any of them encounter a configuration or startup error. This has lead to a situation where a misconfiguration of one part of Hubble (e.g. metrics) could effectively disable other Hubble components without crashing the Cilium daemon. The recent addition of many new Hubble feature / subsystems, for example monitor event filtering[1], L7 data redaction[2], and k8s Events integration on drop notifications[3] introducing new Hubble related flags and logic both increase the potential of startup failure and the surface of affected features. Furthermore, most of the new feature increase Hubble's reliance on the Cilium daemon for either flag setup/parsing and/or dependencies injection, making it harder to decouple Hubble from the Daemon. Fortunately, many part of Cilium already use the hive/cell framework for configuration, startup, and dependency injection. Most notably, all Hubble dependencies are now available as cell, which open the possibility to convert Hubble components as cell themselves. The goal of this patch series is to refactor Hubble into its own new cell and decouple it from the Cilium daemon. Concretely, all the code under daemon/cmd/hubble.go will be moved away into the new cell, along with the flags and Hubble startup, until the point where it would be possible to create a hive with the Hubble cell but without the Cilium daemon. Splitting the Hubble components into smaller cells is left for a later time. [1]: cilium#24828 [2]: cilium#23887 [3]: cilium#29565 Signed-off-by: Alexandre Perrin <alex@isovalent.com>
This commit introduce a new Hubble cell. It is the first of a series of refactoring patches gradually transitioning Hubble configuration and startup code away from the Cilium daemon. Currently, all the Hubble configuration and initialization is implemented in the Cilium daemon. Hubble related flags (e.g. --enable-hubble) are member of the DaemonConfig struct, and the Hubble startup code is under daemon/cmd/hubble.go. Most notably the launchHubble() func which handle all the Hubble component startup is called from cmd.newDaemon(). Over time, launchHubble() has become increasingly complex, initializing more and more Hubble subsystems while bailing out if any of them encounter a configuration or startup error. This has lead to a situation where a misconfiguration of one part of Hubble (e.g. metrics) could effectively disable other Hubble components without crashing the Cilium daemon. The recent addition of many new Hubble feature / subsystems, for example monitor event filtering[1], L7 data redaction[2], and k8s Events integration on drop notifications[3] introducing new Hubble related flags and logic both increase the potential of startup failure and the surface of affected features. Furthermore, most of the new feature increase Hubble's reliance on the Cilium daemon for either flag setup/parsing and/or dependencies injection, making it harder to decouple Hubble from the Daemon. Fortunately, many part of Cilium already use the hive/cell framework for configuration, startup, and dependency injection. Most notably, all Hubble dependencies are now available as cell, which open the possibility to convert Hubble components as cell themselves. The goal of this patch series is to refactor Hubble into its own new cell and decouple it from the Cilium daemon. Concretely, all the code under daemon/cmd/hubble.go will be moved away into the new cell, along with the flags and Hubble startup, until the point where it would be possible to create a hive with the Hubble cell but without the Cilium daemon. Splitting the Hubble components into smaller cells is left for a later time. [1]: cilium#24828 [2]: cilium#23887 [3]: cilium#29565 Signed-off-by: Alexandre Perrin <alex@isovalent.com>
This commit introduce a new Hubble cell. It is the first of a series of refactoring patches gradually transitioning Hubble configuration and startup code away from the Cilium daemon. Currently, all the Hubble configuration and initialization is implemented in the Cilium daemon. Hubble related flags (e.g. --enable-hubble) are member of the DaemonConfig struct, and the Hubble startup code is under daemon/cmd/hubble.go. Most notably the launchHubble() func which handle all the Hubble component startup is called from cmd.newDaemon(). Over time, launchHubble() has become increasingly complex, initializing more and more Hubble subsystems while bailing out if any of them encounter a configuration or startup error. This has lead to a situation where a misconfiguration of one part of Hubble (e.g. metrics) could effectively disable other Hubble components without crashing the Cilium daemon. The recent addition of many new Hubble feature / subsystems, for example monitor event filtering[1], L7 data redaction[2], and k8s Events integration on drop notifications[3] introducing new Hubble related flags and logic both increase the potential of startup failure and the surface of affected features. Furthermore, most of the new feature increase Hubble's reliance on the Cilium daemon for either flag setup/parsing and/or dependencies injection, making it harder to decouple Hubble from the Daemon. Fortunately, many part of Cilium already use the hive/cell framework for configuration, startup, and dependency injection. Most notably, all Hubble dependencies are now available as cell, which open the possibility to convert Hubble components as cell themselves. The goal of this patch series is to refactor Hubble into its own new cell and decouple it from the Cilium daemon. Concretely, all the code under daemon/cmd/hubble.go will be moved away into the new cell, along with the flags and Hubble startup, until the point where it would be possible to create a hive with the Hubble cell but without the Cilium daemon. Splitting the Hubble components into smaller cells is left for a later time. [1]: cilium#24828 [2]: cilium#23887 [3]: cilium#29565 Signed-off-by: Alexandre Perrin <alex@isovalent.com>
This commit introduce a new Hubble cell. It is the first of a series of refactoring patches gradually transitioning Hubble configuration and startup code away from the Cilium daemon. Currently, all the Hubble configuration and initialization is implemented in the Cilium daemon. Hubble related flags (e.g. --enable-hubble) are member of the DaemonConfig struct, and the Hubble startup code is under daemon/cmd/hubble.go. Most notably the launchHubble() func which handle all the Hubble component startup is called from cmd.newDaemon(). Over time, launchHubble() has become increasingly complex, initializing more and more Hubble subsystems while bailing out if any of them encounter a configuration or startup error. This has lead to a situation where a misconfiguration of one part of Hubble (e.g. metrics) could effectively disable other Hubble components without crashing the Cilium daemon. The recent addition of many new Hubble feature / subsystems, for example monitor event filtering[1], L7 data redaction[2], and k8s Events integration on drop notifications[3] introducing new Hubble related flags and logic both increase the potential of startup failure and the surface of affected features. Furthermore, most of the new feature increase Hubble's reliance on the Cilium daemon for either flag setup/parsing and/or dependencies injection, making it harder to decouple Hubble from the Daemon. Fortunately, many part of Cilium already use the hive/cell framework for configuration, startup, and dependency injection. Most notably, all Hubble dependencies are now available as cell, which open the possibility to convert Hubble components as cell themselves. The goal of this patch series is to refactor Hubble into its own new cell and decouple it from the Cilium daemon. Concretely, all the code under daemon/cmd/hubble.go will be moved away into the new cell, along with the flags and Hubble startup, until the point where it would be possible to create a hive with the Hubble cell but without the Cilium daemon. Splitting the Hubble components into smaller cells is left for a later time. [1]: cilium#24828 [2]: cilium#23887 [3]: cilium#29565 Signed-off-by: Alexandre Perrin <alex@isovalent.com>
This commit introduce a new Hubble cell. It is the first of a series of refactoring patches gradually transitioning Hubble configuration and startup code away from the Cilium daemon. Currently, all the Hubble configuration and initialization is implemented in the Cilium daemon. Hubble related flags (e.g. --enable-hubble) are member of the DaemonConfig struct, and the Hubble startup code is under daemon/cmd/hubble.go. Most notably the launchHubble() func which handle all the Hubble component startup is called from cmd.newDaemon(). Over time, launchHubble() has become increasingly complex, initializing more and more Hubble subsystems while bailing out if any of them encounter a configuration or startup error. This has lead to a situation where a misconfiguration of one part of Hubble (e.g. metrics) could effectively disable other Hubble components without crashing the Cilium daemon. The recent addition of many new Hubble feature / subsystems, for example monitor event filtering[1], L7 data redaction[2], and k8s Events integration on drop notifications[3] introducing new Hubble related flags and logic both increase the potential of startup failure and the surface of affected features. Furthermore, most of the new feature increase Hubble's reliance on the Cilium daemon for either flag setup/parsing and/or dependencies injection, making it harder to decouple Hubble from the Daemon. Fortunately, many part of Cilium already use the hive/cell framework for configuration, startup, and dependency injection. Most notably, all Hubble dependencies are now available as cell, which open the possibility to convert Hubble components as cell themselves. The goal of this patch series is to refactor Hubble into its own new cell and decouple it from the Cilium daemon. Concretely, all the code under daemon/cmd/hubble.go will be moved away into the new cell, along with the flags and Hubble startup, until the point where it would be possible to create a hive with the Hubble cell but without the Cilium daemon. Splitting the Hubble components into smaller cells is left for a later time. [1]: cilium#24828 [2]: cilium#23887 [3]: cilium#29565 Signed-off-by: Alexandre Perrin <alex@isovalent.com>
This commit introduce a new Hubble cell. It is the first of a series of refactoring patches gradually transitioning Hubble configuration and startup code away from the Cilium daemon. Currently, all the Hubble configuration and initialization is implemented in the Cilium daemon. Hubble related flags (e.g. --enable-hubble) are member of the DaemonConfig struct, and the Hubble startup code is under daemon/cmd/hubble.go. Most notably the launchHubble() func which handle all the Hubble component startup is called from cmd.newDaemon(). Over time, launchHubble() has become increasingly complex, initializing more and more Hubble subsystems while bailing out if any of them encounter a configuration or startup error. This has lead to a situation where a misconfiguration of one part of Hubble (e.g. metrics) could effectively disable other Hubble components without crashing the Cilium daemon. The recent addition of many new Hubble feature / subsystems, for example monitor event filtering[1], L7 data redaction[2], and k8s Events integration on drop notifications[3] introducing new Hubble related flags and logic both increase the potential of startup failure and the surface of affected features. Furthermore, most of the new feature increase Hubble's reliance on the Cilium daemon for either flag setup/parsing and/or dependencies injection, making it harder to decouple Hubble from the Daemon. Fortunately, many part of Cilium already use the hive/cell framework for configuration, startup, and dependency injection. Most notably, all Hubble dependencies are now available as cell, which open the possibility to convert Hubble components as cell themselves. The goal of this patch series is to refactor Hubble into its own new cell and decouple it from the Cilium daemon. Concretely, all the code under daemon/cmd/hubble.go will be moved away into the new cell, along with the flags and Hubble startup, until the point where it would be possible to create a hive with the Hubble cell but without the Cilium daemon. Splitting the Hubble components into smaller cells is left for a later time. [1]: cilium#24828 [2]: cilium#23887 [3]: cilium#29565 Signed-off-by: Alexandre Perrin <alex@isovalent.com>
This commit introduce a new Hubble cell. It is the first of a series of refactoring patches gradually transitioning Hubble configuration and startup code away from the Cilium daemon. Currently, all the Hubble configuration and initialization is implemented in the Cilium daemon. Hubble related flags (e.g. --enable-hubble) are member of the DaemonConfig struct, and the Hubble startup code is under daemon/cmd/hubble.go. Most notably the launchHubble() func which handle all the Hubble component startup is called from cmd.newDaemon(). Over time, launchHubble() has become increasingly complex, initializing more and more Hubble subsystems while bailing out if any of them encounter a configuration or startup error. This has lead to a situation where a misconfiguration of one part of Hubble (e.g. metrics) could effectively disable other Hubble components without crashing the Cilium daemon. The recent addition of many new Hubble feature / subsystems, for example monitor event filtering[1], L7 data redaction[2], and k8s Events integration on drop notifications[3] introducing new Hubble related flags and logic both increase the potential of startup failure and the surface of affected features. Furthermore, most of the new feature increase Hubble's reliance on the Cilium daemon for either flag setup/parsing and/or dependencies injection, making it harder to decouple Hubble from the Daemon. Fortunately, many part of Cilium already use the hive/cell framework for configuration, startup, and dependency injection. Most notably, all Hubble dependencies are now available as cell, which open the possibility to convert Hubble components as cell themselves. The goal of this patch series is to refactor Hubble into its own new cell and decouple it from the Cilium daemon. Concretely, all the code under daemon/cmd/hubble.go will be moved away into the new cell, along with the flags and Hubble startup, until the point where it would be possible to create a hive with the Hubble cell but without the Cilium daemon. Splitting the Hubble components into smaller cells is left for a later time. [1]: #24828 [2]: #23887 [3]: #29565 Signed-off-by: Alexandre Perrin <alex@isovalent.com>
This adds the option to hubble to emit v1.Events related to v1.Pods when a packet drop to or from that pod is detected.
Please ensure your pull request adheres to the following guidelines:
description and a
Fixes: #XXXline if the commit addresses a particularGitHub issue.
Fixes: <commit-id>tag, thenplease add the commit author[s] as reviewer[s] to this issue.
Fixes: #29399