-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
[k8sattributesprocessor] Refactor informer initialization #36604
base: main
Are you sure you want to change the base?
[k8sattributesprocessor] Refactor informer initialization #36604
Conversation
04db117
to
a4351c1
Compare
I haven't added a changelog entry because this change should be completely transparent to users. Considering I've made a whole bunch of changes though, I can see an argument to add one anyway. |
This is a good problem to solve. Potentially, it'd be great to share across all k8s components. However, I'm curious, have you considered using https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/internal/sharedcomponent for this particular problem? |
I didn't know that existed, so no 😅. But as far as I can see, it just allows us to avoid making copies of identical components. The primary use case I'd like to address (not with this PR, but with a follow up) is having processors used for different signal types share the cache. With sharedcomponent, you can't have a logs processor act on traces, it's a different interface. |
When it comes to sharing across all Kubernetes components, it should be possible. We'd have to come up with a common interface for informer providers, but I think standard options in client-go get us 90% there. Then the main thing we'd need to standardize would be client construction, but I think that's already done with internal/k8sconfig. The most challenging bit are transform functions, because we'd need a way of specifying their behaviour statically in a way that was consistent across all components. I think the k8sattributes processor is the only user of these right now, so it's not a problem we'd need to solve to get most of the benefit. |
|
Dang, that's unfortunate. At least it looks like their transform funcs don't depend on configuration. But I'm not sure if this would even be especially useful. You don't normally want multiple k8sclusterreceivers, and it's unlikely that you'd be able to share informers with other components unless you resign yourself to keeping all the data. |
a4351c1
to
2d6e81f
Compare
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
@@ -33,6 +33,9 @@ type kubernetesprocessor struct { | |||
telemetrySettings component.TelemetrySettings | |||
logger *zap.Logger | |||
apiConfig k8sconfig.APIConfig | |||
k8sClientProvider kube.APIClientsetProvider | |||
kcProvider kube.ClientProvider | |||
informerProviders *kube.InformerProviders |
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 the informerProviders
is a nested field of kubernetesprocessor
, how could we ensure the local caches of informer can be shared among all the kubernetes processor object?
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.
The actual providers are just functions, and their implementations can pull from a shared pool of informers. The informerProviders
struct just contains all the providers potentially necessary for the processor to function. It only exists for convenience, so we don't have to pass around four provider functions everywhere.
Also remove handlers when stopping the processor.
2d6e81f
to
d7ec6a5
Compare
Description
We'd like instances of the k8sattributes processor to share local K8s resource caches (represented by the
informer
concept from client-go). See #36234 for the justification and a broad overview. This change refactors internal interfaces and responsibilities of different components during initialization, in order to make this possible.The way the processor currently initializes resources makes it impossible to share them effectively:
We address the issues above by making the following changes:
InformerProviders
struct which contains all the necessary providers. This makes it easier to inject them during initialization as needed, and also simplifies tests.This is a refactor without any externally visible changes. It is split rather cleanly into atomic commits, and may be easier to review that way. I'm submitting it as a single PR because I believe it is easier to understand this way, but I'm open to splitting it into parts.
Link to tracking issue
Part of #36234
Testing
Added some unit tests for the new code.